Front-end tech stack evaluation

October 30, 2020
Front-end tech stack evaluation

It was an exciting time when I joined DueDil. A new design system had just been introduced into the business which looked refreshing and slick. Planning had gone into the front-end modernisation project, that was planned to be delivered in two phases. 

- Phase one: to create a components inventory based on the DDS (DueDil Design System)

- Phase two: to roll out feature based SPAs built on top of the components inventory.

The purpose of the project

There has been a lot of noise made since front-end frameworks such as Angular, React and vue.js became popular. Since the virtual DOM and encapsulated DOM events have been introduced, on top of the optimal DOM diff algorithm, the user experiences of the applications have been enhanced more than ever.

As a tech company - among the constantly evolving technologies, the products’ code base readability, scalability and testability have always been the key concerns. After evaluating the options out there and weighed up the pros and cons, we then chose the following tech stacks.


React + Redux

Since react v16, functional components and hooks are introduced. It reduced a good portion of boilerplate code which largely simplified the code and enhanced the code readability. Redux is a state management tool that centralises the one-dimensional data flow.

From the dark times when we were utilising closure to introduce dependency injection, till we had AMD (Asynchronous Module Definition) format of a modular solution, React and Redux has pushed the modular development further. We are able to separate logic with representational components and container components, where one concerns how things look and the latter concerns how things work. 

Modular pattern, easier readability and clear separation of presentational and data logic are what we strive to achieve for better code maintenance and scalability.

Typescript

As javascript is loosely typed, the type coercion and scope hoisting in javascript naturally astonished developers who are coding in strongly typed languages. Its shortcomings especially unveil in developing large-scale applications. 

Typescript is a better way to adapt in rolling out larger applications where a bigger team is involved to maintain strict coding, reviewing and testing workflow. In rolling out the components inventory, we have set the global type interface being reused in phase two, with a typescript compiler that rules out significant coding errors, it overall improves the code quality.


Storybook

Storybook is another UI documentation tool we introduced for an intuitive interface where designers and developers can collaborate. It runs outside of the main app for developers to focus on the virtual consistency and functionality of each component. It has various add ons such as knobs and actions for interaction controls and providing live testing cases. Its systematic displaying nature, it exceptionally serves as an interactive style guide and documentation for knowledge sharing.


Testing frameworks

Jest and Enzyme are the test libraries we chose for unit and functional tests. Compared to Mocha and Jasmine, Jest is a library developed especially for React applications, which require less dependencies and is well documented and is actively updated. 

Enzyme is a popular testing utility package that works well with Jest. It simplifies in rendering components, finding and interacting with elements. 

For end to end testing we utilise Cypress, which can almost test anything in a browser and is more intuitive to work with. After all, it is important for developers to pick the testing up and test away.

Apart from the mentioned frameworks we utilise Redux-saga for handling asynchronous workflow as well as Nivo and D3 for various data graph visualisations and there are more to mention.


As a front-end engineer, it was rewarding to see the components inventory become interactive. While we are able to focus on the look and feel of the components in phase one, in phase two we can utilise the components to focus more on the logic and data flow. 

It was not uncommon that we were refactoring the code by writing more helper functions, separating strictly the containers from representational components, centralising the data normalisation functions and many more. 

It is ever so valuable to be in a team while everyone is highly aware of the code hygiene and code quality. Nurturing in a cooperative and helpful team, you naturally absorbed the knowledge faster and form good coding habits to grow into a better engineer in DueDil.


Author: Xiaoxia Li - Front-end Engineer

Sign up to the latest DueDil news!
Follow us on LinkedIn or subscribe to our new feed to receive updates on our product and events
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.