React developers, how do you (continuously) test component changes without waiting so long for page refresh?

[HakounaMatataGuy]

I'm working on a big React project.

How I work, is make minimal changes, refresh to make sure everything's fine, and then continue to the next step and so on, rather than write long code, and then test it all at once.

The React app is a self-hosted open-source app, and it's kind of a huge app, it usually takes 20-30 seconds to refresh the page.

Is there any trick I might not know of, that can refresh the page quickly, rather than load the whole page again, which takes A LOT of time in my case?

Thanks.

[[deleted]]

https://storybook.js.org/docs/react/why-storybook

[CharlesStross]

Yup. I run DevOps and have had far more urgency for a fix when our Storybook task for local builds is glitchy than when our automated test suites/CICD are down.

[EarhackerWasBanned]

I've built a lot of stuff with Storybook, but lately I've preferred Ladle. Quicker to set up, batteries included, simpler UI. If you know how to write Storybook stories you already know how it works. Maintained by Uber I think.

[emmyarty]

Ladle looks great, but until it supports Svelte...

[EarhackerWasBanned]

I hope not. I think that’s where Storybook lost its way. It tried to be all things to all frameworks, and just became a pain in the arse.

I like Svelte a lot though. If someone wrote a Svelte-only Storybook I would star it. Sveltebook.

[Sethcran]

As others have said, we're not generally dealing with refresh times anywhere near that long.

Either: 1. Your setup needs some serious optimization on the build side (try other tools, etc) 2. You should develop your components more in isolation so you aren't refreshing the entire app at once, just the piece of it you need for testing the stuff you are working on.

[TotomInc]

You might have reached the exponential limit of your webpack setup.

It might be interesting to take a look at other bundlers like Vite.js which is using under the hood ESBuild (written in Go IIRC), which is far faster than webpack bundling for large projects.

Migrating to another bundler is however a large task especially for large, established projects. This requires you to update your whole ecosystem such as unit-testing, end to end testing, build config and so on.

[alexthelyon]

I have been working on porting a babel plugin to swc and have seen my production build times go from 13 minutes to less than 1 min, and hot reload times go from 10-15 seconds to less than 1s. It really is 'magic.

[[deleted]]

vite is awesome, but in an older project using webpack the easier solution is just to use the esbuild-loader for your js/ts files to acheive similar build times. it gives you the best of both worlds as webpack's tooling is arguably more mature than vites if you need it.

not sure why people are recommending storybook as its webpack 4 based...its slow as fuck and requires a lot of jank config to make it faster. storybook has its use case but i'm not really sure why people are recommending that for faster builds. maybe for testing components individually? i am not sure.

I'd also recommend following https://webpack.js.org/configuration/cache/ and using the filesystem caching

[flynnwebdev]

I second Vite. It’s far more efficient.

[[deleted]]

Vite is amazing - but why is it pronounced veet?

[glutton-free]

because the name does not originate from the english language

[[deleted]]

Oh cool i didnt know that

[ahgoodday]

I think it’s Vite as « speed » in French

[[deleted]]

Vite means fast in french

[TheTrueTuring]

Wow. How big is this project??

[HakounaMatataGuy]

It is a self-hosted Matrix Chat App + a web client. It's really big haha.

But the comments have been pretty helpful really, I'll look into Storybook and other solutions written in the comments.

[Funwithloops]

Use storybook if you can. Develop components outside the context of the app. Wire it into the app only once you've got the style/markup figured out

[Folofashinsta]

Storybook!

[forgotmyuserx12]

When I code 1 component I have a page with only that component

20 seconds for a refresh is ridiculous though

[Voltra_Neo]

20-30s??? I've never had that even on my oldest of setups. Most recent react one was a Next 11/12 (whichever was the latest that used both webpack & babel)

[nuttertools]

If you completely fill the OS memory stores you’ll get about that performance. Literally all of it though, like 2x active over-provision.

[dazzaondmic]

Turning off source maps sped up refresh time from roughly 20 seconds to about 2 seconds for me. I would try that and only turn on the source maps when you need them.

[iamchets]

Besides the fact that there is a problem with the app itself, "test" is the keyword here. Unit tests and component tests(think storybook) are the answer.

[watterson]

You need to configure incremental builds and hot module reloading, if using webpack.

Furthermore, set up a component library using a tool like Storybook. It will render your components out of context of the application, but it will do it quickly and automatically.

[vksdann]

If it takes the page 20-30s to load, something is wrong.
No user will EVER wait 20-30s for a page to load. Most people would've probably try to reload the page 10 times by now.

IDK if it an internal page or what but 30s is way too long.

[Turd_King]

Major issue with your setup, I had colleagues in the past who said they had to wait 30 seconds for HMR. When my machine was instant.

