17 ms·

It's Backbone. A pure state -> DOM function is also called a template. It works when the app is simple. The problem is that you do NOT want a pure state -> DOM

It's Backbone. A pure state -> DOM function is also called a template. It works when the app is simple. The problem is that you do NOT want a pure state -> DOM function. It blows away state of things like mounted subcomponents and input fields. Look forward to lots of ad-hoc DOM coordination as your app grows. Giving up efficiency in the slow part (DOM updates) in exchange for efficiency in the fast part (determining what changed) is backwards.

zkhalique 11y ago
Wait, what? Why would you ever want to read from the DOM in a well-architected app? Unless you are building a component that can be "dropped anywhere", you control what the DOM shows. If you need to read/write to the DOM, you can cause layout thrashing and seriously slow down your UI. You might have to resort to using a library like FastDOM to fix it. I think you are overstating the "dangers" of having the UI be a pure function of the state.
- grayrest 11y ago
  Not at all. I've written/cleaned-up a few dozen Backbone apps. They work great when they're small and are generally a mess once they scale. An example: how do you use a datepicker component in your pure state->DOM system and guarantee setup/cleanup of DOM event listeners? As for when you'd want to read from the DOM in a well architected app, the easy example is drag and drop. Unless your drop targets have fixed sizes or your needs are simple enough to purely get away with mouseenter/mouseleave events then you need to query the DOM for node sizes. Other situations I've run into are text breaking and rich text editing.
  - zkhalique 11y ago
    Yes, if you need to add a behavior to the UI which "can be dropped anywhere", such as drag-drop, or rich text editing, then as I said, you're going to have to read from the DOM and otherwise try to adapt "to any reasonable environment" with varying degrees of success. So what? This is orthogonal to the problem of rendering the basic UI as a pure function of the state. You can store the state of of components inside components, there are many ways you can do it. React does it. We've implemented it in our framework: http://platform.qbix.com/guide/tools http://platform.qbix.com/guide/tools As for how you would remove event listeners when a component is removed, that needs be coded of course. It would be nice for the developer not to have to write all that repetitive code. Of course, that also means you'll have to know when a node is removed from the DOM, and in browsers that don't support mutation listeners you'd be hard pressed to know that unless the user uses YOUR standard methods to control the DOM. All around it's a better solution (if you control the development of the app) to architect the app so that the model goes through YOUR framework to update the view.

zkhalique 11y ago

Wait, what? Why would you ever want to read from the DOM in a well-architected app? Unless you are building a component that can be "dropped anywhere", you control what the DOM shows. If you need to read/write to the DOM, you can cause layout thrashing and seriously slow down your UI. You might have to resort to using a library like FastDOM to fix it. I think you are overstating the "dangers" of having the UI be a pure function of the state.

grayrest 11y ago
Not at all. I've written/cleaned-up a few dozen Backbone apps. They work great when they're small and are generally a mess once they scale. An example: how do you use a datepicker component in your pure state->DOM system and guarantee setup/cleanup of DOM event listeners? As for when you'd want to read from the DOM in a well architected app, the easy example is drag and drop. Unless your drop targets have fixed sizes or your needs are simple enough to purely get away with mouseenter/mouseleave events then you need to query the DOM for node sizes. Other situations I've run into are text breaking and rich text editing.
- zkhalique 11y ago
  Yes, if you need to add a behavior to the UI which "can be dropped anywhere", such as drag-drop, or rich text editing, then as I said, you're going to have to read from the DOM and otherwise try to adapt "to any reasonable environment" with varying degrees of success. So what? This is orthogonal to the problem of rendering the basic UI as a pure function of the state. You can store the state of of components inside components, there are many ways you can do it. React does it. We've implemented it in our framework: http://platform.qbix.com/guide/tools http://platform.qbix.com/guide/tools As for how you would remove event listeners when a component is removed, that needs be coded of course. It would be nice for the developer not to have to write all that repetitive code. Of course, that also means you'll have to know when a node is removed from the DOM, and in browsers that don't support mutation listeners you'd be hard pressed to know that unless the user uses YOUR standard methods to control the DOM. All around it's a better solution (if you control the development of the app) to architect the app so that the model goes through YOUR framework to update the view.