The main reason we use React Native at Mattermost is because it uses React, allowing any frontend developer to develop features for mobile apps. We made several decisions to make the app more reliable, including using TypeScript for type checking and refactoring. We also prioritize folder organization and have coding rules in place. Our components follow a specific order for props, styles, and exports, as well as for hooks, assignments, callbacks, and effects. Now let's move on to state management using Redux.
But the main reason is that it uses React. Using similar technology to the rest of the stack allows any frontend developer to develop features for mobile apps. And in that way, a small mobile team can be responsible only for the nitty-gritty of the native design. But there have been more decisions along the way.
These are a few decisions I framed into making the app more reliable. The big one is using TypeScript. What is TypeScript? Summarizing too much, it is JavaScript with types. We all love how flexible is JavaScript, until we have a big project and we don't love it anymore. With TypeScript, type checking, refactoring, etc, becomes way simpler. I introduce less errors to the code. Practically, the whole code in our app is written in TypeScript. To follow REaD guidelines, we also move a lot of components to functional components. It's not only the recommended approach from the REaD team, it makes it harder to make huge components, even if it's only by the easy feeling of seeing 1,000 lines long function. We also try to specialize, to especially care, to be especially careful about folder organization. For example, the screens are in some folder, separate from the common use components. Being things organized helps to find things not only for us, but also for contributors. And finally, we have many coding rules all over the place, from basic Linting rules, to import order, to some component style guidelines. So let's look into that a little bit.
Take a look at this example component. Our components usually have the props, the styles, the component and the export always in that order. That way you know where to look for stuff. Also, the insides of a component have a standard order. First, the common hooks, like getting the theme, styles, then all the assignments, like states or auxiliary variables, then all callbacks, and just before the render, all the effects. Why this? Because having things ordered reduces the cognitive load when reading a long component. When effects and callbacks are mixed, it gets very complicated to distinguish between them and see what has really happened, both when trying to understand the component or when you are code reviewing the component. And that's it for the basics. Let's move to state management. As almost everyone with a React project, we use Redux for our state. But there was a problem. First of all, the completed state had to be in memory.
Comments