Do a better job explaining when to use versus ember-concurrency. about ember-lifeline

[rwjblue]

FWIW, I am planning to work on an RFC for Ember to add a very specific "destroyables" API. I took an initial (though short sighted) crack at it in emberjs/ember.js#14602, but realized some short comings.

I think this could be a good starting point for sharing logic between ember-concurrency and ember-lifeline (both of which have logic to run through a list of disposables).

[machty]

They are quite similar in their intent and stated use cases. I think the potential for community fragmentation here is kinda worrisome so I'd definitely be interested in considering how they might be unified at some point in the future....

[machty]

@schickm Thanks for the feedback :)

I'd recommend disabling regenerator transpilation when you're doing local development work; this way you can debug against raw generator functions and avoid the messy switch statements. http://vanderwijk.info/blog/how-disable-es6-transpilation-emberjs-in-order-have-better-debugging-experience/

[schickm]

I've been using ember-concurrency throughout my application mainly for lifecycle checks, eg. if (! this.isDestroyed) {. In a few places I've utilized the various concurrency models it offers. One of the big downsides for me is the way e-c tasks are transpiled into giant switch statements. I've learned to read them just fine, but I worry about other members of my team balking at it when they crack open the inspector.

There are a few areas in my app where I'm synchronizing some remote api calls, and for that e-c really shines. I love the simple procedural code that I can write, and for that I'm happy to accept the cognitive overhead of debugging it in the transpiled source. However, when I'm just trying to cut down lifecycle checks, ember-lifeline seems like a great fit (I'm assuming it's transpiled output will be simplier...I have yet to actually try it out).

Additionally the testing helper sounds really nice. In my polling-style e-c tasks, I was going with the window.setTimeout method, which led to lots of nasty "check if we're in testing mode" conditionals throughout my code.

@machty Either way, e-c is an awesome addition to the ecosystem, and thanks for working on it 🥂

[sandstrom]

@rwjblue @machty Just out of curiosity, are there any plans to merge ember-lifeline and ember-concurrency?

Although there can definitely be value to experiment with different ways of solving concurrency issues, it feels like both these repots are way beyond the experimentation stage.

Also, this feels like something that could make it into Ember core at some point (or at least become blessed). In that case it would be neat if peoples contributions could be concentrated into a single addon/repo 😄

[machty]

(Rob and I are gonna be hashing this out over the next few days, but in the meantime...:)

I guess I'd like to hear from newcomers: if you heard about ember-lifelines and immediately thought "whoa, this solves a lot of problems/use cases in my app", why didn't / wouldn't have ember-concurrency struck you the same way?

[knownasilya]

I feel like they solve different issues. Mainly this addon removes a lot of the tediousness of getting third-party and existing Ember features working right, events and run loop/testing. e-concurrency on the other hand, solves async lifecycles in a way that this addon does not.

[blatyo]

I looked at it and thought that it was a wrapper over ember concurrency until I looked at the source. I'm pretty sure ember concurrency handles all these use cases, though it may be slightly more verbose. But, that verbosity allows greater flexibility.
I see it as ember concurrency is the Ember.computed helper and these are just specializations of that, like Ember.computed.alias.

[knownasilya]

For example, pollTask is a solution for http://ember-concurrency.com/#/docs/testing-debugging

[machty]

Possible e-c variant of tagged timer testing https://gist.github.com/machty/574457b1f2d993cc5959a1d6d6c74e5b

[linearza]

I agree I was a bit confused initially as to whether it was just explaining ember-concurrency or if it was a seperate addon. Possibly simply to the lack of installation instructions. Also, maybe worth adding that the mixins should be added manually for now, or atleast I had to. One thing that would make me rather use this is that it also as the event listener handling.

[sandstrom]

Answer to this question (above):

I guess I'd like to hear from newcomers: if you heard about ember-lifelines and immediately thought "whoa, this solves a lot of problems/use cases in my app", why didn't / wouldn't have ember-concurrency struck you the same way?

I've read abut ember-concurrency, and looked through the repo/docs. Probably ~2-3 months ago. I took note of it, and bookmarked it. But that was it. I'd say the biggest difference vs. spending ~5 min just now reading through ember-lifeline is that with lifeline I immediately realized how I would put it to work in our app.

With ember-concurrency I understand the types of problems it can solve, and I know we have some of them in our app, but it didn't feel super-easy to implement. With ember-lifeline it feels like I can spend just ~1-2 hours and get it into our app, eliminating some concurrency issues.

Also, I think ember-concurrency felt more powerful (and a bit more verbose), but I liked the simplicity of ember-lifeline.

Merry Christmas! 🎅

(I may have misunderstood ember-concurrency and/or ember-lifeline, but this is how I've understood the two)

---

An aside, it would be awesome if ember-lifeline's addEventListener could work without jQuery. We're slowly phasing out jQuery and try to avoid new things where jQuery is a dependency.

[knownasilya]

I've tried that, and haven't seen any improvement in the debugging experience. Maybe I'm missing something.

[machty]

@knownasilya you still see the switch statements?

[jamesarosen]

I have code that looks like

didReceiveAttrs() {
  this.pollTask((next) => this.get('doPoll').perform(next), 'my-component#doPoll');
},

doPoll: task(function*(next) {
  try {
    const result = yield something();
    this.doSomethingWith(result);
  } catch(error) {
    this.set('error', error);
  } finally {
    this.runTask(next, 1000);
  }
}

I'm not sure that's the best way to use these together, but it seems to work pretty well.

[sandstrom]

@rwjblue Sounds good! 😄

Has there been any other discussions around merging the projects?

Even in the case where they do completely different things (though I'm not sure that's the case), since both are solving issues around concurrency it may still be helpful for developers if they are under the same umbrella ☂️

Another path forward could be to take the good parts from ember-concurrency + ember-lifeline and consider a joint RFC for inclusion in Ember proper (of course that depends on whether you and others in the core team think this is something that belong in core).

Anyway, both are great addons! Just trying to help start discussions around a possible merger, since I think that may be beneficial to Ember developers! 🎉

[scalvert]

Just doing a bit of cleanup on issues in this repo. If this issue is closed in error please reopen!