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

Rate this content

At Mattermost we use React Native for our app. It is a fairly complex project with more than 100.000 lines of code, with plenty of challenges, like performance, reliability or offline support.
This talk will cover some of those challenges and several design decisions we have made so far to address them, along some other decisions to keep the code base readable and navigable.

18 min
12 Dec, 2023

AI Generated Video Summary

Today's talk is about how Mattermost uses React Native to develop their chat app. They faced challenges with multi-server support and offline support, but React Native's popularity and active community made it a good fit for their stack. They made decisions to improve reliability, such as using TypeScript and following coding rules. WatermelonDB brought scalability to their system, but also had challenges with a steep learning curve and database migrations. They use hooks for state management and native integration when necessary. They also implemented shared extensions and a portable device state feature.

1. Introduction to React Native at Mattermost

Short description:

Today's talk is about how we use React Native at Mattermost. I'll provide disclaimers and explain what Mattermost is. Our React Native app is a chat app with over 100,000 lines of code. We recently overhauled the app with a new architecture, interface, and revised code.

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.

2. React Native Challenges and Benefits

Short description:

We face challenges with multi-server support, data isolation, and offline support. The codebase is open for community contributions. React Native allows writing single code for iOS and Android, and tweaking the app on the native side. It's popular, with an active community. We use React Native because it uses React and fits our stack.

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.

3. React Native Decisions and Basics

Short description:

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.

4. WatermelonDB Challenges and Benefits

Short description:

Using WatermelonDB has brought us a more scalable system ready for multiserver. However, it also comes with challenges such as a steeper learning curve for teams unfamiliar with RxJS, a more rigid data model requiring careful database migrations, and the lack of support for hooks. Despite these challenges, accessing the database and working with queries is simple.

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.

5. State Management and Hooks

Short description:

We use HighOrderComponent and RxJS to get values. We compile observables to get other values, such as the current Azure user ID and the author ID. We have remote and local actions for modification, with the option to prepare records only. Our actions are properly separated in different folders. Hooks allow functionality on function components, such as storing state and adding behavior. Custom hooks modify the context, like the theme provider. Hooks also reduce boilerplate, handling actions like the back button on Android and useEffect after mount.

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.

6. React Native Code and Native Integration

Short description:

The code is simple, but creating a new reference and if statement every time is tedious. We hide complexity with hooks. Going native is sometimes necessary for better integration and specific needs. We created features like EMM, improved text input, and logging. These have strong native components and are available as open source libraries. However, some features like push notifications require specific logic. We use id-loaded notifications to address data residency concerns.

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.

7. Shared Extensions and Portable Device State

Short description:

With shared extensions, going native allowed us to overcome memory restrictions and achieve the desired functionality. We also added a portable device state feature that was missing in our library. Thank you for attending the talk and feel free to contact me at with any suggestions or ideas.

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

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2023React Advanced Conference 2023
29 min
Raising the Bar: Our Journey Making React Native a Preferred Choice
At Microsoft, we're committed to providing our teams with the best tools and technologies to build high-quality mobile applications. React Native has long been a preferred choice for its high performance and great user experience, but getting stakeholders on board can be a challenge. In this talk, we will share our journey of making React Native a preferred choice for stakeholders who prioritize ease of integration and developer experience. We'll discuss the specific strategies we used to achieve our goal and the results we achieved.
React Finland 2021React Finland 2021
27 min
Opensource Documentation—Tales from React and React Native
Documentation is often your community's first point of contact with your project and their daily companion at work. So why is documentation the last thing that gets done, and how can we do it better? This talk shares how important documentation is for React and React Native and how you can invest in or contribute to making your favourite project's docs to build a thriving community
React Day Berlin 2023React Day Berlin 2023
29 min
Bringing React Server Components to React Native
React Server Components are new topic in community, bunch of frameworks are implementing them, people are discussing around this topic. But what if we could use React Server Components in React Native? And bring all optimisation features that RSC allows to mobile apps? In this talk I would present what we are able to do with RSC in React Native!
React Advanced Conference 2021React Advanced Conference 2021
21 min
Building Cross-Platform Component Libraries for Web and Native with React
Building products for multiple platforms such as web and mobile often requires separate code-based despite most of the components being identical in look and feel. Is there a way where we could use shared React component library on different platforms and save time? In this presentation I'll demonstrate one way to build truly cross-platform component library with a unique approach of using React & React Native in combination.

