You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Consider a case with 2 properties (condition and sequence of items) and a showIfElse, which has a produce in the positive branch and repeat+ produce in the negative one. None of these bindings are wrapped in a nested interceptor (in fact, at the moment of writing this, there isn't one provided by the API #592 ). If the condition property changes a few times, bindings will leak.
The order of triggering these bindings once the items property changes is suprising - first all repeats will be handled, then all produces.
This is caused by the fact that structure listeners are fired before value listeners. In the case I've mentioned here, it may cause nasty bugs (e.g. if the content is shared between the bindings div("test").render, it will not be shown in the negative branch due to past produce bindings rendering it after the last repeat binding).
I've seen several places internally which have to work around this behaviour and could be simplfiied by more general listeners, which listen to both value and structure changes and therefore are guaranteed to be fired in order. Another approach could be to keep common order between the lists of element and value listeners.
The text was updated successfully, but these errors were encountered:
Consider a case with 2 properties (condition and sequence of items) and a
showIfElse
, which has aproduce
in the positive branch andrepeat
+produce
in the negative one. None of these bindings are wrapped in a nested interceptor (in fact, at the moment of writing this, there isn't one provided by the API #592 ). If the condition property changes a few times, bindings will leak.The order of triggering these bindings once the items property changes is suprising - first all repeats will be handled, then all produces.
This is caused by the fact that structure listeners are fired before value listeners. In the case I've mentioned here, it may cause nasty bugs (e.g. if the content is shared between the bindings
div("test").render
, it will not be shown in the negative branch due to pastproduce
bindings rendering it after the lastrepeat
binding).I've seen several places internally which have to work around this behaviour and could be simplfiied by more general listeners, which listen to both value and structure changes and therefore are guaranteed to be fired in order. Another approach could be to keep common order between the lists of element and value listeners.
The text was updated successfully, but these errors were encountered: