DEV Community: Yash Mahalwal

Lessons from remote work on burnout, balance, and well-being

Yash Mahalwal — Sun, 24 Aug 2025 12:37:00 +0000

It usually begins with the same question. Someone asks me where I work, and I already know what’s coming next. I take a small pause and say, “I work remotely.” Their face lights up, just as I expect. “You’re so lucky!” they reply, almost every time, as if I’ve been handed the perfect life. I smile back, because it’s easier than explaining. On the surface, yes, remote work sounds like freedom — no commute, more flexibility, home comforts. But as I hold that smile, there’s always another thought in my mind: if only they knew what it really feels like.

Photo by Yasmina H on Unsplash

Introduction

Before I go further, I want to make it clear that this is only my perspective, my story. I’m a 27-year-old Indian software engineer, living alone in a city, and I’ve been working remotely for almost five years now. I’m also gay, which shapes the way I experience isolation and community in its own way. Your journey may look very different, but I think some parts of mine might feel familiar. And even if they don’t, I hope it offers you a useful point of view. In this article, I want to talk about the side of remote work that we rarely discuss — the burnout, the loneliness and the health struggles that build up over time. I also want to share how I eventually found some balance through it all. This isn’t a guide or a set of rules, only my experiences and the things that helped me.

Physical Health

Working from home meant my days had no structure. I lived alone, with no routine to guide me. Slowly my body started to pay the price. My sleep cycle was a mess. Some nights I stayed awake until morning and went to bed at 8 a.m. I ordered food often and ate out a lot. Combined with stress, weight gain came easily.

The bigger problem was my gut. Stress and lifestyle together hit me hard. I developed chronic gut issues that made every morning difficult. Gut problems like this are also fairly common in sedentary, stressful jobs. I have friends dealing with IBS, gastritis, even hemorrhoids. Almost every day, I woke up with severe burning and cramps. It often took me up to three hours just to let the pain settle before I could move forward. This also made it impossible to settle into any kind of routine. And it only made my mental health worse, since the two are so closely linked.

In fact, a UK study found that full-time remote workers took about 10 sick days a year compared to 5 for hybrid workers, and were also more likely to face obesity and depression. (The Times)

What helped me

Photo by Gabin Vallet on Unsplash

Movement became my friend. I started going out for walks and runs, and added some form of cardio to my days. The endorphins helped my body feel better and kept my mind lighter. Going to the gym also made a difference. It helped me stay in shape, and it also meant I could see people and break the cycle of isolation.

I tried to stick to a strict routine. Sleeping and waking up at the right time helped bring some order back into my days. I still struggle with this at times, especially when work runs late, but even small improvements in my sleep made a big difference.

Food was another area I worked on. I began eating at the right times, keeping my meals simple and clean. A fiber-rich breakfast, more salads, probiotic foods, and staying hydrated all helped my gut. I also started keeping a gap between dinner and sleep, which gave my body time to settle. Simple lifestyle changes ended up making major differences.

I also saw a doctor and committed to a healthier lifestyle. I quit smoking and drinking, which not only helped my physical health but also gave me more clarity mentally.

Mental Health

Photo by Tim Gouw on Unsplash

One of the first problems I faced with remote work was with my mental health. I started working young, around 20. I learned how to do the job well, but I never learned how to handle the stress that came with it. Remote work made this worse.

The line between work and home disappeared. I ate, slept, and lived in the same place where I worked. There was no change of scene and no escape. Work hours were also never fixed. It was too easy to open my laptop at night for “just one quick fix.” Days off were rare. Working from home already felt like a break, so I often pushed myself to keep going.

Daily interactions also vanished. There was no commute, no colleagues to meet, no small breaks that came naturally in an office. My routine was built around myself. Most of the time, it was just me in my apartment. I had a roommate for a while, but they were usually at work or busy with their own life. When I finished work, I often didn’t know what to do. I felt too mentally drained to pick up hobbies. Even watching a movie felt like too much. Endless reels wrecked my attention span, so nothing ever held me for long. Over time, it evolved into a slow kind of isolation. I also had a history of depression. Remote work made it spiral out of control. Anxiety came with it, and the mix became crippling. It began to affect my daily life in ways I couldn’t ignore.

