React: Up & Running
Building Web Applications
Publisher: O'Reilly Media
Final Release Date: July 2016
Pages: 222

Hit the ground running with React, the open-source technology from Facebook for building rich web applications fast. With this practical guide, Yahoo! web developer Stoyan Stefanov teaches you how to build components—React’s basic building blocks—and organize them into maintainable, large-scale apps. If you’re familiar with basic JavaScript syntax, you’re ready to get started.

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
  • Manage communication between components with Flux
Table of Contents
Product Details
About the Author
Colophon
Recommended for You
Customer Reviews

REVIEW SNAPSHOT®

by PowerReviews
oreillyReact: Up & Running
 
4.5

(based on 2 reviews)

Ratings Distribution

  • 5 Stars

     

    (1)

  • 4 Stars

     

    (1)

  • 3 Stars

     

    (0)

  • 2 Stars

     

    (0)

  • 1 Stars

     

    (0)

Reviewed by 2 customers

Displaying reviews 1-2

Back to top

(3 of 3 customers found this review helpful)

 
4.0

Good book on React - focusing on "learn React and setState"

By P. Reynders

from ON Canada

About Me Developer

Verified Reviewer

Pros

    Cons

      Best Uses

      • Intermediate

      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.

      I was primarily interested in exploring React as an alternative to Elm (elm-lang.org) for use in "more conservatively minded" projects. I approached this book with high expectations set by the author's excellent 2010 book "JavaScript Patterns" - as such I encountered quite a bit more friction than I had initially anticipated which is ultimately responsible for the 4 out of 5 rating.

      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.

      - I didn't care for the "browser.js JSX transpilation on the client side" detour in chapter 4. "Keeping things lightweight" with deprecated/unsupported technology (since version 6, 2015-10-29; search online: "babel-browser has been removed") seems unwise to say the least even if it is just for training purposes and especially since we are going to soon do this "the-right-way" anyway. So instead, I set up a simple brunch (asset build-tool used by the Phoenix framework) project and worked through the chapter that way. My recommendation is to work through chapter 5 first (which is short enough anyway) and then to use that environment to work through chapter 4. I also would have preferred if chapter 5 would have included the "package.json" section from Chapter 7 and continued by implementing the transpiling, packaging, watching, minifying, and deploying scripts as npm scripts (search online: "How to Use npm as a Build Tool - Keith Cirkel"). JSX essentially requires the JavaScript tool chain and npm is a core pillar of that tool chain - so demonstrating the use of npm scripts for developing and building smaller projects would be nice.

      - 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.

      - The book's code embraces a coding style that seems to be rampant in large parts of the JavaScript community. Multi-line, inline anonymous function expressions usually result in >>highly imperative< < code because the anonymous functions tend to focus on "how to do something" (imperative) rather than on "what needs to get done" (declarative). Expressive function names and use of those names make code more readable and understandable. Furthermore difficulty in finding an appropriate and expressive name for a function may be an indication that the function is doing too much - overuse of anonymous functions routinely bypasses this potentially useful sanity check. As a result I ended up spending a significant amount of time "refactoring to understand" (p.212: "Working Effectively with Legacy Code" - Scratch Refactoring) the book's code in chapters 3, 4, 6, and 8. For example in chapter "6. < Excel>: New and Improved" p.133:

      this._renderTable (~70 lines)

      vs. my refactored version:

      renderTable (13 lines)
      renderColHeader (19 lines)
      renderTableRow (8 lines)
      renderRowCell (23 lines)
      wrapRowCellContent (15 lines)

      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".

      (see also - search online: "React, ES6, Autobinding, and createClass - Andrew Ray's Blog" or "React Binding Patterns: 5 Approaches for Handling 'this'") Interestingly none of these binding discussions mention the possibility of using a separate function closure to mimic the "binding" of "this" or any other argument value(s) (search online: "Closures - JavaScript | MDN", find on Page: "bind").

      Chapter Notes:

      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.

      Chapter 5. Setting Up For App Development
      - A Boilerplate App
      Setup of a rudimentary development environment with a directory structure, index.html, app.css, app.js and Logo component - ES2015 is starting to creep in.
      - Installing Prerequisites
      Install npm/node, browserify, babel, react, react-dom, babel-preset-react, babel-preset-es2015 (and eventually watch, uglify and cssshrink). You are also going to need babel-plugin-transform-object-rest-spread and babel-plugin-transform-class-properties.
      - Let's Build, Moving On
      Discussion of (command line) commands (or shell scripts) required to transpile JavaScript, package JavaScript, package CSS and watch development files for changes.
      - Deployment
      Discussion of a shell script to copy a version of the page with minified JavaScript and CSS.

      Chapter 6. Building an App
      - Whinepad v.0.0.1
      Integration of Chapter 4's Excel component into the first incarnation of the demonstration application in an HTML page that uses a JavaScript bundle.
      - Components
      Building of the low-level React components (including CSS) Button, Form, FormInput, Suggest, Rating, Actions, and Dialog. Discussion of using ES2015 arrow functions for stateless components and using ES2015 classes for stateful components. A "discovery" page is used to interact with the new components outside of the demonstration application.
      - AppConfig, Excel New and Improved, Whinepad, Wrapping It All Up
      Discussion of the higher-level React components Excel and Whinepad (e.g. "search" is relocated to Whinepad) and the application script app.js. It is at this point that the classification object and "schema" array are introduced (p.128).

      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.

      (1 of 1 customers found this review helpful)

       
      5.0

      Very good

      By Raúl Pleitez

      from Ciudad Arce, La Libertad

      About Me Developer

      Verified Buyer

      Pros

      • Accurate
      • Concise

      Cons

        Best Uses

        • Novice

        Comments about oreilly React: Up & Running:

        Perfect for anyone wishing to start as soon as possible with React.

        Displaying reviews 1-2

        Back to top

         
        Buy 2 Get 1 Free Free Shipping Guarantee
        Buying Options
        Immediate Access - Go Digital what's this?
        Ebook:  $33.99
        Formats:  DAISY, ePub, Mobi, PDF
        Print & Ebook:  $43.99
        Print:  $39.99