Two Months in React

For the last two months, I have been working on a web application with react, redux and their friends professionally, aka paid by my employer. Here are some lessons we have learned:

Start small

The current web app was was built five years ago with move fast and break things motto, so we can quickly build and iterate to validate the business ideas. It serves this purpose very well, but we also find it takes longer and longer to land a new feature due to the hairy code base. We finally decide to pull the trigger to rewrite this web application with a more modern, modular fashion.

To avoid the potential scope creep, — it is really hard to resist the temptation of the overhaul with shiny new tools, — the scope is strictly limited to two pages: the preview page and corresponding search page after the purchase of an Audience collector. These two pages demonstrates our powerful audience targeting, real-time availability check and price quote. They are the most important, and complicated two page in our business. The rewrite will just address the pain point; no more, no less.

Another factor is our team’s lack expertise on the front end cutting-edge technology. Our hands are pretty full in the brave new world:

• new languages: ES6 and JSX vs vanilla JavaScript.
• new toolchain: babel, webpack and eslint vs uglify.
• new programming model: flux vs ad-hoc DOM manipulation.
• new programming mode: immediate mode vs retained mode.

With a narrow focus to address the immediate issue and essential tooling, our bandwidth will not be spread too thin for some advanced features, such as SPA routing, and backend rendering.

Team consensus on the best practice

The landscape of the front end world changes fast, — every six months, some cool kids just pop out in the block. A team consensus on the technical decisions will help everyone to stay in the same page:

• Should we adopt ES7 for await, or use TypeScript?
• Should we use immutablejs?
• Should we use dispatch directly in the component, or pass the action functions as the props from parent container with the aid of bindActionCreators?

There are no right or wrong answers, just pick what make most sense for the team.

Learn react and redux altogether

This seems counterintuitive, but based on my personal experience and my colleague’s feedback, the paradigm change brought by the redux is quite confusing for the newcomers:

Where is the state, we no longer use it? We should use props instead?

So my crash course takes a slight different approach: we first reviewed the canonical react component, then quickly moved to the stateless function components diagram with redux. We spent sizable time to dig into the react redux integration, see react-redux. And finally went back to react component life cycle management for the jQuery UI integration.

Make the eslint part of pipeline

Use eslint! I cannot emphasize enough the importance of eslint: the coding style cop not only tidies your code, but also pinpoints the typo bug in the compilation rather than the invariant error in the runtime.

Thanks to the eslint-loader, we can enforce the linting as a part of webpack pipeline:

  module: {
    preLoaders: [
      {
        // Use ESLint for both js and jsx files
        test: /\.jsx?$/,
        loader: 'eslint',
        exclude: /node_modules/,
        include: path.join(__dirname, 'app')
      },
    ],
  ...
  }

Improve the testability

The react’s virtual DOM approach not only boost the performance, but also decouples the library from the browser runtime. Thus, we can unit test the react components in the node environment with enzyme.

Another trick to improve the testability is to insert the data-* attributes in the JSX element as probing mark. Since react only renders the visible element¹, you can expect the element visible to the end user if the probing mark is identified.