HMR

[ryanflorence]

We thought we wanted it in the beginning, but we're not sure now. With the full-stack nature of Remix it's quite nice to have the full page reload so you don't break your app in production.

For example, if you do this:

let [state, setState] = useState(0)

Fire up your app, start working and then change it to this:

let [state, setState] = useState(localStorage.foo)

With HMR, your app continues to work just fine. If you don't hit "refresh" and try to server render that code, you'll never know you broke your app.

Our current live reload approach ensures that every change runs through a full server render pass so you don't end up with those kinds of surprises.

Additionally, when you're changing loader code, HMR won't update the UI, live reload does.

Finally, usually HMR is more about hiding the slowness of front-end build tools than about maintaining client state on code changes. ESBuild is fast, so it doesn't matter.

All that said, we've got some experimental stuff working from a while back, but it's really not high priority right now because there are some tradeoffs to consider, it's not just an obvious thing to add. Also the live reload experience right now is so good that some people think we already have HMR 🤫

This issue is here, and left open, because we haven't decided to do HMR, but we haven't decided not to either.

EDIT: 03/22

I'm not sure why I didn't mention it when we created this discussion cause it's been on our minds the whole time 🙃 but the biggest argument that keeps me believing we should do the work to add this is that it's super annoying to have to wait for your loaders when you're just screwing around with the padding on some elements. My workflow in Remix is like 10% JSX/loaders/actions/react stuff and 90% fiddling with styles. That 90% would be a lot nicer with HMR.

[alexturpin]

I appreciate the Remix team leaving the door open to this, and so just wanted to weigh in for team HMR a bit!

I understand Remix's goals with SSR first, and I also agree that with Edge computing, it's likely where everything is headed. However, I assume there are many others like me who are building apps with significant client-side state and interaction in order to create really rich UX. One example of such an app would be an online collaborative editor, something like Figma or Miro.

It would be awesome to have some fast refresh capabilities to make building that kind of apps on Remix an even nicer experience. On my current project, I even use the Vite HMR API to enhance the development experience according to our business requirements.

[itsMapleLeaf]

I've worked on a handful of "app-like apps" using Remix lately, and this is still near the top of my wish list.

Although ESBuild runs are fast, in my opinion, maintaining state between changes is a really underrated capability. It helps in cases like editing a popover state while it's open, editing a menu item while it's open, toggles, and so on. The failure case as described in the OP is a valid one for sure. But I don't know if guarding against that is worth sidestepping a potentially huge boost in DX.

[leon]

My story is I want to use remix as the framework for a react-three-fiber app.

I really like remix, but compared to using vite and their react plugin I get real time updates both to css and 3d code which is a must have once you have tried it.

Could we tell remix which folders to do fast refresh on?

that way we could get fast refresh on ui components and in my case the react-three-fiber app, but still have full reloads when changing loaders or route adjacent modules.

[dan-lee]

I think it's vital for an ambitious project like Remix to provide HMR/ fast refresh as powerful as vite. I understand the argument that a full page reload can help prevent bugs but most of the time changes don't warrant a full page reload.
I'd love to see ongoing investigation how this could be achieved

[fishuke]

I believe you can provide it as an option if possible. Like two seperate scripts:

npm run dev
npm run dev:hmr

[agcty]

Remix absolutely needs HMR, it's an amazing framework and I really wanted to migrate from Next.js but not having HMR is quite a dealbreaker for us, unfortunately.

We are building a game with react-three-fiber and have a lot of 3d models that are being loaded into a canvas.

A Canvas component could look like this:

const models = [model1, model2, ....., model100]

<Canvas>
    <ambientLight />
    <pointLight position={[10, 10, 10]} />
    <Suspense fallback={null}>
        {models.map((x) => (
          <MyModel src={x} />
        ))}
    </Suspense>
</Canvas>

each model could have a size anywhere between 50kb - 1mb in our case.

Without HMR, Remix becomes literally unusable as rebuilding the canvas can take anywhere from 20s to up to 1 minute 🥲

I understand it's non-trivial to make HMR work adequately client and server-side and that reloading in a lot of cases with LiveReload is enough, but there are a few cases where HMR becomes absolutely crucial.

[gopeter]

Literally the same for our app. Fairly large internal project management app which is built on top of dozens of components from our internal design system. Changing the style of a popup drives you crazy if the state is lost on every change.

[tiagoad]

For data visualization this would also be very useful (for the same reasons)

[agcty]

Is there anything I could help with getting HMR out of the way? Would love to know what the current issues are and what code/files I should take a look at. As @kentcdodds mentioned in discord, CSS is probably the most important thing that benefits from HMR in the short term.

[aulneau]