I also know people who slipped into substance abuse while working from home. With alcohol or other substances always within reach, it’s easy to pour a drink during work or in a long meeting. What feels harmless in the moment can slowly turn into a routine without them even noticing.

What helped me

The first change I made was to give work its own space. I set up a separate room for it. All work stayed in that room. When I felt overwhelmed, I would step out and shut the door. That simple act helped me leave work behind. I also set strict hours. Once my day ended, I turned off notifications and closed the laptop.

I got a cat, which gave me company and comfort. (If you consider getting a pet, ensure that you are not allergic to it.) I started going for walks and working out to bring more movement into my days. I practised mindfulness and simple breathing exercises, which helped me slow down when my thoughts felt too heavy. All of this was a way to step out of my head. Staying in your head all day is a recipe for disaster.

I began replacing empty screen time with books. That made me feel more grounded and slowly improved my attention span. And one of the biggest steps I took was starting therapy. It gave me tools to handle stress and the cycle of depression and anxiety.

Social Life

Photo by Sam Moghadam on Unsplash

Remote work left me with almost no social life. After work I often felt like doing something, but at home there wasn’t much to do beyond watching Netflix. In an office, you naturally step out for dinners or drinks with teammates. That part just disappeared.

A survey found that 25% of remote workers say their social skills declined, and 20% reported worse mental health since working from home. About two-thirds (66%) say this was because of reduced social connection. (New York Post / ResumeBuilder)

I have a friend who got so used to being at home that even daily interactions like buying groceries felt overwhelming. I feel it too. In a new setting, starting interactions is hard for me, and I often end up staying quiet even when I want to connect.

Dating can sometimes help fill that gap, but for me it hasn’t been easy. In India, especially in cities, people are open about their sexuality and willing to date. The challenge is that the pool is still small, and finding a good match isn’t simple.

What helped me

The biggest change came from finding community. Making connections outside of work gave me something to look forward to. I tried hobby classes in my free time, which helped me meet people and break the routine. For me, queer events like sports, karaoke, crafts, and parties created a space where I felt at home.

It also helped to find others with remote jobs. I have friends in the same city who work remotely, and on boring days we meet and work together from a café. That small change brings energy back into the day.

Photo by Ron Lach on Pexels

Travel has also been a huge benefit. I often travel with a childhood friend who works remotely too. Together we have seen the Himalayas, the deserts of Ladakh, the beaches of Goa and the forests of the Kerala. I also try to take solo trips and explore new cultures. Many countries now offer digital nomad visas, so take the chance and travel to new places.

It is also worth exploring where you want to live. I moved to a calm, green neighborhood with plenty of cafés and everything within reach. When I feel tired, I just step out for a walk and it makes me feel better. That would not have been possible if I had to live close to an office.

Remote work can take away your social life if you let it, but it also gives you freedom to build a better one if you choose it.

Workplace

Photo by Chris Montgomery on Unsplash

My workplace shrunk to a desk and a chair in my apartment. The people I worked with were only faces behind screens, and many times not even that because cameras stayed off.

Collaboration felt harder without a physical space. You miss the whiteboards, the quick discussions, and the sense of working side by side. Managing teams across time zones added to the challenge. It meant long hours, late-night meetings, and waiting for answers that would have been instant in an office.

For some of my colleagues, working from home also meant living with family. Staying at home all day while trying to balance work and children around them was overwhelming in its own way.

What helped me

We had to find a rhythm of collaboration that worked. It took some time, but it is possible to work asynchronously and still get things done. We relied more on text. The classic “this could have been an email” really should have been an email. Meetings became a place where people came together to deliver value. Time is valuable, and treating it that way helped everyone. Remote work can also empower you to be more productive and focused. With the right boundaries and setup, it gives you the freedom to design your day in a way that brings out your best work.