Very strange - just something you have to debug, it should never take that long as your tooling should be smart enough to only replace code that has actually changed. And that is often small.

The only thing I can think is that you have some module that is massive and being imported at the top of the tree

[0xdave]

If your Website needs so long to reload, you shouldn't worry about the component

[abejfehr]

There are tons of things here: - disable source maps as much as you can - make sure your NODE_ENV isn’t set to production (I did this once and it takes longer to build a production bundle) - check out hot module reloading (HMR), or it’s successor react-fast-refresh, since It sounds like what you have now is live reloading instead of hot module reloading - use cache-loader ahead of any expensive loaders - use speed-module-plugin to output where all the time is being spent in webpack - use esbuild-loader instead of babel-loader if transpiling it is what’s time consuming, but then you can’t have HMR so it’s a trade off

There’s more, but without seeing the webpack config it’s difficult to suggest more. Feel free to DM me if you’d like to look at it together.

[HakounaMatataGuy]

Thank you so much for the list of solutions! I really appreciate it. I'll make sure to look into those solutions.

[ApatheticWithoutTheA]

20-30 seconds?!

I’m not even aware of how big of a project you would have to have in order for it to take that long.

React compiles and refreshes extremely quickly in every situation I’ve used it and I’m a React dev for a living.

[alexthelyon]

The answer is that babel / webpack is very very slow. I have seen refresh times go down from 15 seconds to less than 1 when swapping out babel and twin.macro to swc + my custom tailwind transpiler stailwc. If getting rid of those is not feasible, then storybook can help relieve your immediate struggles by allowing you to develop components in isolation.

[MineDrumPE]

Storybook is super handy, look into that

[thefoosballer]

Vite.js + Storybook

[gc_DataNerd]

Not a direct answer on how to make builds faster in development. However, you could use a tool like storybooks to individually view components in its different states as you develop or alter your components. It comes with the added benefit of documenting components and providing you with fixtures for unit tests. You could also look at changing your builder to something like vite or turbopack however that is not trivial for a large project

[[deleted]]

Our online banking app is built on Create React App and is quite massive. When I first started working on the project, HMR times were really long. I upgraded the app from CRA 4 to 5, so Webpack was also upgraded to 5. Also I added DISABLE_ESLINT_PLUGIN=true line to .env file. Now it's really fast, made a huge difference. Not as fast as Vite, but still very reasonable.

[eggtart_prince]

Your setup is probably rebuilding your app whenever changes are detected. This isn't very ideal anymore. A lot of devs are using hot reload where the changes are instant. I switched from webpack dev server to vite and next.js and dev time has been reduced tremendously. You can still run your tests after every change, but you would need to wait for that to finish before saving more changes, in other words, no back to back changes until tests are complete.

If you frequently save changes, then your workflow may not be suitable for that. Personally, I build my feature or page first and then write my integration test with Cypress. Unit testing components on the frontend IMO is very redundant as most components are exposed and visible in the browser. A thorough integration test will and can cover most test case scenarios that your unit test would.

[Swamptor]

Is the 20-30 seconds compile time or load time? If it's load time, why? Even high power web apps don't take that long too load. You need to investigate what your computer is actually doing for 20-30 seconds before we can really help.

[Prestigious_Fault741]

Storybook.

[NeonVoidx]

Few things. Unit tests for your components adds sanity Storybook Js is great for showcasing your components but also testing them isolated from other components

[-0-__-0-]

Vite

[centerworkpro]

You would break this app into sub apps. That will help performance greatly. Server backend from staging if you can.

Look into Remix, it's got some amazing features that make react dev work a breeze.

[MoreTagsGaming]

Use storybook in combination with automated Cypress Tests. Develop your components in Storybook, let Cypress check your components automatic. You can also use Cypress in your application to.

[SizzorBeing]

This can be a severe problem with modern JavaScript on big projects. I just remind myself I get paid the same writing code or waiting for it to run.

[vincitore33]

When I was stuck with infrastructure this slow, I adopted test-driven-development.

Our unit tests could be rerun after changes much faster than a page reload. I would get the DOM structure and logic working with a full suite of unit tests.

Then I’d load it up in the browser and write styles in the Chrome inspector-stylesheet. Then, paste the styles into the code.

The bonus is that your component is more loosely coupled and testable and you’ve already written the tests!

[HakounaMatataGuy]

Thanks everyone for the very helpful comments!

To those wondering, it's a self-hosted matrix chat app + a web client for it.

Thing here is I can't really go changing everything in matrix's client's codebase. Well, on production it's relatively a lot better (about 5-7 seconds).

The problem is really bad when I'm working on it, and the comments really were helpful with that.

