Once you understand how React works, you’ll build a complete custom Whinepad app that helps users rate wines and keep notes. You’ll quickly learn why some developers consider React the key to the web app development puzzle.
Set up React and write your first "Hello world" web app
Create and use custom React components alongside generic DOM components
Build a data table component that lets you edit, sort, search, and export its contents
Use the JSX syntax extension as an alternative to function calls
Set up a lean, low-level build process that helps you focus on React
Build a complete custom app that lets you store data on the client
Use ESLint, Flow, and Jest tools to check and test your code as your app evolves
The animal on the cover of React: Up & Running is an ‘i’iwi (pronounced ee-EE-vee)bird, which is also known as a scarlet Hawaiian honeycreeper. The author’s daughterchose this animal after doing school report on it. The ‘i’iwi is the third most commonnative land bird in the Hawaiian Islands, though many species in its family, Fringillidae,are endangered or extinct. This small, brilliantly colored bird is a recognizablesymbol of Hawai’i, with the largest colonies living on the islands of Hawai’i, Maui, andKaua’i.
Adult ‘i’iwis are mostly scarlet, with black wings and tails and a long, curved bill. Thebright red color easily contrasts with the surrounding green foliage, making the ‘i’iwivery easy to spot in the wild. Though its feathers were used extensively to decoratethe cloaks and helmets of Hawaiian nobility, it avoided extinction because it was consideredless sacred than its relative, the Hawaiian mamo.
The ‘i’iwi’s diet consists mostly of nectar from flowers and the '?hi?a lehua tree,though it will occasionally eat small insects. It is also an altitudinal migrator; it followsthe progress of flowers as they bloom at increasing altitudes throughout the year.This means that they are able to migrate between islands, though they are rare onO’ahu and Moloka’i due to habitat destruction, and have been extinct from L?na?isince 1929.
There are several efforts to preserve the current ‘i’iwi population; the birds are verysusceptible to fowlpox and avian influenza, and are suffering from the effects ofdeforestation and invasive plant species. Wild pigs create wallows that harbor mosquitos,so blocking off forest areas has helped to control mosquito-borne diseases,and there are projects underway that attempt to restore forests and remove nonnativeplant species, giving the flowers that ‘i’iwis prefer the chance to thrive.
Good book on React - focusing on "learn React and setState"
By P. Reynders
from ON Canada
About Me Developer
Comments about oreilly React: Up & Running:
TL;DR: Good book on React - focusing on "learn React and setState first". Simply reading through it will only put a fresh coat of paint on your existing knowledge - you will have to work through the book to get the full in-depth benefit which may take a bit of (unexpected) effort. You won't be a React ninja by the end of it but your new knowledge base should be solid enough to cope with the more advanced sections of the online documentation. In general there is very little repetition - so whenever things seem to get a bit murky, back it up a bit and if clarity remains elusive see if a quick online search can help to set matters straight (see "Chapter Notes" below).
The book uses React 14.7 (2016-01-28). The github repository seems to have some 15.02 (2016-04-29) updates. I used React 15.3.2 (2016-09-19) on Arch Linux/GNOME 3 with Chromium. React 15.4.1 released on 2016-11-22.
What follows are some opinionated comments that may save some readers some time and frustration - "forewarned is forearmed":
- I like the fact that the initial three chapters restrict themselves to non-JSX, ES5, bare naked React library use. I find that while many seem to find JSX "more convenient", JSX can hide some revealing and interesting details and get in the way of forming the correct mental model of how React actually works and what it actually does. ES2015 React use is introduced later together with JSX in chapter 4.
- For me the book misses on explicitly emphasizing the core role of React Elements. The discussion is always so focused on "components" that it is easy to miss that a React application uses React Elements to convey the rendering requirements to React - render functions return a >>React Element< < . Chapter 1 would have been the perfect place to elaborate more deeply on the role that React Elements play, especially given that the "Hello world" application doesn't use any custom components - it simply creates React Elements to describe to the React engine which stock components are to be used for rendering. It was only after I read Dan Abramov's explanation (search online: "React Components, Elements, and Instances - React Blog") of the relationship between React Elements, components and instances that for me some of the missing pieces feel into place. It finally clarified that renders only ever create React Elements and that it is entirely up to React to correlate those React Elements to existing instances and to decide when and where to create new instances. So be sure to understand Dan Abramov's article before proceeding past the end of chapter 2.
- Testing is delayed until the end of the second last chapter (Chapter 7) - which makes it feel a bit of an afterthought (this continues to be an issue with books of this type). This is aggravated by the fact that it follows the disruptive section on "Flow" which some readers may never get past. Tero Parviainen's amazing "Build Your Own AngularJS" demonstrates how a TDD environment can be used to effectively showcase in code the behavior of a framework/library under scrutiny - an approach that simply cannot be matched by the "let's build a sample project" approach alone. Flow continues to be used in chapter 8 but there is no more sign of testing.
Obviously I find my refactored version (with shorter functions) easier to read and understand (search online: "GOTO 2014 Kicking the complexity Habit Dan North" t=508 (08:28)).
- Starting with p.118 code like "this.reset.bind(this)" starts to appear with (at least to me) disturbing regularity in render functions. p.119 does discuss "bind once in constructor" briefly but quickly dismisses it as introducing "more boilerplate in the constructor". Now I do understand that "bind once in the constructor" is viewed by some as a premature optimization - the render is typically already generating a number of soon-to-be-garbage React Elements, why would a few more redundant function objects matter? The only net benefit of "bind during render" that I could find was that it is needed for Webpack's Hot Module Replacement - which is a development option that doesn't benefit production operation. But the book doesn't use Webpack nor does it imply that Webpack is the de facto standard build tool for projects using React (in fact the book is decidedly standoffish with regards to mentioning any build tool, likely not wanting to deal with a distraction that could be entirely irrelevant to any particular reader). However for me it is about using code to "communicate intent" - "this.reset.bind(this)" should only really be necessary inside the render function if there is the possibility that "this.reset" has changed since the last render - but considering the circumstances that would imply that monkey patching is going on - if "this.reset" doesn't change during the lifetime of the instance then "bind once in constructor" is in my view the correct way to "communicate intent".
Chapter 1. Hello World A bare bones , pre-npm, pre-JSX ReactJS "Hello World" HTML with inline ES5 example is discussed - there is also a quick side excursion for the className and htmlFor properties. The React DevTools Browser extension is quickly mentioned.
p.4 "React provides wrappers around HTML DOM elements. You use the wrappers via the React.DOM object". This over simplification sent me off into the weeds and the notion never really got explicitly set straight later in the book. For example React.DOM.h1(...) is essentially a pre-validated wrapper function/version of React.createElement('h1', ...) and as the latter name suggests - it returns a "React Element". A React Element is more like an "order ticket" - and when you hand over a ticket to ReactDOM.render(...) that orders an "h1", it will eventually find/create the matching "HTML DOM element" - but the "h1" React Element (the "ticket") is hardly a wrapper of the actual "HTML DOM element/node". Also note how close "ReactDOM" and "React.DOM" are (which does get it's own discussion in a sidebar on p.5). In hindsight I would have preferred that the introductory ES5-based chapters would have ignored the React.DOM utility functions entirely (save mentioning them in a sidebar to preserve the p.6 "List of React.DOM properties" which identifies the stock components) and stuck entirely with React.createElement(elementName, ...) to really drive home the fact that React component render() functions only create React Elements.
p.7 continues to talk about "nested components" - the code is actually nesting React Elements (each of which refer to/identify a component like "h1", "span", "em").
Chapter 2. The Life of a Component A gradual introduction to the pertinent aspects of class-based component( instance)s, including props (and propTypes), state, React event handling, and the lifecycle methods and some of their use cases.
Unfortunately the chapter is too focused on instances of class-based components. The key role played by React elements in relation to instances is not adequately explored. Neither is the environment/context for React's component lifecycle methods sufficiently established. The sidebar about "reconciliation" on p.27 is simply not enough to reveal under what circumstances a method like componentWillReceiveProps will be invoked (i.e. when will that "outside intrusion" (p.28) occur?) - especially after the setup on p.24: "this.props is like all the arguments passed to a class constructor" - which can leave one with the impression that props really aren't supposed to change (which the API clearly implies they can). My initial confusion was only cleared by reading Dan Abramov's article which I didn't come across until after I had finished the book. It probably didn't help that p.29 "Lifecycle Example: Log It All" didn't log componentWillReceiveProps which may have been helpful in p.33 "Lifecycle Example: Using a Child Component". That example could also have been used to demonstrate an alternate counter component implementation as a stateless functional component but that isn't introduced until much later around p.111.
p.24 How do you pronounce "camelCase"? Does it sound different from "CamelCase"? Event handler names and JSX attributes names use "lower camel case" notation - in general verbal communication "camel case" is typically assumed to mean "Pascal case" or "upper camel case". So it is a good habit to always specify "lower camel case" even in written communication.
Chapter 3. Excel: A Fancy Table Component Gradually building a column sortable, field editable, filterable table component with plain ES5 React. Versions that can replay past table states and export table data are also explored.
Chapter 4. JSX The React library calls from the previous chapters are bit by bit replaced with JSX syntax which is discussed in the process. Transpilation (JSX and ES2015 to ES5) with Babel is introduced. A nice JSX overview.
The application creates object properties on data objects in the order of the "schema items" within the "schema array" (p.123 Form.getData(), p.142 app.js). Logic in Excel._renderTable() (p.134) relies on the assumption that Object.keys() on such a data object will generate an index that correctly indexes into the original schema array to access the correct schema item! AFAIK the ECMAScript specification does not guarantee that this approach will ever work (i.e. that object property enumeration order will always reflect property insertion order) - despite the fact that this works in current browser implementations (this is easily fixed by offering/using an alternate schemaMap ES2015 Map object instead).
Chapter 7. Lint, Flow, Test, Repeat - package.json A quick discussion of npm project setup. There seems to be a fondness for sticking every tool's configuration inside the package.json, my personal preference is to keep those separate (.babelrc, .eslintrc.json, jest-config.js, etc.). There is also a quick discussion of npm scripts - too quick in my opinion. It seems peculiar that all the package.json files on the github repository are missing their "dependencies" and "devDependencies" objects - typically this would give valuable insight into the versions of npm packages used. - ESLint A quick discussion of how to add ESlint to the project. Helpful, though further study at eslint.org is likely indicated. - Flow Introducing Flow at this point is infuriatingly disruptive. This material should have been relegated to an appendix as a suggested exploration where it would not interfere with the "working flow" of the book. As it stands the nine pages provided cannot cover the Flow knowledge required for the reader to convert the sample application to Flow - I can't imagine what it would be like if one doesn't already have experience with statically typed languages. So to "work through" the relatively short Flow section one has to be prepared to put the book aside and spend a significant amount of time with the online Flow documentation (wondering what that trailing question mark does? - better know to look for "optional properties" which are an entirely separate topic from "Maybe types" which use the leading question mark). Finally converting an existing ECMAscript project to Flow is an exceedingly frustrating experience, especially if you are just learning Flow - frankly it leads to an experience that doesn't do Flow any favors. It would make more sense to introduce Flow right at the beginning of the project. But that would significantly add to the "React/Flow learning curve" in a book that presumably wants to focus on "just React" - but maybe Flow should go hand in hand with React just like TypeScript can with Angular 2.
Granted the full Flow sample project is available on the book's code repository but essentially any code past this point isn't just ECMAscript with JSX - it's Flow constrained/annotated ECMAscript with JSX, so understanding Flow's syntax becomes an essential part of comprehending the semantics of the code. Also be warned, that as Flow's capabilities are constantly improved, the repository's code may not pass statical analysis anymore (the version of flow-bin used is not identified in the repository's package.json - flow-bin 0.33.0 did throw error's for me on the repository's code).
Note: p.152 - since August 2016 class fields have advanced to a Stage 2 Proposal (search online: TC39 ES Class Fields and Static Properties); i.e. the babel-plugin-transform-class-properties plugin is needed rather than the babel-preset-stage-0 preset. - Test A quick and useful introduction to testing with Jest which includes code coverage. I should mention that Jest 15 (2016-08-31) no longer "auto-mocks". Just a bit (too) late in the book for my taste and there are no more tests past this section/chapter.
Chapter 8. Flux A DIY implementation of Flux is introduced into the Whinepad application. In order to keep things simple the DIY implementation is necessarily constrained. An unfortunate consequence is that the reader may get an anemic impression of the potential behind the Flux architecture/pattern.
The store only emits one single event ("something about the data changed") which doesn't even supply any "event context" (the updated data) and the React components partially implement the dispatcher by calling a specific method on the CRUDActions object rather than simply sending an action message (JS object) that is routed elsewhere. The DIY implementation has a decidedly object-oriented/imperative feel about it (Alan Kay: I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea. The big idea is "messaging").
Then there are some puzzling design decisions in the DIY implementation. Both CRUDStore and CRUDActions are implemented as single instance objects that become quasi-global the moment the encapsulating module is imported. p.173: "However, while passing properties this way, you may sometimes end up with a component that takes too many properties." So we are trading explicit and deliberate dependency injection for implicit dependencies via quasi-global single instance objects? I'll take "Just Create One" over a Singleton anytime (search online: "Singleton vs. Just Create One - Uncle Bob"). For comparison, in Redux the store is injected into the Provider and then exposed via a connect function in a much more controlled fashion.
p.182 "Any function calls in render() start to look suspicious — you never know what kind of values you'll get from an external call." I'd argue that decomposing lengthy render logic into well-named functions within the module's closure improves code readability tremendously.
For a functional Whinepad, CRUDStore and CRUDActions need to be introduced simultaneously, so it would make sense to me to discuss their communal impact one React component at a time. Instead changes are discussed in entirely separate CRUDStore and CRUDActions passes, significantly increasing the reader's "mental load".
Finally, the Immutable library is introduced to manage the data inside of CRUDStore. The necessary changes in CRUDStore and CRUDActions are discussed - a minor one in the Excel component isn't (i.e. an Immutable List can't be indexed into).
This is probably a good time to have a look at (search online: "Redux or MobX: An attempt to dissolve the Confusion - RWieruch"). Many MobX adoptees attest that they find it "easier" - it certainly should feel more "familiar" (familiar != simple) but that doesn't necessarily make it the "right tool for the job" nor does it help to minimize mutable state.
Bottom Line Yes, I would recommend this to a friend