Drawbacks of Using React
Which form library do we want to use? Which state management library is currently the best? Which router is ideal for our application?
If you have ever worked with React, you have probably asked yourself these questions before starting a new project. Having many choices is generally not problematic, but React developers worldwide have looked into the same questions and, with a high probability, come to different conclusions than you did.
In your project, you are familiar with the directory structure and the different libraries that you are using. However, if you join another company or want to work on an open-source project in your free time, you will have to get used to the choices made by another developer. In open-source projects, this costs “only” time, but in company projects, it takes both time and money.
At finstreet, we have created many React applications and have faced these problems before. And we needed to provide both faster and cheaper solutions to finishing projects to our clients.
Finstreet Building Blocks
Our first step was to use a fixed set of libraries/frameworks. These are the libraries that we chose to respond to our different challenges:
- Next.js → “The React Framework for Production,” which offers a pleasant developer experience, a good base for our directory structure, and some more perks that will help us build our applications faster.
- ChakraUI → “ChakraUI is a simple, modular and accessible component library that gives you the building blocks you need to build your React applications.” Everything that ChakraUI mentions on their homepage is true, and we enjoy building applications with ChakraUI.
- React Final Form → Complex form wizards are an essential part of our applications. React Final Form makes it easy to develop these complex forms.
- Zod → A great validation library in combination with TypeScript.
- React-Query → Never has data-fetching been easier, and React-Query often removes the need to use a state management library like Redux.
We figured that one of the pain points for our developers after switching to a project is to get used to and learn the application’s libraries. Especially component libraries have different philosophies on how to style your components. Additionally, Next.js offers an excellent directory structure. Having a fixed set of libraries and identical project structure in each and every project helps us develop new applications faster and allows developers to effortlessly switch between projects.
Finstreet Form Wizard
The most integral part of our flagship product – eco.banking – is a complex form wizard. The information our partners need from their customers in order to grant loans differ vastly. Depending on the partner, we might have to build a new form from scratch.
The complexity grows in our application with each new partner because we try to reuse components wherever possible, but we keep adjusting details due to different requirements.
After we transitioned to the fixed set of libraries mentioned above, we started to extract all components that we needed to build forms from scratch. These components were moved into their own library. This library enables us to create a new project per partner while still being able to reuse most components. It reduces each partner’s form complexity and helps developers focus on completing their tasks at hand without struggling to control side effects for other partners.
However, we do not want to stop at having a library for eco.banking. Traditionally, we build many inquiry processes at finstreet, so the form component library will be used for eco.banking as well as all new projects in need of inquiry processes. We will face some challenges with this step as the components need to be absolutely flexible to fit different partners’ needs and completely new UIs.
Fullstack For The Rest of Us
Our applications primarily consist of a Ruby on Rails / Django backend, which provides data through an API to our React frontend. If you have worked in this kind of stack before, you know the pain of syncing with the backend team to send parameters correctly for the API to accept. Another pain point is validation. With complex forms come complex validations which have to be developed and synced for frontend and backend.
Finally, there is an excellent full-stack solution for React developers: Blitz.js. Blitz.js is built on the principles of Ruby on Rails and Django but offers a lot of improvements over these frameworks. In my entire career, I have never created an application faster than with Blitz.js. Some cool features of Blitz.js are:
- “Zero-API” data-layer → in your frontend code, you can directly import backend functions, and during compile time, the function is swapped out with an API call for you. With the help of TypeScript, you do not have to figure out which parameters you sent to the backend. The imported functions are fully typed!
- Shared validations → Program once, validate twice. You only have to maintain one set of validations because you can use them in your frontend and backend code.
- Built-in Authentication → After you scaffold your project, Authentication will be instantly set up for you.
- Code Scaffolding → One command generates all the files you need for a new set of CRUD operations.
Blitz.js is still in beta, but once it hits production, we will start building applications with Blitz.js and use the components mentioned in our first step – a lot of these libraries are already used by Blitz.js.
Summary
There is a lot more work ahead of us. However, we believe it’s fully worth the effort. Not only can we increase the development experience at finstreet. Since each developer will already be familiar with all project libraries, we will also be able to finish applications significantly faster and reduce costs for our clients.