In Part 1 of this series, I gave a start-to-finish overview of how we at UNRVLD integrated a React application into an Optimizely ASP.NET MVC website.
I'd like to delve into several aspects of the process in more detail over the next few parts, starting with the choice of React itself and the specifics of how we actually implemented it, given there were (as there always is with anything front-end...) several options.
Why a Front-End Framework?
JavaScript is easily the most flexible way of implementing a performant, user-centric experience in a browser. Your HTML gives you structure, CSS makes it pretty and JavaScript manipulates it as necessary.
At some point, the amount of JavaScript code increases and the amount of manipulation required - even with the help of some still very popular libraries... cough...jQuery...cough - reaches the point of being unmanageable and unsustainable. FE frameworks have, in recent years, really risen to address these limitations.
Taking on a project to do exactly what these frameworks are designed to do really meant it was a no-brainer to go with one.
But which one?
The decision of which front-end framework to build on given a reasonably blank slate is always a challenging one. The stereotype of the front-end development landscape changing every 15 minutes is not entirely undeserved - the choices are, indeed, ever more numerous.
But the big name players are still React, Angular and Vue, in my opinion (and I fully confess there was a lot of my opinion in the decision phase here!). Other noteworthy candidates were Next.JS and Svelte.
However, for reasons including (but not limited to):
- In-house developer experience
- Learning curve
- Community support and documentation
- Training availability
- Package library diversity
...we chose React.
And then we added TypeScript.
As I mentioned in Part 1, I've been someone who was - despite my years of experience and interest in new development tools - actively resistant to adopting TypeScript. But I'm willing to admit I was mistaken. It has definitely grown on me.
The supporting tools in IDEs like VS Code are really excellent and the assistance you get when developing actually does help significantly. I can't see us starting any significant piece of JS development in the future without using TypeScript.
I have no doubt that:
- perfectly valid arguments could have been made for using a number of other frameworks
- we would have successfully produced a solution using any one of those number of other frameworks
But React it would be for us for now.
Integrating with .NET
Since we remain somewhat constrained by a traditional MVC architecture and a UI rendered using Razor views, we needed a way to integrate the React app into the site.
One potential option would have been to use ReactJS.NET - a platform almost specifically built to do what we were trying to do. But the coupling of Razor and React required by this tool just felt "wrong", and would have left us inseparably tied to React (a view also expressed by the Optimizely team themselves). Given our "proof of concept" stage, maintaining the ability to swap out one framework for another one in the (unlikely-but-you-just-never-know) event of reaching an insurmountable road block was important.
create-react-app
The de-facto standard when starting a new React application is to open a terminal and run npx create-react-app. Again, we decided against this. Whilst this app does indeed give you absolutely everything you need to create, build and deploy a React application, it includes a bulk load of features that we didn't expect to need and we weren't creating a Single Page Application (SPA) - something create-react-app is very much angled towards.
Our app was going to be a fully built-by-hand endeavour. Starting with a brand new working folder and npm init and a src/index.tsx, off we went.
Top comments (2)
Very nice! Where's the rest of the series, particularly how you implemeneted SSR? :-)
Excellent write up so far, I too am wondering how you implemented the SSR!
I strongly agree with your sentiment on typescript. I can't imagine writing a large interaction, e.g. a checkout, without it.