tgasson
Joined 14 years ago
Joined 14 years ago
For @defer, the transport is a stream[2] where subsequent payloads are tracked ("pending") and as those payloads arrive they are "patched" into the existing data at the appropriate path.
Both of these are effectively implementations of this Progressive JSON concept.
I can picture a future where both the JSX and object payloads are delivered progressively over the wire in the same stream, and hydrate React and Relay stores alike. That could potentially simplify and eliminate the need for Relay to synchronise it's own updates with React. It would also potentially be a suitable compile target for decoupling, React taking ownership of a normalised reactive object store (with state garbage collection which is a hard problem for external stores to solve) with external tools like Relay and TanStack Query providing the type-generation & fetching implementation details.
Using `new Promise()` in the client-side store would also mean you could potentially shrink the component API to this. `useFragment(fragment IssueAssignee on Issue { assignee { name }}, issue)` could instead be `const assignee = use(issue.assignee)` and would suspend (or not) appropriately.
[1]: https://github.com/facebook/relay/blob/main/packages/relay-r...
[2]: https://github.com/graphql/graphql-wg/blob/main/rfcs/DeferSt...
That can be easier since you can add metrics to each individual field rather than url, allowing you to deprecate rarely used fields knowing what you'll break and alert only those who are using it of the change
At some point later 5 mutated from looking like 4 to as it is now.
It's the same reauth you sometimes get when visiting a public blogger site. It is an edge case, but quite unpredictable and hard to track down from client reports.
Sometimes google will make already logged in users reauthenticate. It will redirect to the authentication page and you'll get a bunch of HTML rather than json returned, and the user won't know why it's not working.