Async streaming data updates (eg Flux)

[ericclemmons]

Async streaming data updates (eg Flux)

[jesseskinner]

I also realise there are nice benefits to a resolution that only resolves once, and rendering that is delayed until resolution completes. So maybe this "streaming" concept is outside the scope of react-resolver?

[ericclemmons]

Hah! My Internet went out why you replied.

Yes, you're correct. The props should only be resolved once and not mutate. For one, React won't allow this, unless the parent component updates the prop. Otherwise, that's what state is for.

See the "Counter" example:

http://facebook.github.io/react/tips/props-in-getInitialState-as-anti-pattern.html

But, it means that we should come up with a test-case where the prop may be different with each resolution to ensure the behavior is correct (I think it is, but need to confirm).

[jesseskinner]

Yes you're right, it makes a lot of sense to only resolve "props" once but use "state" for ongoing changes.

solve may not be a great solution in its current state then, as it does allow for open-ended "streaming" callbacks, and it also calls its own callbacks multiple times, once for each promise resolution. So it's hard to tell if all the promises have resolved.

I'd considered adding some API to solve to check if the resolution is "done", ie. all callbacks called, all promises resolved, all static data available. It seems this is necessary if react-resolver is going to use it, so it knows when to resolve the "handle" promise.

[ericclemmons]

I would like to use it, but, since it is an implementation detail, perhaps we can answer the hard questions for this project & the API first (particularly around errors!), that way we can ensure both projects are in sync.

solve would be pretty useful for state, it seems. Do you not need stores anymore, since resolutions can keep happening?

[jesseskinner]

Yep, many of my stores were just assembling promise results into an object, so solve replaces most of these.

I agree, using solve is an implementation detail, more important to nail down the API challenges with the current resolution.

[ericclemmons]

I <3 collaborating!

I was going to do another, more complex example with alt. Should I consider Hoverboard as well?

[jesseskinner]

Sure, up to you. They're pretty similar, Hoverboard is a bit simpler so might make for an easier example.

[ericclemmons]

I've been wrapping my head around this for v1, and it seems this logic is best suited for stores/actions.

[jesseskinner]

Agreed. I've come to see "resolution" as something that needs to happen once and be done, that other streaming types of data (eg. chat) should use a different mechanism for updating and re-rendering.

[ericclemmons]

Since Facebook's dispatcher has an architectural limitation (1 action per dispatch) on a project, I'm wrapping this project's <Container /> with a "store" that's tracking updates/state, which re-renders the container with new props that re-fetches things.

For streaming, you'd obviously want something different, but this concept is working well for our needs.

[gilesbradshaw]

I've started a branch using csp channels rather than promises with the idea that the server will wait for at least one message and then the client will carry on listening for messages. I'm thinking these channels could be linked to various things - such as updates from flux but also websockets. Rxjs was another option.

https://github.com/gilesbradshaw/react-resolver/tree/csp

[iamdustan]

❤️ that idea. Looking forward to hear how the csp approach works out.

[gilesbradshaw]

I'm thinking it's a more general approach as promises could be fitted into it converted to channels that just have one message.

[ericclemmons]

@gilesbradshaw I'm not very familiar with CSP. The biggest issue was knowing when the entire tree is "done". Is that still possible?

[gilesbradshaw]

Nor am I! :P But yes it is/will be at work right now but will reply in more detail later