React created roadblocks in our enterprise app

As a counter point, I was almost fired for not choosing to build a SPA for an internal app which was going to be used by 3-5 people, 5-10 times a month, if that many.

I worked at large accounting software provider, and internal billing system used static pricing which was changed once a year. The company wanted to move to a more flexible system where pricing can be setup based on few rules like customer type. For this the ui and backend system needed to be developed. Design I proposed was a single "monolithic" service which did everything including UI and UI was supposed to be a old style mustache templates and some minor jquery. Instead they went with pub-sub systems, 4 different microservices, a react based UI, api which used json-schema, even to send data back to UI. When I left a team of 6-7 people was working full time on this and they were about 20% done.

> And I am not even considering the time that each developer spends on learning all those third-party libraries. I never saw two React projects with the same dependencies, project structure, and guidelines. This means the knowledge is not transferable from project to project, as can be the case in Angular or Vue.

For a developer just looking to make the thing their design team sent them as quickly as possible, this makes good sense to me. And I get that project/file structures can be wildly jarring to an uninitiated dev - I remember looking through a Java repo for the first time :shudders:

But! Isn’t there a necessary step of understanding why decisions were made the way they were? In my experience as a front-end eng, even if a previous project involves other-worldly dependencies or FS compared to the one I’m on now, if I understand the trade-offs of the approaches for the previous project, no amount of knowledge is untransferable.

The problem is not about react or not react, the problem is how to align big team to create an application. If a big team is going to be working on it you need some strong opinions around it. Do not mess with the package.json. I cant stress this enough. Actually, the most important file in your whole application is the package.json. Almost nobody should be allowed to add additional dependencies because is the main point to generate chaos and problems in the long term.

Also, the design system matters a lot. Have a small team working on the UI components to tailor and extend the design system. Dont allow the rest of the teams to extend the ui components with new libraries. Stick with the design system as much as you can. The rest of the teams should minimize the amount of CSS they have to write to components placement.

Usually the datagrid is the soul of any enterprise application. Choose it wisely and be sure it covers as much functionality as you can and also that it is customizable on an "easy" way. There is always a team with the need of a datagrid that sorts, groups, filters the data with dynamically adjustable cells and multi header items without pagination. Welcome to hell.

Use one pattern: hooks, central store, whatever you want. If at some point you have to change it you have to know which teams are using which one. Dont allow team members of the same team follow different patterns. Code reviews must take care of this.

Hope this small tips help one or two teams out there. I have worked on the migration of 5 big enterprise applications from angularjs to react or from legacy desktop application to react or from server pages to react.

I made a lot of mistakes that costed a lot of dollars. I have tried to learn from them. Also, dont take me very seriously, I am pretty sure I am about to discover another mistake I have made.

React feels more like the Spring Boot response to Angular's J2EE.

But yes, I prefer the microframework approach.

I've worked on stacks with .NET backends and React frontends, and there's a ton of truth to this. You can't use .NET concepts to bridge into an understanding of React. If you need to carry over .NET's paradigms, don't pick React.

Personally, I think if you want a deep understanding of React you need to first get in a few cycles of working with DOM, JS, CSS, etc. directly. Maybe throw in a functional programming language too. Then try to pick up React.