HMR in preview for "non-email components" is not working
maxxlwr opened this issue Β· comments
Describe the Bug
Hey there!
I am facing a problem in my newly created project (which is installed using auto install).
I have a folder called _components
with some components that I am going to reuse in emails, it is located in the emails
folder.
The problem is that when I make a change, for example, in the file emails/_components/reusableComponent.tsx
, which is used in the file emails/some-email.tsx
, then automatically this change is not displayed in the preview. That is, I need to reload the page myself for this to happen.
If my reusableComponent.tsx
is in the components
folder (without the _
), changes to it will only re-render that component, not the components it is used in.
Some details:
MacOS Sonoma
Arc/Chrome browser
yarn/pnpm
node 21.6.1
But I don't think there is a problem with the versions.
Which package is affected (leave empty if unsure)
No response
Link to the code that reproduces this issue
https://github.com/maxxlwr/react-email-issue/
To Reproduce
- create project -
pnpm create email@canary
and run it -pnpm dev
- open preview in the browser
- add a component into
emails/_components
folder and export it, i.eReusableComponent
- add an email into
emails
folder, i.eemail-template
- import and use the
ReusableComponent
- make a change in
ReusableComponent
- browser preview will not be hot reloaded after the change in
email-template
Expected Behavior
Expected behavior is to have a working HMR regardless of which component has changed
What's your node version? (if relevant)
21.6.1
Lovely! Thank you so much for taking the time to open this issue! I'll be taking a look into that as soon as possible.
PR open that should take care of this. #1379
Will close this and let your know once it's released.
Fixed and released under react-email@2.1.1
!
See https://github.com/resend/react-email/releases/tag/react-email%402.1.1 for release notes.
Hey @gabrielmfern, it still doesn't work for me. In one of my templates changes are just ignored and in another one I have this.
src/actions/get-email-path-from-slug.ts (22:8) @ getEmailPathFromSlug
β¨― Error: Could not find your email file based on the slug by guessing the file extension. Tried .tsx, .jsx and .js.
This is most likely not an issue with the preview server. It most likely is that the email doesn't exist.
at getEmailPathFromSlug (./src/actions/get-email-path-from-slug.ts:35:11)
at endpoint (../next/dist/build/webpack/loaders/next-flight-action-entry-loader.js?actions=%5B%5B%22%2FUsers%2Fbambook%2FProjects%2Fenergi%2Fenergi-email%2Fnode_modules%2Freact-email%2Fsrc%2Factions%2Fget-emails-directory-metadata.ts%22%2C%5B%22getEmailsDirectoryMetadata%22%5D%5D%2C%5B%22%2FUsers%2Fbambook%2FProjects%2Fenergi%2Fenergi-email%2Fnode_modules%2Freact-email%2Fsrc%2Factions%2Frender-email-by-path.tsx%22%2C%5B%22renderEmailByPath%22%5D%5D%2C%5B%22%2FUsers%2Fbambook%2FProjects%2Fenergi%2Fenergi-email%2Fnode_modules%2Freact-email%2Fsrc%2Factions%2Fget-email-path-from-slug.ts%22%2C%5B%22getEmailPathFromSlug%22%5D%5D%5D&__client_imported__=!:10:17)
I've debugged it a bit and slug in this case is something like my-template/_styles/variants.ts
. Should files like this be ignored?
I use custom emails dir and tailwind if it matters
should
.ts
also be checked in the packages/react-email/src/actions/get-email-path-from-slug.ts?
Hi @gabrielmfern I can confirm that it doesn't work for me either.
I bumped the version to ` "react-email": "2.1.1". Was getting errors on anyhot reload so i reinstalled the node_modules.
errors disappeared but essentially I still can't hot-reload changes dome with nested emails nested directories
Hey @sorokin-energi, I've also had a few times when I got this error where I was updating dependencies, that might be the issue for you here. Not sure how that causes this though, still have to investigate.
it still doesn't work for me. In one of my templates changes are just ignored and in another one I have this.
Would love if you could make a reproduction for this.
I've debugged it a bit and slug in this case is something like my-template/_styles/variants.ts. Should files like this be ignored?
Yeah, they should be ignored, was this error when running email build
? Or did you manually try opening this file by changing the URL?
Yeah, they should be ignored, was this error when running email build? Or did you manually try opening this file by changing the URL?
I've seen it running email dev
after updates in some of files under _something
folder.
I have structure like this:
βββ tpl/src/
βββ emails/
βββ email-a/
β βββ _components/
β β βββ component-a.tsx <-- if I make changes here I get the error above
β βββ email-a-1.tsx <-- all good if I make changes here
βββ email-b/
βββ _components/
β βββ component-a
β βββ component-a.tsx <-- and no error and no HMR here
β βββ index.ts <-- `export * from './component-a.tsx'`
βββ email-b-1.tsx <-- all good if I make changes here
And in the second case when HMR doesn't work it seems it somehow related to how you import the component.
HMR doesn't work If I import that component like:
import { MyComponent } from './_components/component-a' // re-export from index.ts
After changes in the component-a.tsx
the getEmailPathFromSlug
fn is called once, with email-b/_components/component-a/component-a.tsx
only
But it works just fine if I import component like:
import { MyComponent }` from './_components/component-a/component-a' // directly
After changes in the component-a.tsx
the getEmailPathFromSlug
fn is called twice, once with email-b/_components/component-a/component-a.tsx
and once with email-b/email-b.tsx
I haven't dug into the code enough yet, so I'm not sure if this is useful.
UPD. I believe the first issue is related to the fact that .ts
is not handles in the packages/react-email/src/actions/get-email-path-from-slug.ts
And if we fix it we'll have issue 2 when HMR isn't triggered at all as we return changed file path where email path is expected and might be hard to detect target email path (or maybe list of email paths).
@sorokin-energi Sorry for taking a while to answer this, been busy with other issues.
I've just tested on a few file structures, similar to the one you mentioned, and I think I found the rough edges causing this. The not checking for .ts
was a part of it, but not all of it.
The only way, at least AFAIK, we can do hot reloading from the dependencies, is resolving some sort of dependency graph, which we try to do. The issue with it were three that I've noticed from experimentation:
- It was trying to get the file extension of imports without them based on a very failing heuristic (probably the cause of the errors you had)
- It was not resolving Β΄index.tsΒ΄ files from imports on directories
- Once it saw a change on a file, it would only notify the surface-level dependents of it, which would mean that very far apart changes, that were connected through imports, would not end up hot reloading for the user.
I'm not sure if there are any remaining bugs, I've already got a branch with the fixes and will open a PR in a few. Would love it if you could create an issue with some of this detail and a minimal reproduction we can test these changes on.
@sorokin-energi @szymdzum PR open for the issues you mentioned #1427