I am also very interested in this -- i am finally moving toward exploring remix as an option compared to next.js or vite based apps, and HMR is a huge loss for me here. I'd be happy to help contribute whatever I can towards this, I think many, many people would benefit from this. It sounds like there are a lot of good ideas too: opt in, making it clear etc etc. @ryanflorence would love if you could update us on if this is something that is coming 🙏

[shogs]

Can we have some sort of official update on this and if it is a priority now or not. I was very keen on using Remix on a new project but with the lack of HMR support makes it not so ideal now. However, if it's coming in soon I may put up with Live Reloading for the time being until HMR gets in.

Some insight, my upcoming project will need a lot of custom styling and modelling with heavy data requirement so live reloading wouldn't be ideal, though for now mocking a subset of the data would do. I've also used HMR quiet a bit in the past and I find it great for styling and design changes without reloading the entire page, sure at times you need to reload but thats never been a problem and I have never deploying without a final check or test of my app.

Thanks.

[shogs]

Thanks for the responses, sorry I didn't get a chance to respond sooner. I've actually decided to use Remix because of other factors but with the hopes that HMR will eventually come, maybe with the migration to Vite if it ever happens. Thanks...

[tigerabrodi]

@itsMapleLeaf Donny, creator of SWC told me he knew nothing about compilers when starting with SWC 😂

nothing is impossible 🔥

[JClackett]

Literally praying for HMR support! I have a 1 route app, which utilises a lot of modals and every time I save I have to open the modal. Defaulting the modal to open is the temp fix but not ideal :)

[hollandThomas]

@JClackett Have you considered putting each modal in a nested route and navigating there instead of setting some state to open it? I'm all for HMR as well but in that particular case, this might just be the solution

https://github.com/remix-run/remix/tree/main/examples/route-modal

[JClackett]

@hollandThomas yeah just switched everything to modals and this helps a lot! Thank you - still definitely a lot of use cases for hmr :)

[eagsalazar]

Any updates? Also I feel like the outlined issues with HMR aren't particularly specific to Remix and yet everyone wants it and benefits from it, so sounds like people mostly are ok with the limitations.

[hkan]

I would also suggest implementing the feature into core Remix libraries but having it disabled by default, and documenting it clearly. This way Remix authors achieve the default setup without the aforementioned pitfalls, but developers have the freedom to accept the risk and have HMR.

If anyone is keeping record of choices, I'm also pro-HMR.

[JClackett]

Agreed! No HMR is great when everything you are doing can be referenced from the URL, but there's so many use cases where this isn't suitable.

[karibertils]

Trying Remix for the first time. Looks promising, but coming from Next.js the lack of HMR feels like a huge step backwards for me. HMR is far from perfect on Next.js and very prone to breaking things, I add // @refresh reset to top of files all the time to force full reload when things start acting up. And yet I feel it's absolutely a must have killer feature.

[bradchristensen]

I just wanted to add that if you're coming here looking for a faster alternative to Next.js that supports HMR, I recommend giving Vite and vite-plugin-ssr a go. It's probably only worth looking at if your project is currently large and slow to build/develop though, rather than a little hobby project you want to get up and running quickly. By that I mean it will likely require more investment to get up and running - and bear in mind that it won't give you the same ergonomics that you get with Remix out of the box. But if, like me, all you're after is a significant speed boost coming from Next.js, that'll do the trick. As an example, my app would typically take ~5-10s to load each page in Next.js, but page loads with vite-plugin-ssr are each <1s 🔥

(And by the way, I love Remix and really hope to see HMR support at some point in the future!)

[lu-zen]

Vite is awesome.

[ourmaninamsterdam]

This is a great debate. I love Remix and I'd love to see HMR added.

We're currently evaluating tech stacks and are down to a choice between Next.js and Remix. DX being one of our core decision-making factors. So without the lack of HMR we're leaning towards Next.js. If we knew it was on the roadmap then it could swing us back.

Related to this, when you make a change to a component in Next.js, any compilation errors are piped into the browser and displayed. Whereas Remix renders the previously compiled page and shows the compilation error in the CLI, so you often miss that an error has occurred. Is there a way around this?

[hkan]

Remix renders the previously compiled page and shows the compilation error in the CLI

That's not the case for me. If there is an error it shows the error on the page. Share this issue in the Discord community's help channel, maybe?

[cliffordfajardo]

+1 to what hkan said ^

Remix renders the previously compiled page and shows the compilation error in the CLI
If there is an error in the server, I see it show in the browser - its similar to nextjs experience

[kiliman]

Not sure if OP is the same person, but someone on Discord had a similar issue. Turns out he was using the Express adapter and const build = require(BUILD_DIR) at the top, instead of dynamically in the request handler.

Anyway, Remix should work out the box. Please share a simple repro if you're still having issues.

[ourmaninamsterdam]

Runtime errors get shown in the browser without issue, but build errors aren't shown, only in the command-line. IMO it's not a serious issue, but I've been caught out a few times where I've continued making changes (non-UI) and hadn't realised that it wasn't rebuilding.

