Hacker News Reader

Comment by riogordo2go | Hacker News Reader

   "I don't recommend having components responsible for querying data because their responsibility is already in presenting the data. More accurately, components need only receive data from view models, format it, and output it to the screen. Instead, I advise you to follow either of the three following ways:

  Render the data on the server and pass it to components as a view model, as shown in this guide.
  Use a state management library that supports dispatching actions (e.g. Redux or MobX), deriving view models from the state, and passing them to components as properties."

This is opposite to what Next.js new React Server Components stuff is advocating for in the new app/ dir structure. It expects every component to fetch the required data, and just cache any duplicate calls. It's probably good for a Serverless / Edge deployment but I much rather use a MobX store that takes care of state, fetching and mutations.

View on HN

This is probably very tinfoil-haty, but I can't help but wonder how much of this recommendation is a perverse incentive to sell edge compute on Vercel's platform. In general I am very wary of VC-funded open source, like Next.js.

They poached pretty much the entire react team in order to bet on:

- 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.

This is just a meme, an overwhelming majority of the React team ar still at Meta.

A very large chunk of the longest serving and more important jumped ship though.

More important? Or more famous?

> They poached pretty much the entire react team

I remember they got Sebastian :-) Who else?

Grabbing contributions (commits specifically) between Dec 20, 2021 – Apr 15, 2023 and looking at the workplace of authors (first #20) it seems:

- at least 2 (top #2) works at Vercel

- at least 4 works at Facebook

Edit: but this is just commits for facebook/react, reality might look differently :)

Andrew Clark just moved over to Vercel. I believe they also got Dominic Gannaway, who used to work on the React team, although he said he'll be working on Svelte compiler stuff now.

> Dominic Gannaway

Whom React got from InfernoJS

I don't think Dominic ever stopped working on Inferno

Dominic is going to work on the Svelte team at Vercel according to his Twitter. https://twitter.com/trueadm/status/1640761270566633472?s=20

Honestly I don't see a large use case for React Server Components, to me it's really more of a way to woo those that were still adamant about server rendering. I can see it being very useful in some specific instances, but for the most part I still advocate that one build a React site the way they always have.

Facebook has their own internal use cases (they talked about it at some show and tell when they over-hauled the FB design a few years back).

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.

If you buy into server rendering before you write a single line of code and understand it's a trade-off it turns out to be only mildly unpleasant in practice.

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 ;)

I don't see any tinfoil-hatness in exposing the incentives that are in place of every opinator.

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).

Vercel also employs Rich Harris the creator and driving force behind Svelte and Sveltekit. I highly doubt these are top down decisions to pump usage of Vercel’s platform. Nothing forces users to use Vercel at all.

I came from a centralized store background — and honestly I'm falling in love with the decentralized data responsibilities. Between React Query (fetch batching & caching) and Jotai (decentralized state) I love that every component can just take care of itself. No more prop-drilling, everyone just declares their dependencies and takes care of their own.

That sounds like absolute hell to dig through once you hit N+1 queries.

Yeah, this is the kind of thing that seems elegant and convenient when the requirements are simple, but completely falls apart as soon as any complexity is involved.

This tracks for me as well. Very quickly, you start having to manage 10, 15, 20, or more places where data in a store is being manipulated from outside the store and it quickly becomes unmanageable on anything beyond a toy-sized application. It almost feels like a rite of passage to decentralize like that and then start to pull back when it becomes a nightmare to debug and maintain.

That's the purpose of the in-app request caching layer. Another way to see it is that you do have state in a separate store, it's just that you have one piece of state for each resource that can be requested. So it's not that all the components are requesting the /users resource, it's more that all the components a requesting the value of the /users store, and the /users store fetches the data once and determines whether the data is loading, present, needs to be updated, etc.

That caching layer sounds like a footgun.

RTK Query does something similar, offering multiple ways to initiate, update and use the data of the queries.

It all sucks. The grass is not greener on the other side. Just wait for the usEffect hell that awaits you.

If you end up with useEffect hell, you are coding wrong. As OP said: it deduplicates and caches requests, there is no need to use useEffect.

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>;
  }

Where's the caching in this example?

Handled under the hood by Next 13. To be honest, they probably could have done something to make that a bit more obvious when looking at the code - it probably wouldn't hurt to throw in a simple 'cache' keyword or something.

This is the documentation I could find although it's not for 13 but Beta: https://beta.nextjs.org/docs/data-fetching/caching

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);

https://github.com/AndrewIngram/next-rick-morty

Ok, and how does this work when I need actual client side interactivity?

The problem is the moment you need to do complex combination and computation from multiple async sources, it's game over. It's the repeating of the history of flux -> redux back then all over again. Further more, what happens when you need to share this computation across multiple components?

For all of that: Jotai

Yes the point is that in this case the complexity is not by choice. If u have the business needs then u have to deal with them

Right, you put the complexity inside the Jotai

Separation of concerns is nice

Something like React Query and other hooks based approaches are fine and very useful for certain scenarios. At the end you always need a hook (or something very similar).

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.

That sounds to me like it'd cause all sorts of trouble in the real world (authentication, changes to endpoint URLs, difficulty to agglomerate data), and not surprisingly the Next.js documentation states `For now, if you need to fetch data in a Client Component, we recommend using a third-party library such as SWR or React Query.`

Reply on news.ycombinator.com