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
reactor.observe only triggers on changes. It seems like it should trigger immediately using the current result of the getter. Otherwise, if you don't know the present state and don't want to leak memory, you have to do something like this:
I ran into this same issue when implementing a data-binding layer between Nuclear and VueJS.
Your solution of immediately evaluating and then observing is what I ended up doing.
In terms of leaking memory, i've found it best to not use reactor.observe many places but instead build it into a UI framework or conventionalize around some lifecycle of obsevation, ie a React Component.
By relying on observe as a way to read data from your system you lose a predictability and understandability of NuclearJS. In fact we have built an entire frontend and only use observe outside of a component binding maybe 3 times.
The pattern you mention above @appsforartists seems like a pretty easy way to do this.
Having to evaluate before observe isn't a huge cost to incur and if we coupled evaluate with observe you could never get the behavior of "observing without first evaluating" without a flag passed to observe.
For now I am going to keep the API as is, since we are in 1.0.x
reactor.observe
only triggers on changes. It seems like it should trigger immediately using the current result of the getter. Otherwise, if you don't know the present state and don't want to leak memory, you have to do something like this:Instead of simply
reactor.observe(getter, onValue)
.This could either be corrected by default, corrected with a flag or new method (like
observeImmediately
), or left as is. What do you think?The text was updated successfully, but these errors were encountered: