Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bindings handling ordering #593

Open
ddworak opened this issue May 6, 2020 · 0 comments
Open

Bindings handling ordering #593

ddworak opened this issue May 6, 2020 · 0 comments
Milestone

Comments

@ddworak
Copy link
Member

ddworak commented May 6, 2020

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.

@ddworak ddworak added this to the 1.0 milestone May 6, 2020
@ddworak ddworak changed the title Bindings ordering Bindings handling ordering May 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant