> the definition of an application’s UI as a pure function of application state
I presume "application state" means the stuff that the app cares about, and not the stuff that it doesn't.
But the app's actual, rendered UI incorporates state from multiple sources. For example, if you have a text field, it has "application state" like its positioning, "framework state" like where the text selection(s) are, "user state" like what size the user dragged it to, etc. And your "pure function of application state" necessarily discards this non-application state.
So then how does this state ever get preserved? The answer must lie in the "diffing algorithm:" the thing that determines what has changed, and attempts to reuse as much of the old UI as possible. A good algorithm will reuse an element and preserve its state. A naive algorithm will drop state and result in bad UI.
So in this model, aren't you taking a huge and hidden dependency on this diffing algorithm? What's the right way to ensure continuity of non-application state across updates?
As for optimizations ,
He mentions immutability , we already have that using Swift structs.
Then there's the differ
The diffing algorithm shouldn't be a one size fits all super algorithm but a collection of dumb components you can put together to get the perfect diffing behaviour for your particular use case.
The differ should also animate the state transitions appropriately where necessary.
> the definition of an application’s UI as a pure function of application state
I presume "application state" means the stuff that the app cares about, and not the stuff that it doesn't.
But the app's actual, rendered UI incorporates state from multiple sources. For example, if you have a text field, it has "application state" like its positioning, "framework state" like where the text selection(s) are, "user state" like what size the user dragged it to, etc. And your "pure function of application state" necessarily discards this non-application state.
So then how does this state ever get preserved? The answer must lie in the "diffing algorithm:" the thing that determines what has changed, and attempts to reuse as much of the old UI as possible. A good algorithm will reuse an element and preserve its state. A naive algorithm will drop state and result in bad UI.
So in this model, aren't you taking a huge and hidden dependency on this diffing algorithm? What's the right way to ensure continuity of non-application state across updates?