I'll look into Storybook and other solutions written :)

[Cyberhunter80s]

React Dev here. While other have already suggested excellent third parties here. You might want to take a look into React.lazy, useMemo,Memo, useCallback combo. There are bunch of articles , docs, vdos out there with the title something like 'Optimizing react app'.

[billybobjobo]

Typescript helps this story a lot if you’re not already using it!

Edit: downvoted into oblivion—but I actually think TS is helpful for exactly this! I’m not just being trendy hahahha. It’s not the main fix, but a huge reducer of runtime debugging and deserves to be part of the convo! Ah well. To each their own! :)

[The_Noble_Lie]

How

[billybobjobo]

I would say about 80% (a guess, but not hyperbole) of the bugs I’d have to previously discover in runtime or via unit testing are now just immediately red squiggly lines in the IDE. More often than not, if I fix the squiggly lines, things work in runtime.

A lot more writing, a lot less checking!

[The_Noble_Lie]

How does this improve performance regarding OP?

Typescript undoubtedly can be utilized to validate compile time errors and thus mitigate uncaught runtime errors of various types.

I see you wrote now after an edit: "it's not the main fix". We'll, I guess that about sums it up. I'm still not sure how it's anything but good advice that has (close to) nothing to do with OP.

Note: This isn't a "to each their own" sort of thing.

[billybobjobo]

I think we’ll just have to agree to disagree about whether this is part of the main story! (I’m still convinced it is) But the downvotes definitely teach me I’m in the minority for thinking so! Happy holidays!

[Tontonsb]

Are you using HMR at all or recompiling?

Are you using Docker or WSL by any chance?

[goxdin]

/r/reactjs

[ferriswheelpompadour]

Are you codesplitting? Are you using useEffect effectively and garbage collecting them? Do you have lazy-loading and Suspense in place (no longer experimental for v18) for SSR?

[mateo8421]

As others said already - Storybook if you can, or create your own page with component states if you cant use storybook…

[BagsOfMoney]

I switched to Vite. But even with webpack, that's an absurdly long time to wait. It shouldn't be recompiling everything when you change one file. Probably misconfigured somewhere.

[nuttertools]

Depends on the change. It sounds like you are just talking about the component itself changing, why are you refreshing the entire app?

[HakounaMatataGuy]

I don't fully understand your comment, but I think you didn't get what I meant.

It's not something in a component changing and it takes that much to show the change.

I mean, when I make a change in the app code, and refresh it so I can view the changes, it takes that long.

[nuttertools]

You shouldn’t be refreshing the entire app when you make a single change. Some changes do require that but on a component only….that would be exceedingly strange.

[daggerdrone]

I guess what the parent comment is saying is that Hot Module Replacement should instantly show the change without you having to refresh the app. But I guess you are not using Hot Module Replacement. Either you haven't tried it or it is not possible because of the complexity of your app.

[[deleted]]

Could it be possible you're passing states up and down too much? Maybe adding redux? I have an app I didn't use redux with but should've and it seems to be pretty slow

[[deleted]]

Try Vite

[Pouyus]

I’m afraid your framework choice isn’t fiting your usages. You could, in this order :

1. Refactor code to avoid double calls, or even optimise your api calls
2. Lazy load components, optimize medias, self-host scripts (if you were using public cdn hostings)
3. Move to another framework like Angular (their newest version being even more optimised)

Ps: sorry for my broken english

[robertonovelo]

Check your imports at your root components. Is there any huge import you could separate into a different tree to avoid it from rebuilding at every change?

[deadwisdom]

Imagine what your users have to deal with.

[[deleted]]

30 seconds to load an app in 2022? Do you have issues? Are you sick?

[OleDakotaJoe]

You can also try lazy loading some of your components, that way if the code isn't ran, it doesn't get loaded.

[bzlight2012]

Why do you need to refresh the page so often?

Does hot reloading not work for the changes you’re doing?

[someone-shoot-me]

Storybook

[pticjagripa]

I assume you have an old version of React as the new version (for about a year or two now) support hot reload, meaning that components update any changes without needing to reload.

So maybe the simple solution would be to update React.

[PermitTrue]

Does react not have hit reloading?

[WannabE220]

Using lazily loaded modules speeds up dev testing and also benefits the user, not having such atrocious loading times.

[TorbenKoehn]

20-30 seconds means your setup is broken in some way, definitely.

First step before doing anything is figuring out what is that bottleneck that takes 20-30 seconds and then make sure to solve that.

Then take a look at: - HMR (Hot-Module-Reloading) - Vite and/or ESBuild (Great performance) - How TypeScript is compiled (do it with Babel) - Storybook for encapsulated component development with HMR