A Stanford study found that employees working from home were on average 13% more productive than their office counterparts, thanks to fewer breaks and less time spent commuting. (Stanford University)

I also made an effort to connect with colleagues beyond just work. Taking interest in each other’s lives, sharing vacation photos, stories about family, and having fun in virtual events made the screen feel a little less distant.

Meeting colleagues in real life whenever possible also made a big difference. If they were in another city or country, I tried to pair it with a trip. Those moments built trust and made working together easier.

Lastly, I worked on making my own space better. A decent ergonomic chair, a monitor, keyboard, and mouse all helped. A good camera and mic are worth it too. Your entire presence is virtual, so it pays to make it effective. Exploring coworking spaces is also a good option. It gives you place to focus and also brings back a sense of the office when you need it.

Conclusion

Remote work is not just comfort and flexibility, and it is not just isolation and stress either. It can hurt your health, your balance, and your social life if you let it. But it can also give you the freedom to rebuild these things in ways that work for you.

For me, the past five years have been both difficult and rewarding. I have made mistakes, I have struggled, and I have also found small ways to create balance. Some things are still a work in progress, and that’s okay.

If you are working remotely, I’d love to hear about your own challenges and what has helped you deal with them. Everyone’s story is different, and sharing those stories might just make the rest of us feel a little less alone.

Optimising React Apps

Yash Mahalwal — Sun, 21 Apr 2024 19:10:41 +0000

In this article, we try to understand the approach to optimising React applications. We'll work with a real example to explore some of the most common issues that developers face. Then, we'll go through the process of improving our application to tackle those issues effectively. We'll also learn how to make informed decisions and strike the right balance between different possible options.

Note: This is a lengthy article. However, you may already be familiar with some of the topics we discuss. Therefore, I encourage you to selectively read the parts that are relevant to you.

Table of contents
Introduction
Performance challenges with React
- Scheduling an update
- Render phase
- Commit phase
- Where is the issue?
- How do we optimise?
Understanding with a real example
- Monitoring the application
No optimisation
- Profiling
  - T = 0 - 18s
  - T = 18s - 33s
  - T = 33s - 60s
- Adding optimisation
  - Trade-off
Add memoization
- Profiling
- Adding optimisation
  - Trade-off
Reduce renders
- Profiling
- Adding optimisation
  - Trade-off
Reduce computation
- Profiling
- Adding optimisation
  - Trade-off
Optimise Updates
- Understanding how the store is structured
- Profiling
- Adding optimisation
  - Trade-off
Optimise Memory
- Profiling
- What went wrong?
Summing up
- Credits

Introduction

React has become increasingly popular in recent years for building user applications due to its introduction of declarative programming. Previously, developers had to write code to update different parts of the UI whenever there was a change. This process was difficult to manage at scale and often resulted in bugs as the application evolved. React changed that by defining the UI as a function of state. Now, developers only need to focus on updating the state correctly, and React takes care of updating the UI.

React is a good tool for building correct UIs quickly. However, the next problem down the line is performance.

Performance challenges with React

React is not without its limitations. Over the years, it has become increasingly clear that it is difficult to create performant React applications. Let us go over how React updates UI to understand where the problem lies.

Scheduling an update

React maintains a tree of your components. These components can have some state. Developers can request an update to the state using setState. This instructs React to schedule an update for the component's state. React performs render and commit to process the update for the subtree under this component.

Render phase

The component is re-evaluated using the new updated state. For function components, this means invoking the function again. React recursively re-evaluates all the children of the component being updated. In the end, React has the output of all components in the tree. React requires this to be done using pure functions which means if rendering is done multiple times with the same state, output should be the same. The output should only depend on the input and no other external factor. Components can describe any side effects that need to run separately using useEffect.

Commit phase

