Architecting Reliable React Systems in Unreliable Environments

Hello everyone. Welcome to React Summit 2026. I hope you all are having a good time here. Thank you for joining my talk and I'm really excited about it. Today, we'll be talking about architecting reliable React systems in unreliable environments. So let's get started. Have you ever seen a screen look fine while the system is actually in a bad or wrong state? I am sure. Like many of you have seen this, especially working with React systems, like a spinner that never stops. A saved message after a failed request. Stale data on the next page. Bugs that do not crash. But the system under the hood is not working properly in a bad state. So today we are exploring how to fix this with architecture and not more retries or like ad hoc hacky ways. So let's go.

About myself, I'm Rajnikadia. I'm staff software engineer at Hinge Health and I design and build reliable systems for connected devices in regulated environments. My focus is architecture and reliability for mobile apps, variables, and BLE hardware in active patient care programs. Here is my social media links so feel free to follow or connect with me. Also, I am working on building a BLE validation platform, which is open source. This helps to build a profile-driven BLE testing framework. So if you don't have a physical device, you can use this to simulate a device and it's very flexible. So give it a try.

Okay. So the main issue. React is predictable. The outside world is not. Your UI seems fine and under the hood it's working differently. Your UI assumes that everything should be in order in sequence. But in real, it can be different.

But in real, it can be different. Like the API fails or connected device drops the connection intermediately. So the real world situation is totally different from what we expect.

Why is async complexity explodes? So that can be many reasons. Like many things happening at the same time. Like you are interacting with the UI. There is an API call. You are connecting with a Bluetooth device or a connected device and it drops in between. There is a retry. So many things can impact your app flow.

So for example, you save a click button twice or three times and you don't have a throttling. So the earlier API or click request is pending and you're still spamming that flow. The second is no one owns the plan. So what I mean by that, like there are multiple UI effects and each UI effects has their own lifecycle. So one doesn't know how the other is doing or what's the sequence between them unless we use a hacky way of like using a user ref.

So a multiple user effect is a problem and no one coordinates them. So whenever you notice that a multiple user effect you need to fix that issue. Third is state lives in too many places. Like you are using useState, useRef, or like a state singleton instances and there is no link between them. So it's hard to debug or even trace any issue like a spinner or error or all this. Like which is the issue when we see something on UI. It's hard to predict which state is deriving this particular UI.

Real world reliability failures. So these are the cases like a device was connected, why session is dead. So for example, on the screen you say okay device is connected to like a green checkmark UI. But in reality, it's doing like a retry or actual connection is already dropped. In case of API, it's like similar thing happen. It may say okay this is the live data but actually the API failed or it's in an error state. So there is no sync between the UI and actual system state. And retry storm after brief disconnection.

So for example, there are 50 requests for retry in 10 seconds. So it might look fine on the UI but under the hood it's spamming the backend like multiple retries without any connection with your UI. So that's a sign of like something is not going well respective to state management. State closure. So UI displays stale data. So again, I said like you requested or you connected to device UI saying okay you are connected or it is dead. But it might be showing the data from the last session or last stale state.

Another example, like a background and foreground. So for example, if you are working with a mobile application or even for web browser, you are switching between the tabs, you are getting a focus, losing a focus. And in case of mobile app, if your background program let's say you are working on a connected device. So when you come to foreground, you try to reconnect to your device. So here let's say somehow app is doing multiple time background foreground. So at this, if we don't use like a particular state management system, your app can spam about retrying to the state, retrying to the connected devices and that can have like multiple connection and only one is active but the rest is just retrying. So which may put your app as well as your device in a bad state.

OTA update interrupted. So for example, you are working with a connected device and you start to update the firmware on that device. So somehow that failed or interrupted due to let's say reconnection or some other reason, then app stuck into that limbo state. So there is no sync between the app and a UI and actual state.

Another classical problem is a Boolean soup problem. When we start a react app, we might use multiple state variables leading to issues like out-of-sync states, triggering additional side effects, and difficulty in debugging. This complexity can result in UI being in a bad state and confusion in displaying the correct UI based on multiple states.

