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

Immediately evaluate reactor.observe #36

Closed
appsforartists opened this issue May 5, 2015 · 2 comments
Closed

Immediately evaluate reactor.observe #36

appsforartists opened this issue May 5, 2015 · 2 comments

Comments

@appsforartists
Copy link
Contributor

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:

var stopObserving;

var onValue = (value) => {
  var completed = doStuffWith(value);

  if (completed)
    stopObserving();
};

onValue(reactor.evaluate(getter));
var stopObserving = reactor.observe(getter, onValue);

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?

@jordangarcia
Copy link
Contributor

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.

@jordangarcia
Copy link
Contributor

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

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

2 participants