The output of the render phase is an updated representation of DOM under the component subtree (often called Virtual DOM). React now has the outdated DOM for the subtree along with the updated DOM. It has a O(n) algorithm to patch the outdated DOM and update it.

Where is the issue?

The commit phase is very straightforward. Under the imperative paradigm, developers would manually update the DOM which resulted in inefficient updates. React replaced that by carefully only updating what is needed in one go.

The render phase is usually more computationally expensive since the entire subtree is calculated again. That in itself is not a big problem for a single update. However, when you have multiple updates occurring rapidly, it becomes a real problem. The React team has acknowledged that and has started working towards mitigating it.

Imagine you have a parent component with 3 state variables - s1, s2 and s3. It also has 3 children which rely on one of these variables.

Even if only s1 is changed, the parent and all the children are re-rendered instead of just parent and Child 1. This is fine since the rendering process is pure and re-rendering other children will return the same result. However, when a lot of updates are made to s1, s2 and s3 rapidly, the performance overhead becomes evident. This is often the case with highly interactive apps (like chat, video conferencing etc).

React has introduced measures like batching state updates, background concurrent rendering and memoization to tackle this. My opinion is that the best way to solve the problem is by improving their reactivity model. The app needs to be able to track the code that should be re-run on updating a given state variable and specifically update the UI corresponding to this update. Tools like solid.js and svelte work in this manner. It also eliminates the need for a virtual DOM and diffing.

How do we optimise?

Software optimisation is usually not a simple process. Each change has trade-offs associated with it. Some trade-offs might be acceptable for your use case while others might not be acceptable. This makes optimisation a very specific process. In general, it is repeated iterations of the following steps:

Observe the application under stress.
Find which parts of the app run into performance issues.
Debug the root cause of these performance issues.
Come up with approaches to mitigate those.
Compare trade-offs between these approaches and select one most suitable to your use case.

Understanding with a real example

Let us consider a stock monitoring application. This mock app monitors rapidly updating stock prices in real-time. It is deployed here. For the best experience, you should clone and run the app from the source from here.

This app has the following sections:

Header with navigation to different versions of stock monitoring
Buttons to observe/unobserve the stocks and reset the stock data
A plot of the running average of the last 50 entries
A list of stock price events - contains the name of the stock and the current price
A profiler widget which:

Shows how many renders take place every second and the average render & commit durations of those updates.
Can plot line chart for the number of renders, average render duration and total time spent calculating per second throughout profiling.

    Total time = (Render + Commit) * Render Count

To keep things consistent, I will profile each version of the app for 1 minute. Stock events are fired at every 200ms. We will observe how the app behaves and iterate over the code to make it perform better.

Monitoring the application

The app already has a profiler widget built on the Profiler API. The development build of the app is deployed so that monitoring can be done with ease.

In addition, you can use React developer tools to see component trees and profile them. This will provide a breakup of why each re-render took place and how much time each component took to re-render.

Chrome also has a built-in performance monitor which helps you see the overall behaviour of the application outside React's context

No optimisation

Let us observe the app without any optimisation. To see the performance fluctuations better, you can add an artificial CPU slowdown. I will be working with a 6x slowdown.

Go ahead and click on observe. Remember to start profiling before you start observing. When you want to stop, click on Unobserve.

Profiling

Let us look at the plots generated by the profiling widget and understand the trends:

T = 0 - 18s

Number of renders starts with 10-11 renders per second. It stays at that for a while.
Render duration increases linearly from 0 to 50ms
Total time spent increases linearly from 0 to 500ms.

These trends show that with time, the load on the JS thread increases. Render duration increases which also increases the total time spent. Also, 500ms = 10 x 50ms which means that the JS thread can process all the renders so far.

T = 18s - 33s

The number of renders fall rapidly from 10 to 5
Render duration keeps on increasing almost linearly to 110ms
Total time spent oscillates between 500ms to 650ms.

