4 ms·

> They do exactly the same as your `rerender` function here, it's just nicely hidden That's the whole point. React does this for you in the background. You don

> They do exactly the same as your `rerender` function here, it's just nicely hidden That's the whole point. React does this for you in the background. You don't have to think about it. > There will be no more of a mess of event listeners than you'd get using React. There will be more of a mess because you have to programmatically update elements. With React, I can alter global state and every single element that uses that state gets re-rendered. That isn't possible with this framework.

jeswin 6y ago
Re-rendering for state changes is a fairly easy thing to do, if you're willing to accept something like useState/setState. It can even be done application-side (without help from the lib). Basically, just wrap all state changes in setState and re-render everytime. Now the optimization I haven't done is deciding whether a child needs to re-render when a parent re-renders. Comparing the props seems like a straightforward way to do this, so I'll probably spend some time over it today and implement it soon.
- ZephyrBlu 6y ago
  Yep sorry, I misunderstood how your library works. I left another comment explaining what I misunderstood: https://news.ycombinator.com/item?id=25800961 https://news.ycombinator.com/item?id=25800961
ricardobeat 6y ago
You are programatically updating elements in React, you just internalized a different set of rules (putting state in the designated buckets vs calling an update function). It is the equivalent of this: const setState = (s) => { state = s; rerender() }; Real reactivity is what you get with proxies in Vue, or a smart compiler like Svelte. > I can alter global state ... that isn't possible with this framework You'd just need to export a state object from a module, import into the components, and call rerender after any mutation. I've actually written quite a few vanilla-js apps using this structure when I don't want to bother with tooling, small pages don't need a complex reconciler. I'm not saying this is better btw - there are ergonomic concerns and different trade-offs, but the distance from this to what React does is much, much shorter than most people think. We've just been conditioned to accept its rules as 'normal': don't declare plain variables in your functions, don't mutate properties, don't use inline functions as props, don't rely on previous state object for updates, and so on... step outside the box and you'll get a mess too. This library is just a smaller, different shape box.
- catlifeonmars 6y ago
  It’s not completely equivalent, since React avoids rerendering parts of the tree when the state has not changed (=== comparison). In some ways it separates the concern of rendering from state changes.
  - acemarke 6y ago
    The phrasing on that statement sounds a bit off, and I'm not sure whether it's a real misunderstanding of how React works or just the way the sentence is written. React re-renders components recursively by default. If I call `setState()` in a component halfway down the tree, React starts its rendering pass at the root component, then skips quickly down the tree until it runs a cross a component that's been flagged as dirty and needing an update. From there, it recurses down through all descendants of that component and re-renders them as well, regardless of whether those components have any queued state updates or whether there are any changes to their props. For more details, see my extensive post "A (Mostly) Complete Guide to React Rendering Behavior": https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/ https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...
- ZephyrBlu 6y ago
  I believe I have misunderstood how this library works, and I agree with what you're saying. At first glance I thought that rerender(args.element) referred to the element that the method containing rerender(args.element). Hence, I thought that if you altered global state in a component and called rerender(args.element) it would only rerender a single element and it's children rather than the entire component. Looking at the code more closely I see that args.element actually refers to the component, so the rerender function does do a full rerender.

jeswin 6y ago

Re-rendering for state changes is a fairly easy thing to do, if you're willing to accept something like useState/setState. It can even be done application-side (without help from the lib). Basically, just wrap all state changes in setState and re-render everytime. Now the optimization I haven't done is deciding whether a child needs to re-render when a parent re-renders. Comparing the props seems like a straightforward way to do this, so I'll probably spend some time over it today and implement it soon.

ZephyrBlu 6y ago
Yep sorry, I misunderstood how your library works. I left another comment explaining what I misunderstood: https://news.ycombinator.com/item?id=25800961 https://news.ycombinator.com/item?id=25800961

ricardobeat 6y ago

You are programatically updating elements in React, you just internalized a different set of rules (putting state in the designated buckets vs calling an update function). It is the equivalent of this: const setState = (s) => { state = s; rerender() }; Real reactivity is what you get with proxies in Vue, or a smart compiler like Svelte. > I can alter global state ... that isn't possible with this framework You'd just need to export a state object from a module, import into the components, and call rerender after any mutation. I've actually written quite a few vanilla-js apps using this structure when I don't want to bother with tooling, small pages don't need a complex reconciler. I'm not saying this is better btw - there are ergonomic concerns and different trade-offs, but the distance from this to what React does is much, much shorter than most people think. We've just been conditioned to accept its rules as 'normal': don't declare plain variables in your functions, don't mutate properties, don't use inline functions as props, don't rely on previous state object for updates, and so on... step outside the box and you'll get a mess too. This library is just a smaller, different shape box.

catlifeonmars 6y ago
It’s not completely equivalent, since React avoids rerendering parts of the tree when the state has not changed (=== comparison). In some ways it separates the concern of rendering from state changes.
- acemarke 6y ago
  The phrasing on that statement sounds a bit off, and I'm not sure whether it's a real misunderstanding of how React works or just the way the sentence is written. React re-renders components recursively by default. If I call `setState()` in a component halfway down the tree, React starts its rendering pass at the root component, then skips quickly down the tree until it runs a cross a component that's been flagged as dirty and needing an update. From there, it recurses down through all descendants of that component and re-renders them as well, regardless of whether those components have any queued state updates or whether there are any changes to their props. For more details, see my extensive post "A (Mostly) Complete Guide to React Rendering Behavior": https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/ https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...
ZephyrBlu 6y ago
I believe I have misunderstood how this library works, and I agree with what you're saying. At first glance I thought that rerender(args.element) referred to the element that the method containing rerender(args.element). Hence, I thought that if you altered global state in a component and called rerender(args.element) it would only rerender a single element and it's children rather than the entire component. Looking at the code more closely I see that args.element actually refers to the component, so the rerender function does do a full rerender.