State-based vs Signal-based rendering

(jovidecroock.com)

28 points | by mfbx9da4 5 hours ago ago

13 comments

  • yxhuvud 37 minutes ago

    > Traditional state management like React hooks

    Oh boy. The youth of the author is really visible.

  • zxspectrumk48 an hour ago

    This article is completely backwards. We do not want to manually manage what-gets-refreshed-when. The whole point of React was to react to state changes automatically.

    • jjj123 27 minutes ago

      I’m confused by your comment. Signals do reduce manual render management.

      By default, usestate causes unnecessary rerenders which signals avoid (all automatically).

    • agos 29 minutes ago

      that's the theory, but it's quite easy to end up needing to micromanage react to avoid pathological rendering scenarios

  • Aldipower 2 hours ago

    "Traditional state management like React hooks triggers..."

    Traditional? I remember when React was the new kid on the block. I am getting old! :-D

  • codedokode an hour ago

    I don't like the style of code in the article, with weird functions like "useState" and "useSignal". Looks ugly to me.

    Also, it seems that with signals you must use immutable values only. Imagine if you have, let's say, a text document model, and you need to create a new copy every time the user types a letter. That's not going to work fast. And there will be no granular updates, because the signal only tracks the value (whole document), not its components (a single paragraph).

    Also the article mentions rarely used preact and doesn't mention Vue. Vue can track mutable object graphs (for example, text document model). But Vue uses JS proxies that have lot of own issues (cannot access private fields, having to deal with mixing proxies and real values when adding them to a set, browser APIs break when a proxy is passed).

    Also I don't like that React requires installing Node and compilation tools, this is a waste of time when making a quick prototype. Vue can be used without Node.

    • Jaxan an hour ago

      Immutable does not mean you have to copy the whole structure. You can store only the changes. This is how immutable data structures work in functional languages such as Haskell.

    • AlienRobot 41 minutes ago

      React is crazy because someone thought this was too complicated for developers:

          event.listenTo(render);
          event.emit();
      
      And that we should do this instead:

          property.listenTo(render);
          property.set([property.get()[0]]);
  • pingoo101010 2 hours ago

    Preact signals are far superior to other state management patterns for react, but don't use a ContextProvider as shown is this article, pass the signals as props instead.

    e.g:

      function MyComponent({ disabled }: { disabled: Signal<boolean> }) {
        // ...
      }
  • jzig an hour ago

    Are Angular signals the same as Preact signals?

    • shoemakersteve 2 minutes ago

      I can't say as I'm not familiar with Preact signals, but I do know the Angular team brought on the author of SolidJS to implement signals in Angular. Though I think I remember reading at some point that Preact signals were essentially directly ported from SolidJS, so they're likely similar if nothing else. (Someone correct me if I'm wrong)

  • hhthrowaway1230 2 hours ago

    knockout js is that you?

    • rivetfasten an hour ago

      I was about to mention this too.

      Compare: "import a specific lightweight library and wire together as needed" vs "write the whole app in terms of a bloated framework".

      I've been out of the frontend game for a while, but what does react give you that knockout and maybe some url management logic do not?

      I guess components are supposed to standardize modularity, so you can easily import some random widget?