🗺️ Enhance and Dedupe Loaders #7768
Replies: 8 comments 22 replies
-
If I understand this correctly, you mean if two loaders return the same value (e.g. both return |
Beta Was this translation helpful? Give feedback.
-
|
Correct. Anything primitive in the body is deduped. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, this alone is amazing 🤯 |
Beta Was this translation helpful? Give feedback.
-
|
I imagine this will be critical for RSC where it will be really common for server components to send duplicated data to client components, and paired with support to revive more than JSON will mean props are going to be correct. |
Beta Was this translation helpful? Give feedback.
-
|
I want to explore implementing the flatten concept in the React codebase in-place of their current data format for this reason. |
Beta Was this translation helpful? Give feedback.
-
|
Will this allow to send promises that are not in the root of the response? So instead of always doing |
Beta Was this translation helpful? Give feedback.
-
|
Yes, including subsequent promises in resolved values. So the following type signature would transport properly: type Example = [
Promise<{
sub: Promise<Date>
}>
] |
Beta Was this translation helpful? Give feedback.
-
|
Have you tried using ReadableStream? If I could pass a ReadableStream from a loader I could later do this trick Vercel did for their AI SDK where a component suspended until the reader promise is done and then keep doing this until the stream is completed, this https://x.com/shuding_/status/1681373460860108810 |
Beta Was this translation helpful? Give feedback.
-
|
You don't need to be able to serialize the readable stream for this. Could just do a data structure like so: type Data = { id: string; msg: string }
type StreamingData<T> = {
data: T;
next?: Promise<T>;
}Might be what you meant though. |
Beta Was this translation helpful? Give feedback.
-
|
The readablestream would have to be a detail the loader knows about and the recursive data structure would need to be returned from the loader. |
Beta Was this translation helpful? Give feedback.
-
|
Oooo, so you could send an arbitrary array of Promises for use with |
Beta Was this translation helpful? Give feedback.
-
Is this something that will remain this way? While I have enough with all the things |
Beta Was this translation helpful? Give feedback.
-
|
It could be opened up in the same way devalue is done if we decided it was necessary. |
Beta Was this translation helpful? Give feedback.
-
|
I'm made the underlying turbo-stream lib support plugins for custom use-cases for now. |
Beta Was this translation helpful? Give feedback.
-
|
About sending Error instances, will this work with custom errors? E.g. |
Beta Was this translation helpful? Give feedback.
-
|
The current way it's implemented is:
|
Beta Was this translation helpful? Give feedback.
-
|
so we should make the |
Beta Was this translation helpful? Give feedback.
-
|
Correct |
Beta Was this translation helpful? Give feedback.
-
|
I think it’s a good enough trade off |
Beta Was this translation helpful? Give feedback.
-
|
Let me follow up here. You'd have to expose the class as a global, and the only param it accepts in it's constructor be an error message string. I just implemented a pluggable system in the |
Beta Was this translation helpful? Give feedback.
-
|
As you've written, the serialization of date objects are one of the more significant issues. However most people don't use the built in types for dates and use luxon / date-fns. It would be good if we could configure this to use one of those library's data types (in my case luxon) |
Beta Was this translation helpful? Give feedback.
-
|
This is about the transport of data, not format or display. If you want formatted dates, format then on the server and return a string. |
Beta Was this translation helpful? Give feedback.
-
|
Its more of a timezone problem than a formatting problem. Typically you send and receive information in utc (as per luxon documentation https://moment.github.io/luxon/#/zones). So you create luxon objects server side, use those to compute information in the loader and then they get sent to the client which recreates the objects for formatting purposes So being able to transport the luxon object would be helpful. Just as sergio said above about sending custom types. |
Beta Was this translation helpful? Give feedback.
-
|
Could you expand on how you'd expect that library to interact with the data transport layer? From what I gathered you'd use that lib, and then toString() it before sending it to your view layer (i.e, before you return from your loader). |
Beta Was this translation helpful? Give feedback.
-
|
I think one of the biggest pain points for dates being sent is figuring out a way to serialise them for the client to all regions. There have been multiple times where a date created on the server results in a date on the client being a few hours off of the clients local time due to servers being hosted in different locales and or the load balancers themselves. Would this proposition be able to tackle some of these issues? |
Beta Was this translation helpful? Give feedback.
-
|
Epic Stack has put together some nice tools for solving this directly. |
Beta Was this translation helpful? Give feedback.
-
|
Could you expand on how you'd expect a data serialization layer to tackle time zones? |
Beta Was this translation helpful? Give feedback.
-
|
For everyone focused on dates, this get's you a real Date object that matches between SSR and CSR allowing you to avoid toString()ing it, and format it properly in the browser based on your users client hints. I don't see a way for this to handle dates much better than that, as how to format / display is a "you" decision, not one I can make at this layer. If I'm missing something, let's try to consolidate thoughts / explanations focused on Date concerns in this thread. @moishinetzer @StevenBendell |
Beta Was this translation helpful? Give feedback.
-
|
After doing some further reading, I found there's a proposal for a new standard object that fixes all of Date's issues (that close to stage 4, their blocker just got unblocked): I think just adding this type when its added to EMCAscript would be a good solution. Using Date object is good for now. |
Beta Was this translation helpful? Give feedback.
-
|
this RFC reminds me of this issue for React with RSC -> facebook/react#25687 |
Beta Was this translation helpful? Give feedback.
-
Proposal Overview:
defer()utility.Contextual Background:
Presently in Remix, the loader and action return values are bound to only those that are JSON serializable. This constraint has inadvertent repercussions, notably the conversion of Date objects to Strings when transmitted across network boundaries. Additionally, this results in data redundancy within the initial remix context serialized for HTML document hydration.
Beyond the JSON serializable restriction, the
defer()utility was introduced to accommodate Promises as root object key-value pairs. While this provides the convenience of showcasing a loading state and transmitting data that might be slower to load at a later interval, it doesn't cater to subsequent promises on the resolved value or scenarios like arrays of promises.Detailed Proposal:
The current approach employs a HTML-safe
JSON.stringify()for the remix context and for ferrying loader data to the browser. The proposed methodology adopts a variant of Rich Harris's devalue, specifically the turbo-stream library to efficiently "flatten" values. This process not only ensures deduplication but also seamlessly incorporates data types like Map, Set, Promise, and others.A key distinction between "devalue" and "turbo-stream" is the latter's capability to handle Promises by rendering directly to a WebStream.
Moreover, "turbo-stream" is not designed to be extensible.(I was very quickly talked out of this by my own use-case outside of Remix and others below).Leveraging "turbo-stream" for encoding the remix context would yield automatic deduplication across route loaders and within the internal remix context. This also presents an opportunity to replace the defer() function, eliminating the need for distinct response formats for client-side loader invocations.
Steps
text/remix-deferredwithturbo-streamfor a client initiated navigation to a deferred route.turbo-streamas format inlined in HTML responsedefer()Beta Was this translation helpful? Give feedback.
All reactions