Whew! I think we're ready to start, but before we dive into the code I want to impart how I believe you should think about the render step in the React component lifecycle as well as a way to approach browser support and form validation.
The way you should think about the React render function is much like the definition of a mathematical function: f(state) = UI. React treats the DOM as a rendering target, much like a computer program or game treats the Graphics Processing Unit (GPU). State is kind of like the arrays of object data (vertices, and so on). That data is prepared for shipment to the GPU, and the rendering portion of the component lifecycle is kind of like the OpenGL rendering pipeline that consumes that data (state). The render function itself would be the shader code that processes the geometry and pixels in this analogy, and the virtual DOM would be the framebuffer. In the GPU analogy, object data and state go into the render pipeline and the result is an array of pixel data. In React, state goes into the render pipeline and a virtual DOM tree is the result.
This means that, when a potential render cascade begins (shouldComponentUpdate à componentWillUpdate à render), you shouldn't change the state. It's already too late for that sort of thing. That's worth saying again; the render function should be pure and never affect state or props. You are welcome to make intermediary variables in the render function to create projections (transformations) of state that are easier to consume by render logic, just don't change the state itself.
This application structure is quite powerful and is the reason that the React Native project can exist. The DOM isn't something that you typically interact with directly in React as you would with jQuery, for instance. Other native targets, such as iOS Cocoa, are just other rendering targets with their own specific render function. This one-way structure and focus on efficiency (for what is often the most expensive part of an application, getting pixels onto the screen) is what makes React special and, in some ways, more flexible for cross-platform development than other JavaScript libraries.
For our application we want to use modern browsers: browsers that the vast majority of people use. This means being a bit choosy. Of course, in a real scenario you have to consider the target users who will actually use the application and support them, even if it means substantial additional effort. For example, if you make a government services website you may need to support an older IE browser if some users are citizens who use library computers that are often older and locked into running older browsers.
Conventional wisdom in the web community often asserts that we should start with the lowest common denominator (that is, the worst browser in terms of feature support) and work our way up to the fancier browsers. This is known as progressive enhancement. This is slightly at odds with a technique known as polyfilling in which newer features are back-ported to older browsers.
Polyfills are JavaScript code included to port features into browsers that do not yet support them natively. They enable you to write code as if the feature exists in an older browser. If it does already exist in the browser, the polyfill does nothing and the native code is used. They are often very cheap in terms of code size and performance. While not always on par with native speed, performance is acceptable (in some cases better!). A moment ago, I mentioned that this is slightly at odds with progressive enhancement because, with polyfills, you write code as if those features exist in browsers where they do not. However, it's not entirely at odds with the progressive enhancement strategy. One could argue that starting with the lowest supported browser set, then polyfilling, and then moving on to more complex features that will only be exhibited in newer browsers still fits the strategy. If you are supporting older browsers and following the progressive enhancement strategy, then significant user goals should still be achievable on those older browsers.
For our purposes (learning new stuff), we are focusing on interesting new technology and getting a prototype running easily. So, we'll start with our desired tech and fill it in using polyfills where we are compelled to do so, but we'll avoid writing two or more specific portions of code that have the same effect for two or more browsers.
Using the Babel runtime trick that you saw in the Webpack configuration section eliminates our immediate need for traditional polyfilling.
In Chapter 1, Dynamic Components, Mixins, Forms, and More JSX there was some discussion about validation. In that discussion, three means of immediate (field-level) validation were explored: view level, view model level, and model level. A conclusion there stated that, for system consistency, a model containing the constraints and a shared mechanism to exercise constraints was an ideal architecture. While that is still the contention of this text, in this chapter we want to focus on application structure, mostly views. So, we are going to cheat a little and do minimal validation in the view via a small helper. The constraints will reside inside their respective view components. This is, in part, due to the fact that we are using JSON Server as a mock back-end. To build a model of validation constraints while using a simple document store would take time away from exploring our primary application architecture components (views, stores, and actions) and their interconnections.
