• Styled Components
The customer was looking for a team of experts to write a new version of the application frontend while maintaining API compatibility with the old frontend.The project’s key challenge was preserving all the functionalities of the old system in the new one using a modern design. Maintaining compatibility with a very inconsistent, complicated, and extensive API created over many years of system development was another challenge our team had to face. On top of that, the API could not be changed due to compatibility with the old UI. The new or old UI had to work similarly.
To make matters even more complicated, the system has a lot of personalization options:
– Dates as input and display method (~10 formats to choose from)
– Format of numbers, percentages, and currencies (the number of decimal places, the way of presenting negative values – e.g., a parenthesis and red color instead of a minus, or location of the currency sign).
To address these challenges, our team used a layer of services responsible for most of the business logic and translating the API for consistency and usability. We also tested these services thoroughly. To deal with the matter of different date and number formats, we created a library of components prepared to handle all these elements via a global configuration injection during application loading.
To deal with the matter of different date and number formats, we created a library of components prepared to handle all these elements via a global configuration injection during application loading. Our team rewrote the system modularly, starting with assembling the list of contracts and their editions. We also edited the rules of the `Product Hierarchy` type and developed new features for it, like the rule negotiation module (per row, change history of each row, similar rows in other deals — Similar Deals).
Technologies used in the project:
React – the client’s choice.
Typescript – despite a slightly slower development at the beginning, Typescript helped us solve a lot of problems later. The technology was chosen following our suggestion and our team gradually rewrote the system into Typescript.
Git – the client initially used the centralized version control system SVN. However, we moved to Git following our suggestion that it’s a more suitable solution.
The client’s team prepared cards with the listed requirements, and our team implemented them, catching up regularly with the client.
Our experts created the entire core flow of the system—the creation of agreements and rules within those agreements. There’s a lot of complexity embedded in this system. We have two types of agreements and 50 types of rules that customers can configure in many ways. We created a library of reusable components that hide the complexity of the system and allow users to expand it by assembling it from ready-made bricks.
On top of that, we’ve essentially completed everything else, including Claims and their editing. Claims are reports generated by the system based on the agreements, rules, and batch data from customers, which show who owes money to whom. Additionally, we’ve included a reporting module. So, in effect, we’ve nearly completed the entire system.