How Do We Use React Native at Mattermost. Architecture and Design

Welcome, everyone. Today I'm here to talk about how do we use React Native at Mattermost. My name is Daniel Espino-Garcia, and I am a software design engineer at Mattermost. If you want to contact me, feel free to drop by the office at Mattermost community server.

First of all, I want to give you some disclaimers about today's talk. What I'm going to talk, is the best solution for any project? No, of course not. Each project is different. Then is there a solution for your project? Depends on your project, but still probably not. My hope is that this talk can spark ideas that you can use in your projects. Is this the best solution for our project? I hope so, but probably not. We are not perfect. We haven't assessed all the possibilities. Every day we learn something new, and every now and then, a new technology appears. This is just what we have tried so far, and worked for us. If you think anything can be improved, please come by the office and let me know. We are always happy to do things better.

With that out of the way, let's start. Here is the agenda for today. So, just to be traditional, let's start with the first point. Why this talk? Let's start explaining what is Mattermost. Maybe just looking at the image you get a good idea of what Mattermost is, but a part of a long definition in our website, we can get a more mundane description. An open source alternative to Slack and Microsoft Teams. This is much more than that, but that gives a broad idea of the basics. And of course, we have a mobile app written in React Native. So, great, Mattermost is a chat app. What makes it interesting to talk about? Well, first of all, the React Native app has a decent size. More than 100,000 lines of code. And so, we have recently done a complete overhaul of the app. The first version was facing some challenges, and we remade the app. New architecture, new interface, and the most of the code, revised and rewritten.

And we believe there's a lot to learn from that. But there are also several challenges that we hope to make the process interesting. One of the biggest ones is support for multi-server. Working with multiple versions, Mattermost is self-managed, but the app is distributed through the stores, so the app must be backwards-compatible. And with multiple servers, the data isolation becomes a huge challenge. You don't want a message meant for a family server and an in-your-works server.

And our big challenge is offline support. People don't expect to receive messages when they're on a plane, but they for sure expect to check the previous messages. And the codebase is open for community contributions, so it is even more important that new eyes are able to understand the code well. Because yes, most of the code is open source and that includes the mobile app! The complete code of the mobile app is in GitHub, so everything I will talk about today is something you can check directly in the code, learn a bit more about it, and even tinker with it, be it in your own fork, or contributing upstream. I hope these are enough reasons to stay on this talk.

Now let's talk about the basis. Here we will cover some general decisions on the project. For example, where are we using React Native? Let me start with what is React Native. You have the official description, but it can be crudely summarized to React Mobile. One of the main advantages, as many other frameworks, is that allows you to write single code that works on iOS and Android. It also allows you to tweak and extend your app on the native side. You need a super-specific native feature for your app? You can dive in the native code and create it. Another important thing is that it's pretty popular, and the community is quite active. Most of your answers are one Google search away. And finally, this will be important later, React Native is written in JavaScript.

And why do we use React Native on Matrimons? Let's see our stack. If we look at the backend, the server code is written in Golang. But on the front side, the browser code is written on React, which uses JavaScript. The desktop app uses Electron and React, that again uses JavaScript. And the mobile app uses React Native, which uses JavaScript. You may see already a pattern. I could talk about alternatives with pure Native or Flutter, but it all boils down to one big reason. Because it uses React. React Native has many other great things that pass up on this.

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.

This is great when you have a relatively small state. But our state is huge. Teams, channels, posts, memory issues were meant to be.

The next problem is related to offline support. All the information has to be persisted in the form and then loaded back. And the app cannot start if certain parts of the state are not loaded. But the whole state has to be loaded. So the initial load will take longer.

And the final issue was multi-server. It was not possible to implement multi-server. Why? Because the problems I just mentioned get multiplied by the number of servers becoming completely unscalable.

So we decided to move to WatermelonDB. Why? The state is stored in a SQL-like database, so there is no need to have it completely loaded in memory at any time. We just need to get it from the database. But isn't that slower? Since the query state is cache, maybe it's slower on the first query. But as long as the cache is hit, it should give no problems.

Then all the reactivity to the state uses RxJS. And we can create separate databases for each server, helping a lot with that isolation. At the end of the day, WatermelonDB brought us a more scalable system ready for multiserver.

