Generated by 🚫 dangerJS

I can confirm that this, or something like it, will be essential for future React use with subscriptions. Will do a more in-depth review of the implementation later, but so far looks good and fits with all our learning from updating Relay.

I also put it on the agenda for team sync. tomorrow.

Cool! I like the idea of providing an foolproof way to do subscriptions in async.

Some concerns:

• We should try to avoid making it too easy to use subscriptions in cases where another pattern is more idiomatic. For example, one of the uses of subscriptions today is as a workaround for context (parent-child communication). For those cases, you shouldn't use subscriptions—you should use the new context API. If you're integrating with an external data source, subscriptions are probably the way to go, but you still want to avoid having multiple components subscribe to the same source, and instead subscribe once and use the new context API to share the value throughout the tree. Maybe there's a way we can integrate this into the new context API directly so people aren't tempted to oversubscribe.
• I question the necessity of supporting multiple "subscribable types." An alternative is to expose a generic interface and leave it to users to integrate it with their preferred async primitive. I like that you've proven that this can work with DOM events and observables, but if we provide first-class support for some primitives, inevitably people will ask us to add support for their favorite library. And there are so many: RxJS, most, kefir, xstream, callbag... @gaearon and I faced a similar problem with Redux three years ago (wtf how has it been that long), which is why we decided on the middleware design: keep the core API surface area small and easy to maintain, and let others build abstractions on top of it if they desire. [Edit: Oooooops, ignore this second bullet: it looks like this exactly what you've done :D I misunderstood the issue description.]

Thanks for the feedback, @acdlite!

Totally agreed with your second bullet point! I had that same concern based on past experiences with open source libs. 👍

As for your first concern, I'm on the fence about the best way to handle it. On the one hand, I want it to be as possible- but I hear your concern about encouraging people to use subscriptions in lieu of context.

Maybe there's a way we can integrate this into the new context API directly so people aren't tempted to oversubscribe.

I could export another HOC that ties into the context API, if you think it would be worth doing? It wouldn't be much extra code.

I've updated the README with an API overview and some basic examples for event dispatchers and RxJS. I'd like to add more examples as I think of them. (Ideas welcome!)

I also added documentation and a test for native Promises, although it's a bit clunky. The lack of a way to "unsubscribe" could also result in memory leaks as long as something has a reference to the old Promise, but I think it's still worth documenting how they could be used. (I'm open for feedback here as well of course.)

Just an FYI (in case I lose connectivity in the air) - as soon as I'm done writing more tests, I'm going to update this helper to only use the HOC approach for functional components. For class components, I'll use an "ES6 mixin" approach to retain ref compatibility and avoid the overhead of an additional fiber.

Thanks, everyone, for the valuable input 👋

Since the source branch got deleted might want to edit first post to lead to https://github.com/facebook/react/blob/master/packages/create-subscription/README.md

Done 👍