If you look closely, these trends are due to the rendering duration increasing over time. This blocks the JS thread for more time and leaves less available time for other renders per second. Total time spent shows the correlation between decreasing render count and increasing render duration. When JS thread throttles and reduces the number of renders processed, the total time spent is lesser. However, since the average render duration also increases, the total time spent rendering increases again.

T = 33s - 60s

Number of renders continues to fall. It falls from 5 to an average of 3-4 renders towards the end. The decrease is not as sharp as before
Render duration still keeps on increasing. However, now the growth has slowed down. This is why the render count did not fall as sharply as before.
Total time keeps on oscillating. The average is still 500-600ms with large fluctuations on either side.

This is simply because the JS thread is close to reaching the throughput limit and hence, the number of renders processed is reduced. Growth in calculations becomes slow. The app becomes laggy and less responsive at this point.

Here is a screenshot of the performance analysis using Chrome Inspector.

If you look at the top, there are a lot of lagging frames. These updates are displayed but they lag behind the main thread. Those are coloured yellow and labelled as partially presented frames. JS thread is busy for 92% of the observation time.

Now let us take a look at the React profiler under Chrome Inspector.

This further tells us two things:

The Table component is the most expensive to render
During the renders, hooks 1 and 2 of the Unoptimised component change alternatively.

Adding optimisation

We are familiar with how the app behaves. The table component is the bottleneck. We can start by reducing the time spent rendering it. Let us look at the unoptimised version of the app (src/routes/unoptimised/unoptimised.tsx).

These are the hooks that React Profiler reported:

stockEventList is used by the table.
averagePrices is used by the line chart plot.

These are updated alternatively due to useEffect on line 35. Since they are used to maintain separate parts of the UI, we can add memoization on the children to ensure they only re-render the component they are consumed by. So updating averagePrices should not re-render the table and updating stockEventList should not re-render the line chart.

Trade-off

This change will reduce the render durations. Memoization will increase the memory usage. React docs say that it won't be harmful.

It will also introduce refactoring. As a developer, you try to make minimal changes to the codebase. This ensures that existing logic does not break. However, with React, you'd often be required to prune and refactor big components into smaller ones. This is because your functions map directly to a part of the UI. Solid.js takes an interesting approach to components as simply a means to modularity and reusability. Breaking into components does not impact how much code runs on updates.

Add memoization

The final code can be seen under (src/routes/add-memo/add-memo.tsx). Here is a list of changes made:

The table and line chart components are wrapped in useMemo to ensure that they are not re-rendered when non-relevant changes cause re-rendering of the application.
Moved inline constants outside the function component. This ensures that we are not creating new but equivalent objects on re-render as these might cause re-render of the children.

React is planning on moving to a new compiler which can do some of this for you. But right now, this responsibility falls on the developer.

Profiling

Let us look at the profiling plots again:

There are some interesting trends this time:

The average render duration is reduced. It has become half from a maximum of 180ms to 90ms. This is because the table is not re-rendered on every alternate render.
This is reflected in the JS thread being able to process renders without any issues up to 39s which is a huge improvement over the previous 18s.
Render count is sustained at 10 up to 39s and then starts to fall.
Total time spent increases up to 39s and then fluctuates around the previous range.

Based on these and the insights from the unoptimised version, we understand that the JS thread starts struggling when the total time spent reaches 500-600ms. In the long run, this version of the app will also run into the same issues as before. It will take longer but the app will ultimately become less responsive.

Now let us look at the React Profiler.

The change in trend is because every alternate render is smaller. However, the render duration for the table keeps on increasing.

Adding optimisation

If stock events are being sent every 200ms, there should be 5 renders every second. However, we see that the renders (when the app is capable of handling the load) are twice that number. Let us focus on reducing the number of renders further here. If you look at the code (src/routes/add-memo/add-memo.tsx), you'll see that there is a useEffect on line 51.