But not everything is wonderful. WatermelonDB also had challenges. Among other things, RxJS is new to the Mattermos stack, so it needs some steeper learning curve for the feature teams from the rest of the company. The data model is a database relational data model, so it's more rigid, and that leads to take care of database migrations, which in general sounds more like a back-end problem than a front-end problem. And sadly, WatermelonDB does not support hooks, and you have to rely on high order components.

But all that aside, using WatermelonDB has been worth it. And I will show you a bit about it. Accessing the database is simple. We have put all the queries under the queries folder, and they are mostly three. Get a single value from the database, observe a single value for changes, and create more complex queries that can be fetched or observed. Getting the state from the database into a component is also not complicated.

We use this HighOrderComponent and RxJS to get the values. You see that we use the observe functions I talked about before, and then we compile this observables to get other values. In this example, we get the current Azure user ID. From that and the channel name, we get the author ID. And with that, we get the actual user.

And what about updating the data in the database? For modification, we have put together what we call actions. And we separate them in two types, remote and local. For us, remote actions are those that go to the server to get information, and may or may not store information to the database. Therefore, we have the fetch only option to make sure we only store what we want to store. Local actions just update the database. So many remote actions can call local actions. But also, we have an option to prepare the records only. Where will we do that? To batch several database actions into one. And as you can see, we have the different actions properly separated in different folders, so you are sure that the ones you are importing goes to the server or stays local.

So with the state management out of the way, let's take a look at the hooks. Hooks is something I like a lot. So sorry if I get a bit passionate. I hope you all know what hooks are, but let's review it one moment. Hooks are a small piece of code that allows some functionality on function components. For example, storing the state, memorizing values, adding behavior, or the most interesting of all, a bit of everything. So let's look at what we have done with custom hooks. Adding and modifying the context. With the theme, server, or internet history provider, let's take a look at the theme provider, for example. The custom hook is pretty simple. Use theme just returns the value of useContext. What has a bit more interest is the theme provider itself. Based on several values, we make sure we pass the right value to the provider. With this, any component that needs to be styled based on the theme just have to call useTheme, and all that complexity is hidden from the developer. Another thing we do with hoops is reduce boilerplate. There are many actions that are not especially hard to implement, but just add a lot of boilerplate to the code, so we have extracted that boilerplate to some hoops, for example, handling the back button on Android, or the navigation buttons pressed, or modifying useEffect only to execute after mount, so we have a div mount that we use to have on glass components.

As you can see, the code is pretty simple, but having to create a new reference and create the if every time you want this functionality is boring, so we just dehook and that's it.

Another important part is making the life of our colleagues easier, hiding all the complexity from some features so they don't have to deal with them. There are many features that have complex implementations, as we have seen there, especially we shouldn't be writing those solutions over and over so we can hide this amount of complexity you see here with a hook that is used simply as that.

Let's go native. But we said, one of the good things about React Native is that you don't have to care about natives. You just write JavaScript code. But sometimes it's needed to go native. One of the reasons may be resource limitations. In other words, the reasons because you want to better integration between the native functionality, like push notifications with your application. But why not use libraries that exist out there? In some cases there was none. But at least we couldn't find one that completely covered our needs. Another reason is that on our case was too specific. And none of the available libraries solved the issue the way we wanted. So what did we do? Really, we found some stuff that we didn't find any library there. We create them. These are some of the features we needed. For example, EMM. A way to make sure sessions are separate when dealing with multiple servers. Improved the way we handle text input, or even our logs. All this functionality have strong native components. We thought all these are general enough, so we made open source libraries. So everyone can use them if needed. If you are interested in one of them, feel free to drop by our GitHub and you will find them there.

But there is also a few features that were not general enough. For example, push notifications. We had a lot of logic that is specific for our project. For example, we have something we call id-loaded notifications. Since notifications go through the push notification services, there may be data residency concerns if the content of the message is sent. So how do we fix that? We just send id, and when the notification reaches the phone, we contact the server to get the content of the message. That way the message never goes to a third party, and the mobile still shows the content of the message.

With shared extensions, the problem was about memory restrictions. We wanted to do too much, and the whole React framework was taking too much memory. So going native there allowed us to do everything we wanted.

And finally, we also added some functionality to be able to go to a portable device state. We didn't find that in our library, so we just added it.

Yeah, that's all for today. I hope you liked the talk. As I said at the beginning, this is just what we have tried so far that worked for us. If you have any suggestions or ideas, please send them my way. Thank you very much. And remember, if you want to contact me, just drop by the office at community.modernmos.com.