This content originally appeared on DEV Community and was authored by Carlos Almonte
Don't: Return new arrays or new objects from mapStateToProps. If an object is to be returned make sure it will not be changed later on. This could lead to entire component and sub tree to be re-rendered when this object changes even the slightest.
Do: mapstateToProps should only return primitives and arrays that come directly from state (don't create a new array from mapStateToProps, if needed create a selector that caches the resulting array from arguments computation). Arrays that will be iterated later on should contain the string id of the item to be rendered. The list item is the one responsible for finding the information on the global state using the id passed from props.
Do: When building your own custom hook make sure the array to be returned is also memoized. Pre-mature optimization is not endorsed but why not build something the most optimal way you can, it does not take a significant amount of effort and it promotes learning for other engineers working on the code. Upskill the team!
Do: When building a large object, order the keys in alphabetical order. Objects are likely to grow in size and it can be very time consuming to search for a property. Especially the store, make sure the reducers are ordered alphabetically.
Don't: Build reducers that are specific to the page/screen you are building. Think how it could scale to other pages/screens. Consult with the team to see possible future usages of the pages/screens you are building.
Do: Make sure to wrap communications with external apis with a custom made API. In the future if the service needs to be replaced it can be done at this custom made API. Think of Bugsnag for example. Wrap that baby boy on a custom made API just in case you want to use Sentry down the line.
Do: On the same note. Please standardize the way errors are handled on the backend but also on the frontend. Every action in the app should be wrapped on a try/catch block and the catch block sends reports to the bug reporting tool. Your app should also wrap the entire app with an error boundary. I believe there is a proper way to establish the right pattern in place. A pattern that is able to catch all errors and report meaningful information.
Do: Use a tool that enforces code quality such as Sonar, this will save a lot of time during code review just because someone decided to use if ... else instead of if ... return. Small little details that make a developer be less creative and just follow what the sonar standards of code quality says. A codebase that follows even these details to the teeth is easy to code on from day one.
Conclusion
This is all the opinions I have at the moment. Having a codebase that enforces patterns, people can jump in and grab a piece of code from somewhere else in the codebase, paste it, change the wording a little et voila, you have a feature that meets production standards in every way possible. There are opinions but there is truly a most performant way of doing things at least at time of writing. Other approaches may come down the line but the most performant way of writing the code at moment of writing is the only way of writing the code. Easier said than done until you're met with the deadlines monster.
This content originally appeared on DEV Community and was authored by Carlos Almonte
Carlos Almonte | Sciencx (2024-08-16T00:07:21+00:00) React: Good and Bad Code. Retrieved from https://www.scien.cx/2024/08/16/react-good-and-bad-code/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.