RTK Query does something similar, offering multiple ways to initiate, update and use the data of the queries.
Here is some example code, and imo it‘s really greener than anything else.
async function getData() {
const res = await fetch('https://api.example.com/...');
if (!res.ok) {
throw new Error('Failed to fetch data');
}
return res.json();
}
export default async function Page() {
const data = await getData();
return <main></main>;
}They say there's a new `cache` function in React and they have patched `fetch` to use it by default (for GET requests).
Does this include a solution to the N+1 queries issue (container element requests a list of items, then item elements each request their details)? I see you can do pre-fetching, perhaps those can be batched.
EDIT: Found an example that uses DataLoader by "caching the cache". The src/api.ts module exports a cached DataLoader for characters, and src/components/CharacterAvatar.tsx imports and calls it during render simply like this:
const character = await characters().load(id);
- react being the most popular FE library for time to come
- gain the user's mindshare as react being now a Vercel product (something which is becoming increasingly true)
- users attracted by react and next eventually becoming Vercel customers.
They have also tried or employed several other major library authors in order to position themselves uniquely at the crossroads of major FE software and thus be uniquely positioned to transform those users again in Vercel customers.
I don't judge any of this negatively or positively but that's the case I see.
I remember they got Sebastian :-) Who else?
- at least 2 (top #2) works at Vercel
- at least 4 works at Facebook
Whom React got from InfernoJS
In the rest of the world, SEO is the main use case, e.g. Company X (some kind of retailer) has invested in an SPA (when what they needed was an enriched MPA) and then found they were loosing their search engine rankings. Either they:
1. Render that in a headless browser, cache the results, and serve that to crawlers (non-optimal as detecting bots is hard); or 2. Rewrite their new website to be properly architected (at cost); or 3. Buy into server rendering to serve both normal visitors and crawlers.
I worked at a company that had _exactly_ this journey. Don't forget the non-functional requirements when designing solutions, kids.
The best such codebase I can think of might still have been better off overall as an enriched MPA, but given how few normal pages it had compared to the app-ish bits - thereby making staying on a single technology stack a bigger advantage - I'm not quite willing to say it -definitely- would've been better as an enriched MPA. Not quite ;)
In philosophy, the first thing to understand a philosopher's thinking (make a model of his mind) is to read his work but the second is to read who are his influencers.
No field is truly neutral or deeply agnostic (except reality itself which is The Great Equalizer).
But it can lead to defining asynchronous workflows through the nesting of components, controlled by their mounting/unmounting and other state. I much rather have something like RTK Query which lets me both use it in a hook for simplicity and in Thunks or Sagas for more complex things.