RFC: injectToStream #219
RFC: injectToStream #219
Conversation
|
I agree about the problem statement and urgency. I considered this and intentionally excluded it from the MVP but doesn't mean it can't be added. The main thing that makes a hook like this less powerful is that I don't think features using it will be future compatible with new features that we have in mind. There are way more things we can do with SSR that we haven't discussed yet. We've also explicitly decided not to add something like this for Server Components. Therefore our focus has been on adding higher level replacements for each use case. I expect any solution using this to be temporary in the interim before we add new features that wouldn't work well with them anyway and until we add the higher level alternatives. That's not to say that adding this in the interim wouldn't be valuable. That's why we have things like useEffect in the first place. Tbh, not adding this is more of a prioritization of work - which effectively shifts the burden to others to deal with the intermediate step. This is unfortunate but the reality. Another proposal is to just have every SSR library add an API like this. Technically you don't need the React team to add this. It would require agreement and coordination but so would adding it to React. Each of them would just have to commit to an upgrade path. It just side-steps the React team as the bottleneck and maintainers. To get a sense for other RFCs coming that you can expect will touch of this problem space:
These would also work from Server Components. A notable missing one is CSS-in-JS that use dynamic None of this is to say that we can't/shouldn't add this but this is just why we haven't done it yet. If we do, it's urgent since it's more as an interim feature. |
|
Thanks for the insightful answer, I appreciate it. Ok, I see the reluctance because of potential future breaking changes, but the way I see it is that this RFC (or any alternative that enables library authors to inject to the stream) doesn't make the situation worse: React's 18 discussion board already recommends injecting tags to the stream such as style tags, data
The thing I'm worried about is the feasibility to align all SSR frameworks. If all SSR frameworks (Next.js, Hydrogen, ...) were to use Instead of all SSR framework agreeing on using We can expect SSR frameworks to spend time to implement their own
I see. So I guess it boils down to how we can design the interm solution so that:
Library authors (Telefunc, GraphQL, ...) can then use higher-level abstraction such as react-streaming to easily inject what they need to the stream, without worrying about framework integration. This RFC is a solution for 1. but I can't say if there is a better solution for 2. |
|
@brillout If we didn't do this and picked one higher level use case to prioritize. If you had to pick one use case, which one would you pick? |
|
This one:
By far. Simply because it's required to have suspended SSR boundaries. Without passing SSR data to the client-side, we cannot achieve suspended SSR boundaries for data fetching. Which defeats the purpose of SSR streams. These other use cases seem like low-priority nice-to-have optimizations:
As for:
I'm not all too familiar with Server Components, so I can't say. But since Server Components are not widely adopted yet, I'm thinking it's probably low priority as well. Also, I'm thinking maybe something like It seems to me that having Same for Let me know if you have questions, I'm happy to elaborate. |
|
Some initial work on the stylesheet case is being done in facebook/react#24886 |
👍 Also about the data fetching use case: https://github.com/acdlite/rfcs/blob/first-class-promises/text/0000-first-class-support-for-promises.md. I didn't read the whole RFC yet, but it seems like it completely replaces the need for react-streaming. That's neat. |
|
This is something we would really need in Apollo-Client to add good support for the new Right now, we are considering doing the following:
(Additionally, we also "snapshot" the return value of specific hooks to rehydrate them on the client side with the right value even if the client cache has already advanced to the future, but that's not relevant to this issue.) Our current approach has a few issues.
Is there any way for this to be reconsidered/reprioritized? |
|
Great write out and RFC! It does seem like an important omission from the React's streaming capabilities at the moment, and it seems to me (with my limited knowledge) like an antipattern for data-fetching library authors to have to fork special versions for each framework. The workarounds sadly aren't documented anywhere that I can see! Is there a safe way to inject to the stream with an intermediate stream? It doesn't seem that way to me right now as there's no guarantee that each of Reacts chunks are "complete" . Right now in Redwood, we will have to use the "ServerHtmlContext" workaround used in react-streaming and NextJS, but an indication from the React team of the direction we would be going in (and some idea if this is being prioritised) would be great. :) FWIW - we are looking at this without using RSC capabilities stand point at first - just streaming+ssr, before we move into the RSC world. |
View formatted RFC.