3 ms·

Cases where "UI should be a function of state" seem like a small sliver of all use cases. Probably not worth the complexity for implementing directly in the br

Cases where "UI should be a function of state" seem like a small sliver of all use cases. Probably not worth the complexity for implementing directly in the browser. And there are plenty of conditions that just prohibit the pattern entirely as far as I can tell. Things where referential stability matters, like you have a contentEditable or allow arbitrary edits on a canvas.

deergomoo 4y ago
Personally I would argue that UI should always be a function of state. When it isn’t, you open yourself up to all sorts of inconsistencies and difficult edge cases. Of course, it’s not always that easy; having two sources for said UI (the HTML document itself and the JavaScript within it) certainly complicates matters.
- eyelidlessness 4y ago
  For what it’s worth, even using “vanilla” JS it’s generally much easier than it’s made out to be. It requires design discipline and knowing ahead of time what discipline to apply. But it’s pretty simple once you know it: - the UI isn’t a source of truth, it’s a computed interface to it - changes/interactions in the UI should update the source of truth, not other parts of the UI - the source of truth is fully responsible for managing and notifying dependencies of relevant changes Or much shorter: state and presentation are separate concerns. Once you have that, you can focus on the actual problems you’re trying to solve rather than the ones created by crossing underlying technology boundaries.
eyelidlessness 4y ago
> Cases where "UI should be a function of state" seem like a small sliver of all use cases. Maybe not “should”, but it’s an incredibly helpful mental model, and I can think of very few cases it can’t model correctly. It’s so helpful a model that it’s gained traction in Rust, Swift, Kotlin, Dart, Go. It’s the ~only model in Clojure and and literally the foundation of Elm. None of these cases, AFAIK, apply the model literally when they interface with inherently imperative APIs. They provide APIs expressing the model, and manage the imperative behavior on your behalf. This is ultimately how all functions in meaningful programming work. At the end of the day, allocating memory or displaying output is a side effect. This is also how you can have custom renderers like those used in ink, three-solid, even React Native. The code is modeled as a declarative function of state, implemented as a set of imperative behaviors corresponding to state and dependency changes. I’ve worked on contentEditable solutions in the past, probably more than most people who didn’t ultimately produce a library from the work (I went mad, literally angry at the complexity of making it a good UX, and gave up). I hope I never have that task again, but if I do… you can bet your ass I’d use a function of state model. It’s the only way I could reason about the problem without going mad.

deergomoo 4y ago

Personally I would argue that UI should always be a function of state. When it isn’t, you open yourself up to all sorts of inconsistencies and difficult edge cases. Of course, it’s not always that easy; having two sources for said UI (the HTML document itself and the JavaScript within it) certainly complicates matters.

eyelidlessness 4y ago
For what it’s worth, even using “vanilla” JS it’s generally much easier than it’s made out to be. It requires design discipline and knowing ahead of time what discipline to apply. But it’s pretty simple once you know it: - the UI isn’t a source of truth, it’s a computed interface to it - changes/interactions in the UI should update the source of truth, not other parts of the UI - the source of truth is fully responsible for managing and notifying dependencies of relevant changes Or much shorter: state and presentation are separate concerns. Once you have that, you can focus on the actual problems you’re trying to solve rather than the ones created by crossing underlying technology boundaries.

eyelidlessness 4y ago

> Cases where "UI should be a function of state" seem like a small sliver of all use cases. Maybe not “should”, but it’s an incredibly helpful mental model, and I can think of very few cases it can’t model correctly. It’s so helpful a model that it’s gained traction in Rust, Swift, Kotlin, Dart, Go. It’s the ~only model in Clojure and and literally the foundation of Elm. None of these cases, AFAIK, apply the model literally when they interface with inherently imperative APIs. They provide APIs expressing the model, and manage the imperative behavior on your behalf. This is ultimately how all functions in meaningful programming work. At the end of the day, allocating memory or displaying output is a side effect. This is also how you can have custom renderers like those used in ink, three-solid, even React Native. The code is modeled as a declarative function of state, implemented as a set of imperative behaviors corresponding to state and dependency changes. I’ve worked on contentEditable solutions in the past, probably more than most people who didn’t ultimately produce a library from the work (I went mad, literally angry at the complexity of making it a good UX, and gave up). I hope I never have that task again, but if I do… you can bet your ass I’d use a function of state model. It’s the only way I could reason about the problem without going mad.