uryga

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

how exactly is there "money to be made" here for the React team?

> Why did they not include other companies

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?

> RSC locks you into [Vercel's] hosting solution

how? you can self-host it if you want.

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

> zero functionality has been removed from class components

yes, exactly!

> They use them because they are idiomatic React

right, and do you think it'd be easy for a feature to become idiomatic if it wasn't an improvement over the previous patterns?

> TypeScript is a little unique in that its core type system is much more structural than nominal (even more so than Haskell)

I'm a bit confused by the point about Haskell here -- IME Haskell's type system is pretty strictly nominal, not a lot of structural typing there

thats what the rack is for duh

good luck! it's quite fun :)

another term that might be useful is "GADT" - it's kinda like a weaker form of DT, more easily expressible in, uh, normal languages. the C# one i linked is really more like a GADT, bc it all stays at the type level w/o bringing "normal" values into it. another way to do it would be a sealed class with a private constructor + static methods:

  class Foo<T> {
    private Foo(...)
    static Foo<int> Bar() { ... }
    static Foo<string> Zap() { ... }
  }

(or sth like that, i don't really do C#!)

so that way you can have the type param and use it to track something, but limit what can be put there - in this case, only int or string. type-safe syntax trees are a common case for sth like this (though in that case you'd probably go for an abstract base + subclasses, like in the link).

they allow as many operations as you need, just pass in a "method name" :)

  const p = Point(3, 5)
  p('getX') // 3
  p('up', 11)('toString') // "Point(3, 16)"


  const Point = (x, y) => (method, ...args) => {
    switch (method) {
      case 'getX': return x;
      case 'getY': return y;
      case 'toString': return `Point(${x}, ${y})`
      case 'up': return Point(x, y+args[0]);
      // ...
    }
  }

(unfortunately statically typing this statically requires... some work, either sth like [typescript overloads + literal types] or full on dependent types)

> 'useSyncExternalStore()' -- Gack!

> Now...that "little" it's-not-a-framework-it's-a-library whose scope is supposed to be confined to just the "view" part of MVC (by which I mean: "React") is inserting it's tentacles [...] into the _model_.

useSyncExternalStore doesn't care about what you do in your model. it's for connecting your view to your model in a way that doesn't give you inconsistent states when concurrent-rendering-funkiness happens.

you could even say that useSyncExternalStore exists because React maintainers want people to be able to use whatever state-manager they want (instead of useState/useReducer/whatever) -- uSES was necessary to enable that in 18.