Our firm specializes in helping organizations use React well in enterprise contexts. We spoke about enterprise application development and React with TJ VanToll from the Kendo React team at Telerik on CodeItLive. You can find the recording on React in the Enterprise here.
Update: Since this article was posted, we’ve since done shows with:
- Răzvan Dragomir, author of I Almost Got Fired For Choosing React for our Enterprise App
- Paige Neidringhaus, Senior React Developer at Home Depo
How to use React in really large apps
Please check these resources if you want additional content on Enterprise React.
It’s OK if you aren’t using the most modern techniques
React was released in 2013. Since then, React has evolved into what we know as modern React development. Along the way, however, there have been several shifts. One example is how components are architected. The older way to build components was to use higher-ordered components and classes. Over time, the best practices morphed into using hooks and functions. Hooks provide a cleaner way of separating out concerns from the life cycle and allowing component logic to be free from business logic.
Many React developers can articulate the benefits of using hooks- even if they aren’t using hooks in their own projects. It becomes more complicated in knowing how to migrate an existing and large codebase that was designed and built before hooks were available. Should all of the code be rewritten? Could one adopt hooks incrementally? Mike offered some advice on how React enterprise applications can migrate towards hook architecture in an effective way.
What works well for a TODO app may not work well for an Enterprise app
Enterprise apps, by nature, have complexities that are hard to account for in sample applications. A sample application is generally designed to show how to make a full round-trip with a piece of software. By following instructions and building a given sample application the developer will learn key concepts needed to be productive with that software.
Many times, the best sample apps are contrived, simplistic caricatures of real-world applications. After all, even a real TODO app would have tests, authentication, configuration, preferences, and many other elements that just cloud the point of using a TODO app as an example.
Unfortunately, those new to technology will have to apply the architecture and patterns learned with the sample application experience, into their real-world projects. The differences between the two create friction and can lead the developer to use patterns that are not ideal for the situation.
There are many differences to account for when building enterprise applications with React. We’ve listed some of them below with short summaries. The full detail can be found by listening to the recording.
Being careful to architect seams in your application prevents massive issues later
One way to avoid ugly surprises later is to build in appropriate seams into an application. A seam could be a façade, adapter, or another pattern commonly talked about but boils down to creating a fence around a certain piece of functionality that insulates change. Mike talked about the importance of architectural seams in software development during a recent presentation that you can find here.
By recognizing elements of an application that are likely to change, like external libraries, APIs, other components, or even business logic ripe for evolution, the software developer will be able to implement a seam so that the change can happen without undue side effects.
The React library contains certain features like hooks and state management that can be used to create seams in a React enterprise application.
You’ll be a better React developer if you understand Functional Programming concepts
React was designed according to certain functional programming concepts. This means that a developer trying to apply Object-Oriented Programming will not necessarily be in the best position to use React in the way it was most intended. In order to get the most benefit from the React library, one must accept the patterns and opinions in React. This necessitates an understanding of Functional Programming principles like memoization and immutability.
The right choice of state depends on how your application works
TJ lobbed an interesting grenade question to Mike about choosing the right state management solution for apps. Naturally, the concept of state and state management is often debated in React and there are many with their own views. Handling state correctly in React enterprise applications is an important architectural decision and one that must be kept consistent in order to reduce development and maintenance time.
Mike called out that in larger applications, it can be difficult to have a single, global state management. In some of the larger apps, Digital Primates works on, there can be multiple state management strategies in play, depending on the details at hand.
The takeaway here is to not just take the advice one reads on blogs but to understand the pros and cons of the common state management systems in React and implement the one(s) that make sense given the details of your own application.