Use effect dependency chaos is another challenge. When working with network-connected devices and following a use state pattern, there can be issues with state updates triggered by device connections. This can lead to chaotic UI states and difficulties in deriving the correct UI representation based on multiple individual states.

It might work properly but I'm sure there will be issue because when you take that state and you need to update the state. So if there are 50 states, then somewhere in either in a callback, like click callback or in a use effect, it will be calling okay set state something, set state something and all are out of sync of each other and those state might also be in a dependency of use effect. So things can be very messy, like we don't know which state is updating when and it will put your UI in a bad state. So maybe it looks like it's working but it may trigger an additional use effect, it can trigger additional external call side effect and you don't have any control on that. It's very hard to debug.

So for example, here let's say we have a we are implementing a state management for bluetooth connection. So we might have variables like states like is connected, is connecting, is scanning, so retrying has an error or syncing with the backend. So if we have this, then you might have image in use effect, we'll be updating some of them depending on the connection, depending on the data we get from the backend and again updating it. So the other problem is we don't know which UI we want to show here. For example, if it's connected and connecting, both can be true and is it trying can be true. So technically it can be true because there are three different variables, three different states and let's say somehow due to like spamming or any other app flow, your app is in a state where all this is true.

Which UI will be showing? For example, if you are showing a particular UI based on a particular use state, then all these three UI will be true. Like maybe check mark or green, then it will be confusing. Like user might think okay how is possible like all in a state. So basically the thing is like UI state cannot be derived from this multiple individual use state. So this is like a classic Boolean soup problem and this is not only with the Boolean, it can be like an integer or any other primitive types.

Okay, so use effect dependency chaos. So here, for example, your application is working with network connected devices and let's say you are first fetching from API and then getting connected to your Bluetooth device. Then let's say you follow the same use state pattern that we saw in the last slide. So what can happen here? As you can see in the slide, like for example, when BLE device gets connected, it can trigger a state update. Okay, UI2 connected. You come to a program like app life lifecycle. It might try to retry for the API and also can retry to reconnect to your BLE state, BLE connected devices, and also it can trigger use effect because let's say as part of reply callback you are updating states and that state is in dependency of use effect. So this can trigger this and once it's going to that dependency, then you understand like it will trigger many other things. Like in that use effect, you might have a network call or you can have an update to another use state, another set state, so it can trigger another use effect. And all this can be messy. Like even if it's hard to debug that problem or to debug that flow, if you put a console log or any tracing into that use effect, then you don't know the timing because when you do set update, it triggers a use effect, it triggers callbacks, and yes you can see some sequence but it's not always guaranteed. And there is no single controller, okay, after this, this should happen, after this, this should happen. And it's harder to read also, maintain, and also debug. So basically, if there are multiple async sources like this and no coordinator, then you become a mess.

Hidden state complexity. So we know like a use ref, so we use ref to hold the value that won't trigger the re-render. For example, let's say you want to show a toast notification only once. So maybe a hacky way you will do is like just take a use ref variable and once it's displayed on the screen, you set that to true and next time you will just check, okay, it's true, don't show it. So this may help to mitigate, I would say, like you don't want to show the toast machine multiple times for the same instance. But then this is a hacky because you are just temporarily suppressing the issue like, okay, once shown, don't show it, but it's possible that depending on how you are updating that use ref, it might show again or even show again at the wrong time, which is like a loss. The second is a closer can remember old values from earlier end. So for example, you might have noticed like you are using a use callback and there is a dependency. And if you click or you call that closure, it's possible that particular value is like old, it's not updated because you are using a use state or use ref depending on how you are using it, it may point to an old value. So it can create a functional issue also and UI issues. Our third is timer. So timer may keep running after you have left the screen. So for example, you haven't cleaned up your timers you unmounted or even let's say you disconnected and you didn't clean up that, then that particular timer will keep triggering or even after you leave that page because it's not bind to the react status, it's like a JS runtime, which triggers that set timer. So for example, let's say there's a home screen and you have a timer, you forgot to clean up that timer. So it will keep firing even if you move to a different screen like a setting screen. The listener, similar to timers like you are subscribed to a connection event of a connected device, like a Bluetooth device, if you forget to remove that listener on unmount, then it will still be called.

