5 ms·

Signals and hooks are solving different problems. React was designed to allow you to think functionally about UI. Your UI should be a pure function of your sta

Signals and hooks are solving different problems. React was designed to allow you to think functionally about UI. Your UI should be a pure function of your state. This has always been the goal. All your code runs on every render unless you specifically tell it not to. Signals are the opposite. A solidJS component runs once, and only the reactive bits ever update. You have to opt into reactivity instead of opting out of it. The post gives an example of an unintuitive use of hooks, but misses the point. Yes, it's a tricky use case, but the ability to write custom hooks means you need to solve this problem once per codebase at most. The author's "kludgy" solution just needs to be put in a `useTimeout` hook (https://usehooks-ts.com/react-hook/use-timeout https://usehooks-ts.com/react-hook/use-timeout). The kludge shouldn't live in the component. There are some weird cases when you rerender the whole world whenever state changes, but there are plenty of weird cases that it prevents. React's model encourages treating variables immutably and preferring pure functions for modeling your domain. This is hard, because it's not how most JS devs learn to write code before coming to React. But knowing that the whole world is going to rerender gives you tremendous certainty in other areas. Depending on how complex and reactive your UI is, maybe signals would work for you, but if most of what you see on the page is reactive, I'd probably prefer the React model.

mpweiher 4y ago
> Your UI should be a pure function of your state. Except this has always been BS, and IMHO this fundamental inconsistency at the heart of the model is why the wheel has to keep on turning. https://blog.metaobject.com/2018/12/uis-are-not-pure-functions-of-model.html https://blog.metaobject.com/2018/12/uis-are-not-pure-functio... (Read to the end...) https://github.com/reactjs/react-basic/pull/12 https://github.com/reactjs/react-basic/pull/12
- haspok 4y ago
  > "Except for games, UIs are actually very stable, more stable than the model. You have chrome, viewers, tools etc. What is a (somewhat) pure mapping from the model is the data that is displayed in the UI, but not the entire UI. So if we don't make the incorrect assumption that UIs are unstable (pure functions of model), then we don't have to expend additional and fragile effort to re-create that necessary stability." I think this could be the key takeaway from the linked article. It hits the nail on the head, on the other hand though, pure functions are _really_ nice, so I believe in the future development of UI frameworks will congregate in that direction, but in a more fine-grained way than React et al.
  - mpweiher 4y ago
    > on the other hand though, pure functions are _really_ nice Yes, and therefore it would be really nice if they were an appropriate model here. But they're not. It would also be really convenient if π were 3, but it's not, and pretending that it is 3 just doesn't give you good circles. https://en.wikipedia.org/wiki/Streetlight_effect https://en.wikipedia.org/wiki/Streetlight_effect
azangru 4y ago
> Your UI should be a pure function of your state. I think you are mixing metaphors here. An ideal React component was supposed to be a pure function that takes in props and spits out a piece of UI. This ideal has never been reached, or even within reach, because once you introduce component state, you lose the purity of your function — its output no longer depends solely on the input (which is what defines a pure function), but can vary depending on the internal state. When, however, you say that "your UI should be a pure function of your state" (and when we bracket out the word 'pure' that we addressed in the previous paragraph), then signals are just as good a a way to achieve this as hooks are, or React class components were. You modify your state; some code runs; your UI gets updated to reflect the latest state of your state; voila, the UI becomes a function of the state.
- davorak 4y ago
  > Your UI should be a pure function of your state. I have seen this expressed elsewhere and and how schwartzworld is using it seems to be the common usage and makes sense to me. So if my UI, the DOM on a page, should be a pure function of your state then that means when I input the same state to my function I should always get the same DOM on the page. So if my complete state can be represented by { x: 10, s: 'hi there' } and the resulting DOM can be expressed with nonsensical <div>10 hi there</div> it does not matter what gyrations/changes the state goes through as soon(baring rendering delays or optimizations) as it is { x: 10, s: 'hi there' } then the DOM can be expressed with <div>10 hi there</div>. > your UI gets updated to reflect the latest state of your state; voila, the UI becomes a function of the state. I read what you wrote here as expressing the same idea.
  - azangru 4y ago
    With this interpretation though, the statement about the UI being a (pure) function of the state loses any concrete meaning. Because what you are in fact saying is that you just want your UI to be in sync with your state. Which any framework will give you, because being out of sync with your state means that your app is broken; and it is the purpose of any framework in existence to help you prevent your app from breaking.

mpweiher 4y ago

> Your UI should be a pure function of your state. Except this has always been BS, and IMHO this fundamental inconsistency at the heart of the model is why the wheel has to keep on turning. https://blog.metaobject.com/2018/12/uis-are-not-pure-functions-of-model.html https://blog.metaobject.com/2018/12/uis-are-not-pure-functio... (Read to the end...) https://github.com/reactjs/react-basic/pull/12 https://github.com/reactjs/react-basic/pull/12

haspok 4y ago
> "Except for games, UIs are actually very stable, more stable than the model. You have chrome, viewers, tools etc. What is a (somewhat) pure mapping from the model is the data that is displayed in the UI, but not the entire UI. So if we don't make the incorrect assumption that UIs are unstable (pure functions of model), then we don't have to expend additional and fragile effort to re-create that necessary stability." I think this could be the key takeaway from the linked article. It hits the nail on the head, on the other hand though, pure functions are _really_ nice, so I believe in the future development of UI frameworks will congregate in that direction, but in a more fine-grained way than React et al.
- mpweiher 4y ago
  > on the other hand though, pure functions are _really_ nice Yes, and therefore it would be really nice if they were an appropriate model here. But they're not. It would also be really convenient if π were 3, but it's not, and pretending that it is 3 just doesn't give you good circles. https://en.wikipedia.org/wiki/Streetlight_effect https://en.wikipedia.org/wiki/Streetlight_effect

azangru 4y ago

> Your UI should be a pure function of your state. I think you are mixing metaphors here. An ideal React component was supposed to be a pure function that takes in props and spits out a piece of UI. This ideal has never been reached, or even within reach, because once you introduce component state, you lose the purity of your function — its output no longer depends solely on the input (which is what defines a pure function), but can vary depending on the internal state. When, however, you say that "your UI should be a pure function of your state" (and when we bracket out the word 'pure' that we addressed in the previous paragraph), then signals are just as good a a way to achieve this as hooks are, or React class components were. You modify your state; some code runs; your UI gets updated to reflect the latest state of your state; voila, the UI becomes a function of the state.

davorak 4y ago
> Your UI should be a pure function of your state. I have seen this expressed elsewhere and and how schwartzworld is using it seems to be the common usage and makes sense to me. So if my UI, the DOM on a page, should be a pure function of your state then that means when I input the same state to my function I should always get the same DOM on the page. So if my complete state can be represented by { x: 10, s: 'hi there' } and the resulting DOM can be expressed with nonsensical <div>10 hi there</div> it does not matter what gyrations/changes the state goes through as soon(baring rendering delays or optimizations) as it is { x: 10, s: 'hi there' } then the DOM can be expressed with <div>10 hi there</div>. > your UI gets updated to reflect the latest state of your state; voila, the UI becomes a function of the state. I read what you wrote here as expressing the same idea.
- azangru 4y ago
  With this interpretation though, the statement about the UI being a (pure) function of the state loses any concrete meaning. Because what you are in fact saying is that you just want your UI to be in sync with your state. Which any framework will give you, because being out of sync with your state means that your app is broken; and it is the purpose of any framework in existence to help you prevent your app from breaking.