James states in this article, a way to have a React app without state; rendering without maintaining state at all.
// Handle updated values by re-rendering the app
function render(value) {
ReactDOM.render(
<CommentForm
value={value}
onChange={render}
/>,
document.getElementById("react-app")
)
}
// Initialise the app by rendering it
render({
name: "James",
message: "",
})
I can think of many ways, on how this could get ugly as far as the state is concerned, but I suspect this pattern doesn't also give the benefits of the virtual DOM, right? Can anyone technically prove that this is the case?
The approach using states. Give us the power over the flows, over what will be rendered by the data, when us work with big applications. This approach seems me more easy for writing TDD/BDD and for maintain the low level of complexity.
I hope, help you.
the virtual dom is an observer pattern with meta information. the trigger of the render does the same thing as a statechange, he basically just hacked the lifecycle.
You would need to benchmark it to see the full implications, in the end he just removed the state/props update/life-cycle and moved the state into the DOM again.
But I agree he will loose some benefits of the Virtual DOM, but the way he approaches it it looks like he just short fused the the rendering to itself and uses kind of an actor system where change only rerenders the specific component. can be nice i would think of using http://cycle.js.org/ if I wanted a better event flow or https://vuejs.org/ if i want to get rid of the state.
A react app without state seems feesable if you map state with something else like redux. Currently working on a site and haven't used this.state at all. Redux maps everything and if i have to change it i disbatch an action. If i need its values I mapStateToProps.
Sai Kishore Komanduri
Engineering an eGovernance Product | Hashnode Alumnus | I love pixel art
This pattern sure is strange. But to answer your question on the above pattern losing the benefits of virtual DOM, I don't think that would be the case. As you can see inside the
renderfunction; we're calling therenderprop ofReactDOM; and this would still do the "diff" step with the actual#react-appnode.