3 ms·
Well with retained mode one still has to handle a bunch of application state, and handle keeping that state synchronised with the view. Immediate mode typically
by dan-robertson 8y ago
Well with retained mode one still has to handle a bunch of application state, and handle keeping that state synchronised with the view. Immediate mode typically forces you to manage the view state too but it’s typically easier to keep it synchronised with the application state that way.
I think the following is an interesting example here: your application state is some type, Config which would correspond to some boring components, e.g. text boxes and radio buttons, but the interface you want to present looks like:
[X] default settings
Or
[ ] default settings
...
Now the type of data you want by the end of the form looks like (eg Haskell)
Maybe Config
Where Nothing means “do the default thing”.
But the state of the view has to look more like:
Bool * Config
Because you want to remember what options the user had changed in case they change their mind a few times about using the default state. And now maybe you want a state like
(mutable) Bool * Config * (mutable) Config
Because the default state is not static and you want to make fields bold if they are not default. And so now you still have to do the complicated conversion from view to application state (but at least you don’t have to go back).
I suppose this is like the very early web dev style of having no direct state and directly reading values from controls, but at least in this world one has control over how the view state is managed and represented so it can be easier to avoid getting into invalid states.