mattbaker
Double-link dependencies resolving
Hello!
After some time of using Reactive.js and trying to find a simple and effective way for resolving double-link dependecies graph, as for me I am still far from best solution...
Lets consider a very simple situiation for an example: We've got three objects - A (Datasource), B (Calendar) and C (Some Data). In real life application they are Combobox control, Calendar control and a Grid control. Dependecies are follow: A change B and C, B change C.
The point to mention, is that we cant collapse this graph to something like A -> B -> C in real life because of library result memorisation. I.E: Calendar has current 01/01/2015 as selected value. Changing combobox option sets calendar value again for 01/01/2015. Grid awaiting for calendar changes never accepts event in that particular situation, because underlying memorized value of parent graph object is not changed.
Leaving the scheme A -> (B,C). B -> (C) results in updating C object twice when A is changed. And if C perfoms heavy operation, well... its bad.
This example is very simple, and still it is a real life situiation. The way we handle it, is using additional state variable inside C for resolving, which are setted in A or B.
Maybe there is another, more reactive'ly way to solve the issue?
I'd love to see some small example of this! Maybe even with the UI widgets (calendar, grid). Could you provide a js fiddle or gist? I'm curious to see if I would reach the same conclusion, or have a different take on it.
If you can provide one let me know, I think I see what you're saying but it'd be easier if I could play with an example
On Monday, February 2, 2015, Еugene [email protected] wrote:
Hello!
After some time of using Reactive.js and trying to find a simple and effective way for resolving double-link dependecies graph, as for me I am still far from best solution...
Lets consider a very simple situiation for an example: We've got three objects - A (Datasource), B (Calendar) and C (Some Data). In real life application they are Combobox control, Calendar control and a Grid control. Dependecies are follow: A change B and C, B change C.
The point to mention, is that we cant collapse this graph to something like A -> B -> C in real life because of library result memorisation. I.E: Calendar has current 01/01/2015 as selected value. Changing combobox option sets calendar value again for 01/01/2015. Grid awaiting for calendar changes never accepts event in that particular situation, because underlying memorized value of parent graph object is not changed.
Leaving the scheme A -> (B,C). B -> (C) results in updating C object twice when A is changed. And if C perfoms heavy operation, well... its bad.
This example is very simple, and still it is a real life situiation. The way we handle it, is using additional state variable inside C for resolving, which are setted in A or B.
Maybe there is another, more reactive'ly way to solve the issue?
— Reply to this email directly or view it on GitHub https://github.com/mattbaker/Reactive.js/issues/10.
Yes, for sure I will make a simple UI example for demonstrating the issue. Will add a link here to jsfiddle as soon as it will be completed.
Awesome, looking forward to it
On Tuesday, February 3, 2015, Еugene [email protected] wrote:
Yes, for sure I will make a simple UI example for demonstrating the issue.
— Reply to this email directly or view it on GitHub https://github.com/mattbaker/Reactive.js/issues/10#issuecomment-72608491 .
Example with JSFiddle: http://jsfiddle.net/62138jpd/4/
NOTES: From scratch the example shows the situation about double-link updating with the following graph A-> (B,C) & B->(C). When choosing source from combo, it tries to update grid (and fails because we need two initialized values for this), then setting a date combo and finally updates the grid. The preferable solution would be a single grid update only.
Uncommenting line with folded graph like A->(B) & B->(C) even didn't work at all, because of trying to get A value from C resolves to indefinite loop in such case (If it is curious, why I didn't write about it at first post - because of some changes in library from our side, about which I wrote in Issue#8). With those changes dependencies recalculations are not started after target graph object, but since both sources have 2012 year as started, change of date state is not fired after selection.
P.S. Sorry for my English, I'm trying my best to describe the problem as accurate as possibe, but still it is not my native language :)
Been a while, can't contribute much but here's something I noticed in the docs:
Dependency graph traversal is recursive
In a worst case scenario, with a chain of dependent nodes thousands in number, we can exceed the size of the call stack. You'd really have to try at this to do it, but the limitation is out there. If it's truly an issue the traversal function can be swapped for a loop in the future. From https://github.com/mattbaker/Reactive.js#dependency-graph-traversal-is-recursive
I will repeat the important point:
If it's truly an issue the traversal function can be swapped for a loop in the future.
I mention this as @oliseviche mentioned encountering infinite looping, so I figure this may be relevant. :)
Hey @r4j4h! My note in the docs was just to say that the traversal function is currently recursive, but could be a loop if we start blowing the stack. The function itself should be working correctly but let me know if you see evidence otherwise :+1:
Thank you for the clarification. I did not mean to suggest that it wasn't working correctly! :) He was experiencing a blown stack so I figured it might be worth mentioning. :) He last posted back in Feb so hopefully he found a solution regardless!
Greetings :) Well, the situation about blown stack isn't really related to problem of recursion, it is related to the way we wanted to use the library. Test example clearly shows the problem, but it is not the problem of library architecture.