Workshops on related topic

React Advanced Conference 2022React Advanced Conference 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
React Summit Remote Edition 2021React Summit Remote Edition 2021
60 min
How to Build an Interactive “Wheel of Fortune” Animation with React Native
- Intro - Cleo & our mission- What we want to build, how it fits into our product & purpose, run through designs- Getting started with environment set up & “hello world”- Intro to React Native Animation- Step 1: Spinning the wheel on a button press- Step 2: Dragging the wheel to give it velocity- Step 3: Adding friction to the wheel to slow it down- Step 4 (stretch): Adding haptics for an immersive feel
React Advanced Conference 2023React Advanced Conference 2023
159 min
Effective Detox Testing
So you’ve gotten Detox set up to test your React Native application. Good work! But you aren’t done yet: there are still a lot of questions you need to answer. How many tests do you write? When and where do you run them? How do you ensure there is test data available? What do you do about parts of your app that use mobile APIs that are difficult to automate? You could sink a lot of effort into these things—is the payoff worth it?
In this three-hour workshop we’ll address these questions by discussing how to integrate Detox into your development workflow. You’ll walk away with the skills and information you need to make Detox testing a natural and productive part of day-to-day development.
Table of contents:
- Deciding what to test with Detox vs React Native Testing Library vs manual testing- Setting up a fake API layer for testing- Getting Detox running on CI on GitHub Actions for free- Deciding how much of your app to test with Detox: a sliding scale- Fitting Detox into you local development workflow
- Familiarity with building applications with React Native- Basic experience with Detox- Machine setup: a working React Native CLI development environment including either Xcode or Android Studio
React Summit 2023React Summit 2023
88 min
Deploying React Native Apps in the Cloud
Deploying React Native apps manually on a local machine can be complex. The differences between Android and iOS require developers to use specific tools and processes for each platform, including hardware requirements for iOS. Manual deployments also make it difficult to manage signing credentials, environment configurations, track releases, and to collaborate as a team.
Appflow is the cloud mobile DevOps platform built by Ionic. Using a service like Appflow to build React Native apps not only provides access to powerful computing resources, it can simplify the deployment process by providing a centralized environment for managing and distributing your app to multiple platforms. This can save time and resources, enable collaboration, as well as improve the overall reliability and scalability of an app.
In this workshop, you’ll deploy a React Native application for delivery to Android and iOS test devices using Appflow. You’ll also learn the steps for publishing to Google Play and Apple App Stores. No previous experience with deploying native applications is required, and you’ll come away with a deeper understanding of the mobile deployment process and best practices for how to use a cloud mobile DevOps platform to ship quickly at scale.
React Advanced Conference 2022React Advanced Conference 2022
131 min
Introduction to React Native Testing Library
Are you satisfied with your test suites? If you said no, you’re not alone—most developers aren’t. And testing in React Native is harder than on most platforms. How can you write JavaScript tests when the JS and native code are so intertwined? And what in the world are you supposed to do about that persistent act() warning? Faced with these challenges, some teams are never able to make any progress testing their React Native app, and others end up with tests that don’t seem to help and only take extra time to maintain.
But it doesn’t have to be this way. React Native Testing Library (RNTL) is a great library for component testing, and with the right mental model you can use it to implement tests that are low-cost and high-value. In this three-hour workshop you’ll learn the tools, techniques, and principles you need to implement tests that will help you ship your React Native app with confidence. You’ll walk away with a clear vision for the goal of your component tests and with techniques that will help you address any obstacle that gets in the way of that will know:- The different kinds React Native tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting text, image, and native code elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RNTL tests and how to handle them- Options for handling native functions and components in your JavaScript tests
Prerequisites:- Familiarity with building applications with React Native- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Native Testing Library- Machine setup: Node 16.x or 18.x, Yarn, be able to successfully create and run a new Expo app following the instructions on