fix(preview): fix router when deployed on subpath

[timofei-iatsenko]

Component / Package Name:

This PR contains:

• bugfix
• feature
• refactor
• documentation
• other

Are tests included?

• yes (bugfixes and features will not be merged without tests)
• no

Breaking Changes?

• yes (breaking changes will not be merged unless absolutely necessary)
• no

If yes, please include "BREAKING CHANGES:" in the first commit message body, followed by a description of what is breaking.

List any relevant issue numbers: #245

This PR fixes an incorrect setting introduced here #247

Description

The preview still doesn't work when deployed on the subpath. Assets are loaded but router configured incorrectly and returns Route not Found error

I'm filling a bit guilty, because I proposed this solution, but actually i didn't test it and speculated only looking to the code on the github. It turned out that the basepath should go into the basename router parameter.

[shellscape]

Running the code as-is with your method for testing worked successfully. Is it only when deployed beyond localhost that it fails? I'm looking for the conditions needed for the code to fail as it is in main, since that's the only way we can protect against regressions here.

[shellscape]

Strange, that's what I used to test and it worked here.

[timofei-iatsenko]

Just found that pnpm resigned to update @jsx-email/app-preview stated as peer automatically. So i had following dependencies

"jsx-email": "2.3.5"
"@jsx-email/app-preview": "2.0.2"

When i updated the @jsx-email/app-preview explicitly to the latest i was able to see the preview app on the https://127.0.0.1:8080/email-preview/

But the react-router is still configured incorrectly, when you click on any of the templates you will see that it creates an incorrect path /{template name} instead of /email-preview/{template name}, and next f5 will cause page to be broken again.

This PR is fixing this. Currently, you assign only the root path in the router to the basepath.

[timofei-iatsenko]

Thoughts:

Using a path based navigation /root/templateName brings additional complication for the deployment and make the artifact non-transportable.

It's possible to achieve more self-contained / deployment-proof artifact if you will use hash based navigation instead:

/root/#?templateId={}

This approach is used in the playwright reports, for example. Also this approach allow deploying without an explicit specifying a --base-path

[shellscape]

Good catch.om the url. Will give this some thoughts today and act on it tonight.

[shellscape]

Played around a bit with this. I'm liking the pattern of /root/#virtual/template/path since it looks pretty and isn't much of a cognitive jump. We're heading out of town this afternoon for the U.S. Thanksgiving holiday, so I'll probably be a bit more delayed than usual. If that pattern is something you'd like to work into this PR, that would be cool. No worries if not, I can get to it when I'm free.

[shellscape]

Using createHashRouter is working quite well. I'm going to release a patch version of jsx-email and a major version of @jsx-email/app-preview with the routing changes, and some other misc internal changes that speed up the preview, and should allow for the flexible deployments.

[timofei-iatsenko]

Using createHashRouter is working quite well. I'm going to release a patch version of jsx-email and a major version of @jsx-email/app-preview with the routing changes, and some other misc internal changes that speed up the preview, and should allow for the flexible deployments.

After implementing createHashRouter you can also drop recently added --base-path parameter, and set relative base https://vite.dev/guide/build#relative-base

[shellscape]

@timofei-iatsenko v2.4.0 is out and should tackle the concerns in this PR. (I haven't removed the base path flag yet)

[timofei-iatsenko]

@shellscape thanks, also path: import.meta.env.VITE_JSXEMAIL_BASE_PATH || '/' should be deleted as it's not needed with hash-based router