Example repo https://github.com/ourmaninamsterdam/remix-error-test

It appears there's another discussion about build errors happening here: #4196

[kiliman]

Yeah, I should publish my patch that I used in #4196

[SimeonGriggs]

It it were possible and made the feature simpler to ship: I'd be in favour of per-route, opt-in HMR.

In my instance I have an SPA (like a client-side-only dashboard) loaded at a specific route which would benefit greatly from HMR, the rest of the application is fine without it.

[machour]

Would love to have a Remix debug bar, with the ability to tick/untick HMR whenever I want it

[sudomf]

Hey all. I just started sudomf/remix-vite. It's in the very beginning. But I think I'll be able to support most of remix apps asap.

Give it a try by running.

npx remix-vite

[OnurGvnc]

Limitations
Currently, this implementation only works for React (since it relies on React Fast Refresh) and only for the Node server runtime (so not for Cloudflare nor Deno).

Removing backend-only exports for frontend at transform.ts:45
There is no transform for the backend/SSR at transform.ts:25

Let's say we ran the remix dev server normally. (node or deno or cloudflare)

If 'action' and 'loader' functions for backend/ssr in remix-vite/src/plugins/transform.ts are transformed with functions like the below, the actual backend code will work on the runtime we want.

export async function loader({ request }) {
  const url = new URL(request.url)
  const response = await fetch(
    new Request(
      `http://localhost:${process.env.ORIGINAL_REMIX_DEV_SERVER_PORT}${url.pathname}?_data=${PATH}`,
      request
    )
  )
  const contentType = response.headers.get('content-type')
  if (contentType && contentType.indexOf('application/json') !== -1) {
    const data = await response.json()
    return json(data)
  }
  // other implementations...
}

In this scenario, remix dev server and remix-vite are running at the same time. this may be considered as a disadvantage, but we make sure that the 'loader' and 'action' methods work correctly in the correct runtime.

[sudomf]

Hey @pcattori. Yes, it's all correct.

[sudomf]

@OnurGvnc I think it can work as the remix dev:hmr idea is meant just to be used for development. The users must be warned that when they run remix with hmr, they will be running a code that differs from production. And I think it's ok when we realize the existent solutions for hmr, like Vite, Webpack, already run one version of the code for dev and another version for production.

[hiyelbaz]

Should we just ignore it? @pcattori

Here is the related part of .eslintrc.cjs

[pcattori]

Yes, you can safely ignore this as Remix handles Remix-specific exports like meta, handle, etc... for you

[acusti]

i’m super excited by v1.14.0 and the new development server with HMR (and Hot Data Revalidation)! this looks exactly like what i’ve been hoping for. however, i am using the cloudflare-workers adapter for remix, so my yarn dev run script runs remix watch + miniflare simultaneously as the dev server, and i don’t use the remix dev server (no remix dev). can i simply replace my existing "dev:remix": "remix watch --debug" npm run script with "dev:remix": "remix dev" in my package.json to enable this functionality? in other words, does the remix dev server play nicely with miniflare?

[acusti]

i couldn’t get it to work. here’s what i tried: i upgraded all remix packages to v1.14.0, added future: { unstable_dev: true },, replaced my existing remix watch run script with cross-env NODE_ENV=development remix dev, and removed the LiveReload component from app/root.tsx. CSS file updates result in a line that looks like GET /__REMIX_ASSETS_MANIFEST 200 OK (1.27ms) in my dev script output, but no update to the page in the browser. same with TSX component updates.

[lili21]

Yeah. Need a better doc about how to enable it.

[dmarkow]

@acusti Why did you remove the LiveReload component? That's what's needed for the HMR updates to work.

[acusti]

@dmarkow i removed it because i first tried the upgrade / migration with the LiveReload component still in place and it didn’t work, plus i started getting lots of websocket errors in the browser console, so i figured the new dev server was a full replacement for the previous LiveReload component.

it makes sense that it would still be required, so i tried restoring it and then tried a bunch of different configs to get the websocket server working and communicating with the client (e.g. no LiveReload props.port and no remix.config.js future.port, <LiveReload port={8002} /> and remix.config.js future: { port: 8002 }, <LiveReload port={3010} /> and remix.config.js devServerPort: 3010, { future: { port: 3010 } }, all of those config options plus cross-env NODE_ENV=development REMIX_DEV_SERVER_WS_PORT=8002 remix dev in the run script, etc.), but i still just get [Error] WebSocket connection to 'ws://localhost:8002/socket' failed: Could not connect to the server. (where 8002 is whatever i configured as the port) in the browser console and no HMR.

[jgentes]

I'm in the same boat, tried many options but just get a reloading page due to websocket unable to connect to 8002. Just going without unstable_dev for now - it's unstable!