1.21 kilobytes

This post is the first in a two part series on React JS. Since there are already tons of great docs and training material for React, the focus of these posts is to highlight some common design decisions and Azure ecosystem build/deploy problems that folks new to React typically run into.

This particular post focuses on the key decisions you should make before you start writing any code.

Edit: Part 2 now is available here.

Decision 1: Do I even need to use React at all?

Don’t immediately start a React (or competing framework) project unless you know you need it. Otherwise you will waste a lot of time adding unnecessary complexity to your project.

Here are two common scenarios where it does make sense to use:

1. Websites that have frequent state changes.
   Examples: Live refreshing social media feed. A monitoring dashboard that shows realtime data.
   
2. Component code-reuse scenarios.
   Example: UI elements/controls that you want to build and use across multiple pages or multiple websites.

Decision 2: Should I use TypeScript of JavaScript?

TypeScript is great. You should use it if you want to catch more bugs before they reach production.

I would only recommend new projects in JavaScript if you don’t like safety checks or if you have an unusual toolchain situation that dictates you can’t use TypeScript.

Decision 3: Should I use React or React Native?

Use React if your application is only going to live in the web browser.

Choose React Native if you want your application to look and feel like its a native application in the target operating system. There are a lot of benefits to this approach, but is going to take a bit more work then just living in the web browser.

Decision 4: Should I use progressive web app (PWA) features or not?

Progressive web apps offer some helpful benefits:

• You can ‘install’ a PWA to the home-screen.
• They support push notifications.
• (If you built it correctly) They can be used in offline mode.

The offline support is a pretty key decision factor here. You will likely design your application differently if you anticipate needing partial offline support.

Decision 5: Should I use (ES6) class components or function components?

React supports defining components as class objects or as functions. It actually doesn’t matter which one you choose here, but you should think about it before you start your project so you can enforce consistency.

Function components with hooks are the newer style. They can help decouple state logic or lifecycle hooks into smaller pieces outside of the components, which is good for organization and keeping components small.

However class components will still continue to be supported and sometimes preferred for stylistic reasons (OOP vs Functional programming).

Decision 6: Should I use a state management store?

Avoid the common mistake of selecting a complex state management process. Think about where and how you will need to maintain state inside the UI of your application. Many applications can get away with component local state.

However if you do really have complex state needs, this is what I would recommend:

1. Choose Redux if you love functional programming and want time travel state support in your application (history/undo).
   
2. Choose MobX if want to get up and running quickly with less boilerplate code than redux.

Decision 7: Should I use client-side or server side rendering?

Choose client-side rendering if you want the easier, default React experience, and you want to reduce the number of the trips to the server for view changes.

Choose server side rendering (w/ Next.js) if you have critical search engine optimization (SEO) needs, or you need to render complex pages for low-performance clients.