This useEffect runs when the list of stock events is changed. It calculates the average of the last 50 entries and also scrolls the table to the bottom. However, useEffect is meant for synchronising with external systems. This is important due to the timing of triggering useEffect. It runs after rendering, in a deferred event. If it runs React-related code, there might be a better place to put that code. This is one of the many magical rules that developers must remember and is not strictly enforced by React's design.

In previous examples, stockEventList is updated causing a re-render. This triggers the useEffect which updates averagePrices and causes another re-render. We can put the code under useEffect to the observer for stock events. Since multiple state updates are being made together, they will be batched into a single update.

Trade-off

This change will again introduce refactoring. Many problems with React code happen because components aren't updated regularly. They can grow too big and confusing, making them hard to manage. Components can be dynamic with useState and useEffect hooks and it can become easy to lose track of which code inside the component runs when. Some code can run again and again even when not needed due to multiple updates to the component's state. If that code is run due to an unrelated state update, it causes a functionality bug. It defeats React's purpose of creating correct applications. Developers need to trace the code and describe dependencies for changes. React provides helpful rules which can be enforced by IDEs and linting.

Therefore, you should always try to refactor React code while updating it to ensure that only the correct code runs for a minimal number of times. Currently, this responsibility lies with the developer and introduces extra complexity while writing code.

Reduce renders

To batch the state updates together, we move the code from useEffect into the observer logic. The result can be found here (src/routes/reduce-renders/reduce-renders.tsx)

Another change you might notice is useStableCallback hook. It is a hook that creates a function that does not change in reference but always runs the latest code when invoked. It is inspired by class components. React is planning on bringing something similar with useEffectEvent.

Profiling

Both state variables are now updated together in a single render. This is because React has now batched these updates together.

Let us look at the profiling trends again:

The app behaves similarly to the previous version. Here are the trends:

The number of renders is lower (5 when the app can process all the updates) which means there are no extra renders.
The average render duration is back to a maximum of 180ms.
This is because the number of renders is halved but each render is almost twice as expensive. In the previous version, every alternate render was very small. However this time, every update causes the table to re-render. Therefore calculations on every render are the same as the unoptimised version.
Total time spent reaches the 500ms-600ms range at around the same time mark as before (39s).

Adding optimisation

We have reduced the number of renders. The app is better than before but it still becomes slower and unresponsive. The root cause is the increasing duration of renders. If you look at the React profiler, you'd realise this is because of the table component

The table renders all the rows. On every update, all the rows are re-rendered. As the number of entries increases, the amount of time spent re-rendering all the rows will also increase. The average price plot does not show this trend since we only show running the average of the last 50 entries. It internally uses Canvas which is very performant under rapid updates.

If we limit the number of rows rendered to only show the visible items, we can limit the cost of re-rendering the table. Even if there are a large number of rows in the table, only the ones on the screen will be rendered. That can be done by virtualization. I will use react-virtuoso for the app.

Trade-off

This change will make sure that the app doesn't slow down and become unresponsive. However, with virtualization, we sacrifice the smoothness of the scroll. Scrolling rapidly will result in blank flashes inside the table component. This will also happen when the list scrolls to the bottom on new stock events. We also don't render the rows out of view which can hide them from the browser search functionality.

Reduce computation

The next version of the app can be found under src/routes/reduce-computation/components/reduce-computation.tsx.

Here are the changes made:

The code for the chart and the table is broken into smaller components. They can be separately memoized using memo.
Also logic for averages has now moved into the Chart component. This prevents the table from being re-rendered if there are updates from the Chart component.
We have also eliminated averagePrices state and simplified calculations for calculating averages. Earlier we looped over the last 50 entries of the list. Now we create new entries from previous averages.
Inside the table component, we have replaced NextTable with TableVirtuoso

Profiling

Here are the trends:

The average render duration is much lower. It is between 0.8ms-1.5ms on average. It does not increase. There are fluctuations which look significant. However, these are just small variations which are magnified due to the small scale of render durations.
Total time spent is also limited to 18ms-33ms. It does not increase with time.
The number of renders is constant but much higher with a value of 18-20.

