> AFAIK there's no magic to React.memo. It's basically a shorthand for useMemo that takes the props as the dependency.
Pedantic note: this isn't quite true. memo() also allows a second `arePropsEqual` argument that useMemo doesn't have. Also, memo() compares individual prop values, while useMemo() can only look at the whole props object (which would be "fresh" on every render -- it's a diffferent object, even if it has the same values). So it's not like you can easily reimplement memo() via useMemo(). But of course, conceptually they are pretty close :)
> “Also, memo() compares individual prop values, while useMemo() can only look at the whole props object”
Passing “Object.values(childProps)” as the dependency array for useMemo should do the same thing.
But yeah, there are good reasons to use React.memo for convenience with props. It’s not fundamentally different though, and you can definitely useMemo() for caching components when more convenient.
AFAIK: the initial stages of the project involved Vercel and Shopify [edit: and Gatsby]. these companies maintain frameworks and hosting solutions for them, which makes them good partners to work on full-stack features like this. notably, the convention ("use client") came about based on early feedback from Shopify.
the reason to work with framework authors first is that RSC requires a high degree of coordination/wiring across client code, server code, and the bundler. React itself only implements a couple of low-level primitives that need to be wired together by something like a framework to actually do anything useful
> expecting all third-party packages, React-related or not, to buy into the "use client" directive
AFAIK: non-react code has no reason to care about this directive. and on the react side, couldn't you make the same complaint about most breaking changes?
> But their routing things locks you into NextJS as a framework.
I'm confused by this -- how is a framework supposed to offer routing in a way that doesn't "lock you in"? are you "locked into" React Router if you use that? what's the alternative?
> are you "locked into" React Router if you use that?
Every dependency if large enough has lock-in. The problem with NextJS is how coupled everything is. In NextJS if you decide to stop using it you need to also rewrite your routing. React-router doesn't care about your bundler, or your deployment flows or your use of RSC, etc.
> I would like to write a component, not have to think about where it is running in most cases
you can keep doing this, just put "use client" in the file, Next will SSR them just like it used to. (SSR is an "emulated client" in this model. admittedly, the naming is a bit confusing)
but for some things, you want a guarantee that it only runs on the server, and then you can use server components :) i believe this is also why useState & friends are disallowed there -- they fundamentally don't make sense for stuff that'll only ever run server-side.
have you seen https://vite-plugin-ssr.com/ ? i've only browsed their docs, but AFAICT the pitch is that it's a more DIY approach to a framework, where you keep a lot of control over how things are wired together.
Love this. I've always thought we needed "metaframeworks" for JS. The ground shifts too quickly on things like state management, routing, styling, etc. to be locked into a single library.
> Apps (as in, mobile apps) cannot be rendered on the sever
yes and no. sure, you can't do standard SSR like for websites. but i've seen a number of spins[1] on "Server-driven UI", meaning "server defines the app views as a big blob of JSON". usually, it's payload looking something like this:
the app "interprets" this and displays the corresponding components in the specified arrangement.
the kicker is that, in a sense, RSC is just a less ad-hoc way to do this kind of thing! instead of `type` tags you get "client references", React handles the relevant parsing/serialization, and a lot of other good stuff on top. it's also quite seamless w.r.t writing components -- react does a very good job of abstracting away all the serialization business. and importantly, you can have an actual ecosystem of RSC packages around it, which a bespoke in-house method of doing this won't have.
now, RSC for react native has barely even been teased, but i'll bet good money that they have at least a prototype somewhere. and yeah, of course this would require your app to be in React Native. but that's the selling point -- IF all your stuff is in react, you get a bunch of power and some good DX.
Pedantic note: this isn't quite true. memo() also allows a second `arePropsEqual` argument that useMemo doesn't have. Also, memo() compares individual prop values, while useMemo() can only look at the whole props object (which would be "fresh" on every render -- it's a diffferent object, even if it has the same values). So it's not like you can easily reimplement memo() via useMemo(). But of course, conceptually they are pretty close :)