-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(dev): HMR + Hot Data Revalidation #5259
Conversation
🦋 Changeset detectedLatest commit: 3121ea6 The changes in this PR will be included in the next version bump. This PR includes changesets to release 18 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
ff1c064
to
a84dc6e
Compare
797792c
to
c194ab5
Compare
26b7ecc
to
0ea3039
Compare
… of relying on treeshaking. This allows us to easily detect browser vs server code changes and perform the relevant reload task.
- allow hot.accept("id", cb) - surface manifest through HMR as "remix:manifest" - start plumbing for router updates
- updated warning message
87630f6
to
1832413
Compare
🤖 Hello there, We just published version Thanks! |
Known limitations for MVP: | ||
- Only implemented for React via React Refresh | ||
- No `import.meta.hot` API exposed yet | ||
- Revalidates _all_ loaders on route when loader changes are detected | ||
- Loader changes do not account for imported dependencies changing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which of these are short-term limitations and which are really hard problems that will have to be solved longer-term (or never solved at all)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Revalidates all loaders on route when loader changes are detected
- Loader changes do not account for imported dependencies changing
👆 short-term, should be resolved before HMR is stabilized
- No
import.meta.hot
API exposed yet
👆 we already prototyped a import.meta.hot
API so my gut is that we can also do this short-term as needed
- Only implemented for React via React Refresh
👆 If we have import.meta.hot
API, then HMR should be implementable in user-land for any other rendering frameworks/libraries. Out-of-the-box HMR support for other renderers would come after we support that renderer (e.g. after @remix-run/vue
exists or something like that).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sweet. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I've noticed that HMR can be quite slow (several seconds after save). Is that expected? If you want to play around with a real world project that has this issue, check: https://github.com/epicweb-dev/rocket-rental
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I've noticed that HMR can be quite slow (several seconds after save). Is that expected? If you want to play around with a real world project that has this issue, check: https://github.com/epicweb-dev/rocket-rental
Yes, planning on optimizing for perf soon. Though we are also limited by how quickly the app server can pick up changes. E.g. if using nodemon
, how quickly can the app server be restarted. I know for Rocket Rental you are using tsx watch
, so that might be a limiting factor.
That said, I think we should be able to make app server restart only blocking for HDR, and not for HMR (e.g. if we can serve the updated assets immediately from the dev server). For making HDR faster, server-side HMR (instead of server restart) would be needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think my server is restarting. I'm doing the purge require cache approach instead
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think my server is restarting. I'm doing the purge require cache approach instead
Ah whoops. Saw tsx watch
and made assumptions, but you are only watching for changes in ./index.js
and not build/index.js
. Make sense.
Yea so to summarize, we can optimize HMR speed directly, but have limitations on HDR speed depending on how fast your app server responds with an up-to-date build hash via __REMIX_ASSETS_MANIFEST
endpoint. Should be able to at least speed up HMR part as part of stabilizing this feature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's great to hear! Thanks Pedro!
Exploring
the depths of our universeHMR in Remix w/ @jacob-ebeyDepends on remix-run/react-router#9996
TODO
reason
field for HMR updates to support contextual logs and debugging_internalSetRoutesAndRevalidate()
(naming tbd)unstable_dev
future flagexport function loader() {...}
) OR loader variable expression (export let loader = () => {...}
)<Scripts />
to<LiveReload />
or dedicated component?dev
Follow-on work
esbuild
'sresult.errors