A discussion of these principles follows:
Functional Programming Paradigm
One of the core tenets of React is that components are a function of state and props. For a specific state and props, React will always return the same component - time and environment are non-factors. Behavior is the same on the server as the client and the same upon first render as 500th render. This is the result of React components being pure functions.
This includes the genius of the Virtual DOM. But the real genius of it is not the Virtual DOM itself, but that the rendering is view agnostic - the DOM is just a target that can be replaced with native mobile app or TV or canvas entities. And you can tell React to plop these view entities into a mount container somewhere, or you could just get it as a string - that’s the Holy Grail of universal [isomorphic] rendering right there! We should be abstracting code that is fragile, elusive, or problematic.
This is what gives developers a greater level of confidence in what their view is doing at any given point, and allows React to say “learn once, write everywhere.”
Perhaps this is how the hype of the philosophy behind web components is actualized. We want to build our applications out of composable components and to be able to develop component libraries and use them easily across applications and organizations. We want smart components that are specifically coupled to our application logic, and we want dumb components that can be used for layout and organization.
Componentization is not restrained to rendering views or determining layout. It also enables the use of patterns that may be better suited as declarative than imperative. React-router is the best example of this (routes are defined declaratively, not imperatively) and the trend among Flux frameworks recently has also been in this direction.
These are all principles that we as a community should strive towards. These are means by which we can produce maintainable, scalable, and more predictable code, and produce libraries that improve developer experience by easing the cost of adoption and leveraging the standard library as much as possible.
Here are some examples of how these principles can be actualized:
- The functional programming paradigm - write pure functions and eliminate side effects and unnecessary variables affecting how your code runs
- A minimal surface area API - minimize the concepts and APIs someone will need to know and understand to consume your code. Ensure names are self-explanatory
- Proper abstraction - DOM manipulation is quirky and meticulous and the Virtual DOM protects the developer from those intricacies and idiosyncrasies. Data propagation is manual and repetitive and Relay reportedly addresses that complexity. Proactively identify the real problems in your apps and be ambitious in your consideration of solutions
- Componentization - bet on UI components as the future of building views, it will facilitate rapid composition and iteration of interfaces for everyone
Many thanks to Josh Schumacher and Patrick Costanzo for proofreading.