4 ms·
> 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
by 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 agoWith 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.
- davorak 4y ago> 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. That is common now yes and I think that is a good think. Uncommon techniques, now, like storing data in the DOM, uncareful jquery usage, and I am sure other techniques can deny/break a pure functional relationship. The above is mostly historically why it is important and was not universal. How it ties into what schwartzworld said is that in react you ensure that the UI is a (pure) function of the state by default, no additional work. In signals you have to make sure to opt in every piece of state into reactivity. So I read schwartzworld's argument is that it is easier to keep(?) or at least produce the positive property of keeping the UI a pure function of the state with react than it is with signals because you do not have to do the work of opting in each piece of the state to reactivity.
- aatd86 4y agoI understand the purity constraint as the need for idempotency of the rendering function. Is that right?