We spoke with TJ VanToll from the Kendo React team at Telerik on CodeItLive. You can find the recording on React in the Enterprise here. The conversation was an interview format around using React in enterprise application contexts. Naturally, React is an excellent, modern choice for JavaScript applications. At the same time, using React isn’t a magic bullet solving all enterprise woes. That said, neither is Angular, Vue.js, or anything else for that matter. I encourage you to have a listen to the broadcast. Below are some highlights from the conversation.
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 in 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 life cycle and allowing component logic to be free from business logic.
Many React developers can articulate out 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 in 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 a 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.
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.
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.
One idea is for new React developers that aren’t familiar with Functional Programming, is to spend a bit of time with Functional Programming materials. Mike recommended Tyler McGuinness’s excellent courses that can be found here, specifically Advanced JavaScript.
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 since given the details of your own application.
In summary
The discussion was a fun and interesting one covering a wide range of topics on React and JavaScript in enterprise application contexts. Great applications can be written and maintained for a long time using modern JavaScript. This job can be much easier if the development team embraces Functional Programming concepts, architects the application with a consideration to what could/may change in the future, and deals with uncertainty by creating architectural seams where appropriate.
CodeItLive will be broadcasting React topics on Twitch each Wednesdays at 1PM EDT. We’ll be sure to tune in regularly.
