To enhance server-driven web apps, React’s flexible nature is a game-changer
Facebook’s React is certainly not lacking in popularity. According to The State of JavaScript 2017, nearly 60% of surveyed developers had not only used React for a project, but said they would definitely use it again; no other listed framework came close to that level of loyalty.
Its popularity is well-earned, though. After years of struggling with straight DOM manipulation via jQuery or vanilla JS, or wrestling with unwieldy “full-stack” frameworks like AngularJS, React feels like a dream. Instead of wrangling logic and layout in separate files, using and maintaining custom attributes, or writing function after function to manage DOM changes, React’s JSX syntax permits you to describe how the layout should look like at any given state using syntax which looks almost like HTML. This is an important distinction.
In the early days of React, many highly-skilled and intelligent front-end developers raised a fuss about “separation of concerns” by suggesting that writing JSX was the same as writing HTML in JavaScript. But it’s not. (Fortunately, most of those developers understand that now.)
JSX: The Heart of React’s Approach to Server-Rendered Apps
JSX is syntactic sugar for functions which compile to React classes. React is a library for composing those functions into easily reusable components. Everything in React is a component, and every component is ultimately just a function. This is a brilliant architectural decision. When everything on the page is just a function, we are permitted tremendous freedom to compose the page in virtually any way, using small chunks of code which can reused indefinitely.
Like most front-end developers, I’m very interested in creating modular chunks which are easy to reuse; when working in Rails I make heavy use of partials, and within CSS I adhere strongly to the BEM system and strive to use a module-first pattern with a goal of easy composability. JavaScript’s excellent support for first-class functions, which can be passed around as easily as variables, creates a natural fit for this approach; by facilitating the use of functions which essentially behave like HTML elements, React makes it very easy to create small yet highly customizable components which can be used anywhere with virtually no limitation.
Integrating React in Server-Rendered Apps: A Personal Journey
I’ve spent roughly two years working with React. Oddly enough, most of that work has not been spent on single-page applications, even though Mission Data has created several of these using Redux and React Router. Instead I have concentrated on incorporating it into more traditional server-rendered Rails applications. In my opinion, this highlights one of the greatest strengths of React: unlike full frameworks like Angular, Ember or Backbone, the core React library is just for rendering views — anywhere you want them. With a little help from React On Rails, dropping a component into an ERB template is as straightforward as any other view helper.
If you want/need to use a React component inside a traditional form POST, this is not entirely without disadvantage, though. While rendered form inputs will be included simply from presence of being, a complex UI for managing something like a set of lists will still need to output that information in a way which that form post will be able to interpret. As an example, I built several components for managing groups of lists using select components for setting values to those lists; since all of those values needed to post alongside some other form fields which were not rendered by React, I couldn’t just AJAX my way out of the corner. Instead I created a system to output the list values to a bank of hidden fields each time the user made a change — a task which was not necessarily easy or without burden. Additionally, creating client-rendered UI is easily an order of magnitude more difficult than server-rendered UI; you have far more things to keep track of, and JavaScript’s fragile nature can cause the entire thing to come tumbling down around a single syntax error.
Ultimately, though, the benefits outweigh the negatives. Having the capability to create rich interactive controls and apply them anywhere I need them provides me tremendously more freedom when designing interfaces, and allowed me to execute those interfaces exactly as envisioned. React is a tool I look forward to using because at a base level it feels simple despite being incredibly deep and flexible.
I definitely recommend using a type checker of some sort if you are going to write complex JavaScript using React. The two major players in this field are Flow (also created by Facebook) and TypeScript (from Microsoft). I’ve used both within React projects. While Flow has built-in support for React (due to their common owner), my preference is TypeScript; in addition to having exceptionally good definition files for React, TypeScript is a far more stable product, with a highly active development team and a vastly larger collection of library definition files via DefinitelyTyped.
Aside: if you are interested in using TypeScript, I highly recommend Visual Studio Code as it almost certainly has the best TS support of any free editor. Of course, it’s also an excellent editor for many other reasons, and managed to lure me away from Sublime Text, my old friend of many years.
Elevating Server-Rendered Apps with React: Final Thoughts and Recommendations
If you don’t want to use TypeScript, you will definitely want Babel (with the JSX transform) as React is geared toward the newer ES6+ syntax. And you’ll probably want webpack for preparing bundled code as the React community has more or less chosen webpack as their “official bundler”; while it’s still not necessarily easy to configure, newer versions have come a long way in simplifying that process. If you’re in a hurry, Create React App is a fast and easy way to create a React app with both of these tools pre-configured and ready to go.
