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

Eating items in .all #28

Closed
paulyoung opened this issue Mar 3, 2015 · 8 comments
Closed

Eating items in .all #28

paulyoung opened this issue Mar 3, 2015 · 8 comments

Comments

@paulyoung
Copy link
Contributor

No eating of items should be done in .all() promise method since they all run in parallel we could easily get in the situation where we eat the same item twice.

Similar to #26. I think we should make this error out too.

@d4tocchini
Copy link
Member

@bergie, I thought we fixed this issue by attaching eaten content to the nodes? Subtrees will likely eat an item or a block, not being able to use such subtree in an all is a very strange limitation. Taylor is doing this now...

If this limitation is to remain, we will likely need another all composite promise that is synchronous.

@bergie
Copy link
Contributor

bergie commented Mar 4, 2015

@d4tocchini we do attach them, but only after the sub-promises resolve. Since JS is single-threaded, this would in effect makes the promises in .all run serially, not in parallel. So, in that sense it probably works.

@bergie
Copy link
Contributor

bergie commented Mar 4, 2015

Hmm... I think it actually works, but we'd need a test to prove it

@paulyoung
Copy link
Contributor Author

I added a (failing) spec for this in 322cd06.

@bergie bergie closed this as completed in 2d9117c Mar 6, 2015
@paulyoung
Copy link
Contributor Author

@cbchouinard: another docs update needed here.

@bergie
Copy link
Contributor

bergie commented Mar 6, 2015

Note: this only works as long as the tasks given to all are synchronous

@paulyoung
Copy link
Contributor Author

@bergie: could you clarify? I'm not sure what that translates to in the API.

@bergie
Copy link
Contributor

bergie commented Mar 6, 2015

@paulyoung currently we're running every component in flowerflip synchronously, and that allows eating in all to work since one task completes before the next starts. If the tasks were async, they'd all start at the same time, and wouldn't see what the others do. Not a concern for design systems (where everything will be sync), but something to keep in mind.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants