Quantcast
Channel: Ember.JS - Latest topics
Viewing all articles
Browse latest Browse all 4828

What constitutes a run loop side effect?

$
0
0

@williamhaley wrote:

These articles were a really helpful guide in my understanding about how async side effects in JS impact my application. I think I’ve got a working understanding of the benefits of the run loop, but I’m still confused on what’s considered a side effect and how to track down which parts of my async code result in side effects.

Example here. I have an async “save” action in one of my controllers. It kicks off a batch save like so.

import { all } from 'rsvp';

async save(foos) {
    let promises = foos.map(async (foo) => {
      // ...
      await foo.get('bar').save();
      // ...
      foo.get('baz').someFunc();
      foo.set('isEditing', false);
      // Kicking off an ember-concurrency task. Not waiting for it.
      this.get('someTask').perform(foo);
      // ...
      return foo;
   });

    try {
      await all(promises);
      // Show success message.
    } catch (err) {
      // Show error message.
    }
}

For reasons I do not understand, foo.get('baz').someFunc(); needs a run() loop, but the other lines don’t. Based on my understanding of the run loop, I would assume that all of them need a run(), but that does not seem to be the case.

I need to do this…

run(() => {
  foo.get('baz').someFunc();
});
foo.set('isEditing', false);
// Kicking off an ember-concurrency task. Not waiting for it.
this.get('someTask').perform(foo);

…otherwise, I get this error…

You have turned on testing mode, which disabled the run-loop’s autorun. You will need to wrap any code with asynchronous side-effects in a run` error

So someFunc() causes a side effect and needs a run(). That makes sense. But what about those other lines? Why do they not need a run()? Aren’t those side-effects too? I use {{foo.isEditing}} in the template for this controller. Aren’t async updates that impact the view considered side effects?

In fact, there’s actually a lot of things that can have asynchronous side effects, even calling “Ember.object.set” on a property bound to a template.

What am I missing here? Why does Ember think that one of these async operations warrants a run() but the others don’t? Is there a definitive list somewhere of what sort of async behavior is and is not considered a side effect? Is it “everything”? If so, why are some of my async modifications not throwing an assertion while others are?

Posts: 1

Participants: 1

Read full topic


Viewing all articles
Browse latest Browse all 4828

Trending Articles