React ATL: Building Scalable Applications using React
Our very own Neil Banchero-Smith and Grant Powell were the speakers for React ATL’s April meetup. Neil and Grant talked about lessons they learned working on a rapidly scaling software platform. In this talk they gave tips and tools on how to write react in a flexible way that will save you time, energy, and headache as you scale your application.
They opened up the session with a friendly game of Mad Libs which helped immediately engage the audience at General Assembly Atlanta, but also set the stage for some of the common challenges we face when moving from a quick-to-launch React application to a more reliable, scalable application.
Next they detailed the three things you want to think through when building a web application:
- How to present the data
- Business logic
- State management
When you start an application thinking through these points, it helps when you need to take your app and scale it for thousands of users. Grant and Neil then gave examples of thinking through these principles on small scale, the challenges that arise when you need to scale up your application and the ways we’ve addressed these challenges at SalesLoft.
Progressively Awesome Presentation Components
One big improvement in clarity for big applications is the differentiation between stateful (“containers”) and stateless (“presentational components”) components. Containers manage data or are connected to the state and generally don’t have styling associated with them. On the other hand, presentational components, also known as dumb components, have styling associated with them and aren’t responsible for any data or state management. Basically, containers are responsible for how things work, and presentational components are responsible for how things look.
Splitting our components like this enables us to cleanly separate reusable components and intermediary layers of data management. As a result, you can confidently go in and edit your components without worrying about your data structures getting messed up, and you can edit your containers without worrying about the styling getting messed up. Reasoning through and working with your application becomes much easier that way.
Framework shouldn’t dictate our business logic
If there’s ever a time when you have to change your framework, you don’t want to have to rewrite all of your business logic in the process. Grant referred to a talk and blog post by our own Steve Bussey about pulling out your business logic from your Rails code — but this is something that works well on the front-end or backend.
As an IRL example of this, at SalesLoft we are in the process of moving from AngularJS to React. We have so much business logic tied up in AngularJS that we are having to work through large refactors of our AngularJS controllers to pull our business logic out into separate ES6 JavaScript modules and have React only hold our presentation layer code. However, going forward, if we decide to move from React, to say Vue, we’re only making changes to our presentation layer and our business logic code is still viable. This approach also makes for more testable presentational components, as you can give your component a different set of props, instead of having to mock everything.
Grant Powell and Neil Banchero-Smith are engineers at SalesLoft. Grant enjoys long walks on the beach and web development. Grant is interested in building scalable customer facing web applicatio ns and has enjoyed his work helping scale SalesLoft to almost double the user base since he started. Neil likes building responsive applications that make daily tasks a joy to use. Neil is always interested in user experience and improving lives through tech.