To understand why the number of renders is higher, we can check the React profiler.

Hook 2 causes extra re-renders for the Virtuoso Table component. This hook is responsible for tracking which rows are in the view. The component works by showing the visible rows on the screen and adding space above and below them to account for the sizing of the list. We scroll to end on every update which causes re-renders inside the Virtuoso Table component.

Here is what the performance analysis looks like:

JS thread is occupied for 13.8% of the observation time which is much lower than the previous 92%. There are no dropped frames and the app stays responsive in the longer run.

Adding optimisation

The app still feels unusable. The updates are too rapid for any meaningful interaction. It would be better if we could process multiple stock events together are larger intervals. It would also reduce the load on the JS thread. Also scrolling to the bottom seems to be adding more problems than value to the app. It is very hard to focus on a list that keeps scrolling. It causes extra re-renders in the virtual table and also causes blank flashes while the list scrolls. It can be eliminated if the table shows the list in reverse order, with new entries added to the top. This is something you should discuss with your UX team.

Trade-off

Slowing down the rate of updating UI by handling multiple updates together will provide a better UX and performance. However, adding multiple events together will also introduce larger visual shifts. It also makes state management complex. There is another overhead of reversing the list while rendering the table. But with slower updates, this should not be significant.

Optimise Updates

At this point, it is a good step to introduce a state management library. React provides context and reducers for complex state management. Using them, you can expose your state everywhere in the application and update it as needed. But they have certain limitations:

Context can expose multiple values combined in an object. Even if one of those values changes, the context will cause a re-render everywhere it is being consumed.
You have no control over how the updates are triggered. If there is a re-render in the context provider which changes the context value, then all consumers will re-render.
The developer needs to do most of the heavy lifting around state management logic

Introducing a state management library can help make this process smoother. Here's how:

You can precisely specify the data from the entire state store in your consumer component. The consumer will only re-render when that specific value is changed. So you have fine-grained control over the scope of re-renders on updates.
You can use transient updates. In this case, you can subscribe to a value from the store in a component but you can choose when updates should cause a re-render. This is very useful in applications where there are a lot of rapid updates to the state. It is possible because external stores usually operate outside React's scope and you can control how the integration works with your components.
State management libraries provide a systematic way of maintaining your state-related logic. This is useful when you're working in a large team.
Most of the libraries come with dedicated developer tools. They also come with a plethora of community-maintained plugins which can make complex state manipulation very easy

For our case, points 1 and 2 can help us provide a better way of handling updates in our rapidly updating application. I have used zustand for the application.

Understanding how the store is structured

The code for the store can be found at src/routes/optimise-updates/store/stock-store.ts. Here is how it works:

The store maintains a list of Stock Event IDs. This list can be read in the table component.
A record of Stock events indexed by their ID. Individual table rows can read entries from this record. This is also useful where entries can also be updated. In this case, only the relevant row component will re-render. In the previous version, the table component accepted a list of event objects as prop. Changing a single entry would've caused a re-render of the table component.

We also have a custom hook which leverages transient updates. We throttle the updates instead of immediately re-rendering the component on state change. The code can be found under src/routes/optimise-updates/hooks/use-throttled-store.ts.

Using this hook will make sure that updates are throttled to the specified interval. The default value is 600ms which means 3 stock events related updates will trigger 1 re-render.

Now we can use this in the chart and table component.

Note that list of IDs is reversed before rendering. This eliminates scrolling to bottom on every event. If needed, reversed list can also be maintained in the store.

We read the stock event data in StockTableRow component. That doesn't need throttling. This is because it gets the ID from the table component which already gets throttled updates.

The final code can be found at src/routes/optimise-updates/components/optimise-updates.tsx.

Profiling

Initially, there was a spike in render count and total time spent. That is due to the virtual table calculating layout as entries cause overflow. However, that is not seen once the scroll has been shown in the table. To avoid the spike, can rely on the fact that all the rows are of the same height. We can ask virtuoso to skip this calculation by providing the size in props.

