As time elapses, technology evolves continuously, and finding ways for products to remain competitive is a necessity. This is notably evident in long-running projects that grow gradually to stay relevant and competitive by adapting to trends and implementing new technologies.
At EXN, we have worked on a long-running project with Carflow, Europe’s complete solution for marketing, sales, and stock management for auto dealers. Carflow‘s goal is to create a platform that will allow car brands, dealers and buyers to connect, share information about products, and manage their purchases. Our journey with them began in 2008 and the initiative to redesign their platform has been an ongoing mission since 2013.
As new challenges emerge, fancier and more advanced technologies are needed to adapt business flows, improve speed, and enhance UI/UX. In particular to the Carflow project, the benefits of KnockoutJS were slowly fading away as the technology got old and received less support. Meanwhile, newer and better front-end technologies were gaining traction.
Introducing ReactJS to Carflow
At that point, a substantial module in the Carflow application needed a revamp to improve business flows and UI/UX. The old module was built with ASP.NET MVC and ASP.NET Web API for the back-end and KnockoutJS to render the front-end. KnockoutJS is an open-source JavaScript library that helps developers build rich and responsive websites, but its declining benefits were an indicator that it was time for an upgrade.
In other words, it was the perfect opportunity to introduce a new technology: ReactJS. We set about rebuilding the module using ReactJS as the front-end technology while maintaining the existing back-end architecture (with a few adaptations).
Why did we choose ReactJS? Similar to KnockoutJS, ReactJS is an open-source front-end JavaScript library that helps developers to create interactive UIs. ReactJS is currently the newest advancement and hottest topic in the software industry. It has a rich ecosystem of libraries and packages, and has obtained an outstanding track record in the industry and community. It also improves the standard of web page rendering performance, which was ideal for us since one of our objectives was to improve user experience.
What are the advantages of ReactJS over KnockoutJS?
- ReactJS’s Virtual DOM (Document Object Module) mechanism makes the process of updating real DOMs much faster and more efficient.
- Although KnockoutJS also has components, it is easier to develop, extend, and compose components in ReactJS.
- ReactJS has a thriving community due to its widespread adoption.
- ReactJS comes with “one-way data binding” while KnockoutJS’s “two-way data binding” offers inferior performance and allows the introduction of unhealthy patterns. That said, two-way data binding was initially more intuitive to learn and use.
- With ReactJS, we had multiple viable options of approaching state management, allowing us to choose the best fit for our data flows.
The challenges faced and how we overcame them
Transitioning to new technologies can be a bumpy road. These are the challenges we had to face with the introduction of ReactJS:
- Our team had no knowledge of or expertise in ReactJS, which meant we were at the starting line of a learning curve.
- Variety requires meticulous decisions. ReactJS has a rich ecosystem of libraries and packages, so it took time to choose the appropriate ReactJS patterns and libraries for our needs.
- Creating the new module in ReactJS meant that we ended up with two applications: the existing ASP.NET MVC App and the new React App. The challenge was then to achieve seamless transitions to ensure that users will not notice the switch from one application to the other.
How did we approach and overcome these challenges? To solve the team’s lack of knowledge in ReactJS, we held internal training sessions during the transition. We also organized sessions with a trainer and specialist from our local community who guided us through the features and quirks of ReactJS.
To overcome the slightly overwhelming variety of libraries and packages that ReactJS offered, we collaborated with a ReactJS consultant to help us choose the most suitable stack of libraries for our needs. Of the many that were available, we ended up with:
- React Hooks
- Styled-components
- MobX for state management
- Hook Forms for form validation
- Axios for API request management
- Material-UI for React component styling
In order to approach the challenge of ending up with two applications (ASP.MVC and React), we employed several solutions. The first was to host the React App as a module inside the ASP.NET MVC App. We achieved this by having a script that creates a virtual directory in IIS as part of the deployment script and binding the virtual path to the React Router. Secondly, we made the two applications share the same session by using the Axios withCredentials parameter for API requests and leveraging the virtual directory approach. The third was to replicate authorization mechanisms in the React App to match the ones in the ASP.NET MVC App. Since our application is deployed as an Azure Cloud Service, a package is created during the release pipeline. We included a script in that deployment package to create the virtual directory and copy the npm build output of the React App to that location.
The drawbacks and wins
An unexpected and slightly humorous drawback of our transition to this new technology is that there’s more competition between team members as they “fight” over the stories in the new React module. Team members love taking them on and this has resulted in greater involvement in task assigning and Sprint management since everyone wants to progress in ReactJS. It is also an extra challenge now, for Product Owners and Development Leads, to keep everything in check and balanced knowledge-wise, as well as keeping everyone motivated. In comparison to if it had been developed in KnockoutJS, the redevelopment of the module with ReactJS took longer due to the learning curve we had to overcome and the refactor we needed to do down the line.
The refactor was necessary because we wanted to reduce the technical debt that usually appears when adopting a new technology if incorrect patterns are chosen. The last drawback lies in the fact that the project now uses two front-end technologies. This means that developers need to do a paradigm switch from time to time. Furthermore, new colleagues that join the project would need to learn about both technologies, which would take additional time and guidance to ensure that everyone working on the project possesses the same amount of knowledge.
A particular benefit of introducing ReactJS was that people on the team found it very motivating and stimulating to work with the latest front-end technology. As we got past the initial learning curve, we also observed increased development speed. Furthermore, feedback from our client also emphasized that the new module was much faster and more responsive than the previous ASP.NET MVC and KnockoutJS combination. The development of this module with new technology also triggered a change in the framework used for UI automated testing: we switched from Selenium to Cypress. At the end of the day, it was a big win for the team to complete this migration successfully while overcoming each hurdle that was encountered along the way.
The transition to new and more advanced technologies can be difficult, but the wins we’ve achieved with the introduction of ReactJS to the Carflow project outweigh the drawbacks and obstacles we’ve had to overcome. As of now, we already benefit from increased development speed, improved UI/UX, greater efficiency, positive feedback from our client, and a motivated team. We aim to continuously adopt innovative technologies that benefit us and our clients so we can remain competitive in this rapidly evolving industry.