It might be updating your state and this may lead to a memory leak. So it's totally hidden and your app can consume more memory and things can go worse if it keeps piling up.

Last is observability. So DevTools only show react state, not the full picture. So whatever you put in a state, like a Redux state or local state, you can see in the DevTool, but it won't give the full picture how your app flow works. Because there are multiple async sources, there are multiple use effect, it's hard. Even if you put a console log, it's not easy to predict or debug a particular bug using DevTools.

Okay, so impossible UI state. So this is just showing how the UI state can be different from actual reality. So for example, your UI is saying, okay, your device is connected, and session is active, and the signal is strong, like a connection is strong, but in real, device is disconnected, because we didn't use any particular state management flow here. There is no sync between actual system reality and UI.

Second is like, say, if you are syncing, like you're connecting with a good device, or even actively fetching data, or posting data to the backend, UI says, okay, everything is fine, it's syncing, but in real, no active session, no API is happening. It might stop due to error or retry or something.

Next is like a ready state, like everything is ready, connected, synced, now it's ready to operate on that particular connected device, or that API dashboard, but actually, it's actually in progress of doing something, like it's updating a firmware, or even active API request is going on. So again, discrepancies between the UI state and actual system state.

For the other case, it's like ideal, okay, everything is fine, nothing is happening, it's ideal, but in reality, it's just spamming the retry. So, for example, you connected, everything is fine, and you are synced state, and UI says, okay, everything good, it's just waiting for you to press a connect button, but in real, it's doing a retry. So, due to like a use effect, catch, try, catch, and retry, reconnect, your app is hiddenly doing that stuff.

So, for example, the problem with this is when you click connect, it won't connect, because still trying, and there is no sync between the UI and system. So, without a single source of truth, the UI can lie without crashing. So, here, the problem is we are not notifying user something is going wrong, because let's say something is going wrong, we will crash the app so that it can recover from memory or help you to put your phone or system into a bad state. Here, we are not crashing or not notifying user. So, it's actually the bad user experience, because user is still trying, why it's not connecting, why it's not connecting, and under the hood, it's just retrying, and there is no indication or no intuitive UI that informs the user, okay, we are trying or something.

Why retries alone fail? So, retry, I mean to say like if something was wrong, you try to fix invisibly in backend or in background, I would say. So, retries from, so, first is retries from, like one disconnect triggers many reconnect. So, for example, you connect it to a device and it disconnect. So, let's say you put like a try catch into that connect and it failed, you again call connect. So, it's like recurring call to connect, disconnect, disconnect, connect. So, nobody coordinates how the things work. The issue is you connect, UI says connect, but it's failing, again connecting, failing, connecting. So, if you're using single states like a new state, and just depending on the Boolean, so, it will be flickering a bit, disconnect, connect, disconnect, connect. I think like whoever is working on a Bluetooth device might have faced this issue, like how hard it is to manage the state between the different connection phases.

Second is duplicate work. Like when you retry or tap on a button or like lifestyle, like a background program, you call connect method just to fix that issue or retry issue. So, the problem is there are three different call sites for the connect and it's hard to trace it unless you put explicit logs or logging there, but I think it's a bad pattern to call a connect method three times just to fix the same retry issue. We'll see how we can fix with the state machine. State machine stale retries. So, for example, you are disconnected and you press on connect. Let's say you press on connect maybe multiple times. Maybe the user is testing or maybe there is a bug, like a logical bug that triggers like multiple connections. So, here what happens is like a first request is in process and still another request is placed. So, there is no check. Okay, if the first request is going on, then wait or terminate that and do the fresh request again. So, the stale request is still like old because it's still pending and it will accumulate the new request. So, it creates a problem because let's say the first request got executed, the second one will get executed. So, unnecessarily there will be multiple callbacks which may put your UI into like a bad state. Blind retries. So, for example, for OTA or setting up a Bluetooth connection and you are trying at the wrong time.