After the initial spike:

Render count stays between 1-3
Render duration stays between 0.1-0.7ms
Total time spent stays between 0.5-2ms.

This is a huge optimisation over the previous version where the total time spent maxed to 33ms. Performance monitor further shows that UI is less rapidly updated now. JS thread only spends 5.38% time on rendering effort.

Adding optimisation

Now the application seems to be stable. However, if you think about the store, it will grow indefinitely in the long run. That will cause memory usage to grow. We can remove old entries from the store to free up memory. In a real-world use case, you'd refetch those entries when needed again. This will make sure that memory does not increase unbounded.

Trade-off

This will add extra complexity to state updates. Processing updates where older entries are deleted might take longer

Optimise Memory

The updated store can be found here: src/routes/optimise-memory/store/stock-store.ts. After the size of the ID list reaches 200, we remove the first 100 entries from the store. So only a maximum of 200 entries is maintained.

Profiling

Updated code can be found under src/routes/optimise-memory/components/optimise-memory.tsx. Here is the performance analysis before the memory optimisation:

Here is the performance profile after optimisation:

The memory usage doesn't go down by much. Earlier it was in the range of 11.0-19.4 MB. Now it is in the range of 11.2-19.3 MB. This is probably because the event objects are too small and don't take much memory. It is also concerning to see a range of dropped frames in between. These are due to the store being cleared which blocks the JS thread.

What went wrong?

This is an example of over-optimisation. We could save some memory usage but the cost of computation was higher. The version without memory usage optimisation is good enough since there isn't a practical use case where someone would monitor the stocks for so long that their memory is filled up.

But if we want to ensure that their memory does not increase unbounded, we can experiment with the point at which the store is cleared and the number of entries removed at once. Tweaking these parameters should get us into a zone of acceptable performance.

Summing up

Optimisation is a tricky process. You need to observe your application, correctly debug the bottlenecks and mitigate those with good design. There are added complications due to React's declarative model since you cannot completely control which code runs when. Depending on your use case, there might be other optimisations possible. Some of the common ones are:

Bundle Splitting and Lazy Loading: Splitting your built application into smaller chunks that can be lazily loaded. These chunks are only sent to the client application if they are needed. It helps reduce the amount of code loaded on the client for your application to work.
Server Side Rendering: This is a hybrid of the older server rendered applications and newer single-page applications. You can selectively render your components on the server and serve them to the client readily. That helps increase security, abstract away logic from the client and provides better load times & search engine visibility.
Web Workers and Web Assembly: For applications that are computation-heavy, you can offload the work to a separate thread. These are called web workers. You can also run compiled C++ (or other supported languages) code via Web assembly which gives you the benefit of high performance in the browser.

Did I miss something? Can I make this article better? Is there something that you liked reading? Let me know in the comments!

Credits

Cover photo by RealToughCandy[dot]com: https://www.pexels.com/photo/hand-holding-react-sticker-11035471/

DEV Community: Yash Mahalwal

Lessons from remote work on burnout, balance, and well-being

Introduction

Physical Health

What helped me

Mental Health

What helped me

Social Life

What helped me

Workplace

What helped me

Conclusion

Optimising React Apps

Table of contents

Introduction

Performance challenges with React

Scheduling an update

Render phase

Commit phase

Where is the issue?

How do we optimise?

Understanding with a real example

Monitoring the application

No optimisation

Profiling

T = 0 - 18s

T = 18s - 33s

T = 33s - 60s

Adding optimisation

Trade-off

Add memoization

Profiling

Adding optimisation

Trade-off

Reduce renders

Profiling

Adding optimisation

Trade-off

Reduce computation

Profiling

Adding optimisation

Trade-off

Optimise Updates

Understanding how the store is structured

Profiling

Adding optimisation

Trade-off

Optimise Memory

Profiling

What went wrong?

Summing up

Credits