[Flight Fixture] Refetching #20316
[Flight Fixture] Refetching #20316
Conversation
facebook-github-bot
added
CLA Signed
React Core Team
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 208360e:
|
gaearon
force-pushed
the
refetch
branch
2 times, most recently
from
165f57d
to
314d0ae
Compare
|
|
||
| function refresh() { | ||
| setData( | ||
| ReactTransportDOMClient.createFromFetch(fetch('http://localhost:3001')) |
There was a problem hiding this comment.
Once we have it, this should use the client cache and it's the cache that gets reset.
However, even in that world this can be optimized by seeding the client cache with a new entry.
The idiomatic way would be to seed it with a response that comes from the same HTTP request as the mutation though.
That last part you can prepare for now even without a client cache. You just need to pass this in to the refresh function as an argument.
There was a problem hiding this comment.
Just to be explicit. The reason for this is not perf but eventual consistency. You can easily get into a state where you never see your mutation in prod because the propagation is always slower than immediately handling the next request. That's a really bad user experience and bad developer experience to only know about it once you hit prod.
| } | ||
|
|
||
| ReactDOM.render( |
| 'Content-Type': 'application/json', | ||
| }, | ||
| body: JSON.stringify({text}), | ||
| }); |
There was a problem hiding this comment.
You can have this fetch return a new Flight response. It means you'll have to hard code which Flight root entry point this corresponds to. That's kind of a hard problem for a router but it's good to indicate that it is a problem that's worth solving.
Adds basic Flight payload refetching to the fixture. Still no client cache.