So, for example, when you do a firmware update, your app needs to be connected to a Bluetooth device. But here if you don't have state management, here what will happen is the UI may show firmware update even if it's disconnected. So, again, there's a problem like a bad UX. The user will click on firmware assuming it's connected but in real it's not. So, it's a blind retry without checking what is the current state of the device.

Who decides what happens next? Without orchestration layer everything is a free agent. So, everyone is free. They can fire updates, they can call other callbacks, and there is no middleman who is managing all the states and it's really hard to manage that particular kind of system.

Here now we are going to the solution. So, how we can build a deterministic architecture. So, we can do this by defining an exact state your application can be in. So, for example, your page can be in a loading ready error state. If you are using a Bluetooth device, it can be like an init state, permission check state, scanning, bonding, connecting, and then disconnect or retry state. So, there is a clear boundary or a clear definition of each state here.

The second is define allowed transitions. So, what I mean by that is you need to define okay user can go from init to scanning only. They cannot go to direct to init to connecting because there is no way actually practically. Same way for like if you're working with the API you need to define like a first step is a login, then API fetch, then rendering the actual user profile, and then maybe if it's erroring out, retry. So, there is a clear boundary between them and there is a clear transition and the next is scope async to state.

Same way for like if you're working with the API you need to define like a first step is a login, then API fetch, then rendering the actual user profile, and then maybe if it's erroring out, retry. So, there is a clear boundary between them and there is a clear transition and the next is scope async to state. So, just define like for example start the API call when you enter loading and cancel everything else. So, here basically you are putting an init and a clean-up phase before you execute the actual state. So, for example, if you go into the connecting phase you want to make sure the scanning process is stopped or cleaned up. If you are exiting out from that connect state you want to make sure anything like any particular logging or any, for example, timers that you set in that connect temporary you want to clean that up. So, this will make sure when you transition between the state it will always clear the previous state and there is no issue of like a memory leak or ghost callback suggestor or updating UI.

And the last one is derive UI from the states. So, here what I mean by say is now we are defined the states. So, UI like React UI just look at the state. It should not check using individual ref or individual use state. It only says okay whatever is your state I just get me the UI state and I will just display it. So, it's very deterministic and we can predict okay what will be the next UI on the screen and there is no way you can be in two different states because there is only one particular UI state. Okay. So, here I want to introduce the state machine. So, it is like the three parts. One is states. So, as I mentioned in the last slide is a named situations your applicant can be in like idle scanning connecting events. So, events help you to move from one state to other like things happen in the real world like user tap connect then device found link drops all are events and it will check okay you are in this state and I got this event just move to a different state transition. So, it's more related to events. So, transition is like moving from one state to another you are defining here okay which event I should handle in this particular state. What are the cleanup what are the init that I should do when I enter the state. So, for example here you can see idle if I'm an idle and I receive a scan event I will move to a scanning if I get a select like I'm selecting a device to connect it should move to connecting so you I will check will say connecting again the new event connected it will move to connected and disconnect it will go to idle. So, here UI will just look at that rounded box like idle scanning connecting connected so there is no confusion okay which UI I should repaint.

This is like an in-depth explanation of how actual Bluetooth communication can be designed from a state machine perspective like ideals can again same as last but here the only new thing is like a retrying or recovering so ideal you are moving to scanning and then connecting and then connected so let's say you are disconnected you are connected and something happened like you go out of range and it disconnect so we don't know whether it's like a user initiated like a Bluetooth toggling disconnect or out of range so we will just recover from the state so we will just do retry and try to connect again so here we will do the same thing so here if you remember we have seen that like we have multiple cases where background foreground or you are tapping on a retry button or something there are multiple cases where you are calling connect methods so here we are solving this by putting the connect method into this particular connecting state only so it will automatically loop through these states and make sure UI will only show the correct state and there is no case where you will be saying okay connected either or something because there is no possibility so next is for example you are recovering and let's say you are you have a threshold like I just wanted to retry five times only so you can set up a guard like if you're recovering and that particular value is five just give up or like don't do retry again because it doesn't make sense if a user is out of range and you are just trying like maybe 100 times 500 times it may drain the battery and also like unnecessary calls.