Less React, more JS
Note: I don’t have anything against React. This article is about exploring ideas of decoupling, regardless of the library or framework.
The rise of the virtual dom in the front-end world has left clumsy imperative dom manipulation in the past. From this new shift comes a flood of new frameworks and libraries, the most popular being React.
Consider every component simply renders data to virtual dom nodes. Data in, nodes out. Functionally this seems pure, until state is stored inside. Throw away internal state, throw away createClass.
Any state can just be passed into the function, with no mutation. If state needs to be persisted its better kept in the Model or Store (depending on the paradigm).
This pure function can do without createElement. It can just return an array that can be applied as the arguments for createElement inside ReactDOM.render
This seems nice — pure JS functions and data outside, and all React stuff inside ReactDOM.render. How could this possibly work for nested elements? We’d need to write a small utility function, which may seem tedious for something this small but trivial for larger nested stateless components/functions.
Styles are declared as object literals, but they can also be functions that return object literals. This could be recognized as something similar to mixins.
With a small utility function styles can extends others.
It felt good to brain dump these ideas. I’d be interested to hear any other thoughts on this subject.