-
Notifications
You must be signed in to change notification settings - Fork 149
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
[Feature] Render error page when theme dev
encounters asset upload error
#5221
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
Coverage report
Show files with reduced coverage 🔻
Test suite run success2040 tests passing in 911 suites. Report generated by 🧪jest coverage report action from 599cdd2 |
550b4c6
to
6edd52f
Compare
7ef0845
to
7152c71
Compare
6edd52f
to
dd17d8a
Compare
7152c71
to
d7665cd
Compare
Differences in type declarationsWe detected differences in the type declarations generated by Typescript for this branch compared to the baseline ('main' branch). Please, review them to ensure they are backward-compatible. Here are some important things to keep in mind:
New type declarationsWe found no new type declarations in this PR Existing type declarationspackages/cli-kit/dist/public/node/themes/types.d.ts@@ -92,6 +92,10 @@ export interface ThemeFileSystem extends VirtualFileSystem {
applyIgnoreFilters: <T extends {
key: string;
}>(files: T[]) => T[];
+ /**
+ * Stores upload errors returned when uploading files via the Asset API
+ */
+ uploadErrors: Map<Key, string[]>;
}
/**
* Represents a theme on the file system.
|
dd17d8a
to
7e34195
Compare
8f1e4e3
to
c7c56e8
Compare
theme dev
encounters asset upload error
This comment has been minimized.
This comment has been minimized.
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.
Thanks a lot for this PR, @jamesmengo! Excellent stuff 🔥 It's great how this raises awareness on Liquid errors :)
I've noticed only one minor issue in the grouping of errors (as you may notice /sections/collage.liquid
is not bold):
Here's the content of my files with errors (I'm using dawn on main):
Thanks again for this PR! Looking forward to seeing this feature with developers :)
packages/theme/src/cli/utilities/theme-environment/hot-reload/error-page.ts
Show resolved
Hide resolved
Great work @jamesmengo! Love this project and the improvements you're making with this error page. Sorry— one small pedantic change tho... can we change the icon to I realize that's what we're using with the default But I'd like to keep things consistent— thank you! |
c114df1
to
325191f
Compare
0d5959a
to
b3049a4
Compare
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.
Looking great 🔥
'error-overlay': Flags.string({ | ||
description: `Controls the visibility of the error overlay when an theme asset upload fails: | ||
- silent Prevents the error overlay from appearing. | ||
- default Displays the error overlay. | ||
`, | ||
options: ['silent', 'default'], |
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.
Instead of passing values, should we pass allowNo: true
so that devs can use the flag as --no-error-overlay
to disable the behavior? Or do we expect to have more options in the future?
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.
yeah, the idea is to leave room for expansion moving forward, though there's no clear timeline for that so perhaps something we could call into question
@@ -31,6 +32,17 @@ export function getHtmlHandler(theme: Theme, ctx: DevServerContext) { | |||
|
|||
assertThemeId(response, html, String(theme.id)) | |||
|
|||
if (ctx.options.errorOverlay !== 'silent' && ctx.localThemeFileSystem.uploadErrors.size > 0) { | |||
html = getErrorPage({ |
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 was going to say that maybe we should set the status here to 500. However, what we are showing is the summary of the upload errors, not the rendering errors... so perhaps we should not change the status? :confused_parrot:
Ideally we'd just inject a modal overlay on top of the rendered page so that it makes sense to use status 200 and still show errors. But that doesn't need to be done now of course.
Thoughts? cc @karreiro
-- Thinking more about this, the observed result from the user is an error page so I think we should probably return status 500 regardless of the nature of the error until we move this to a modal 🤔
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.
Do you think we should try to expand the accepted types of the catch block below and use 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.
Actually, what if you do this check before calling render
and just return the error without reaching SFR? Since it's not a real overlay yet, we don't need the actual storefront document, right?
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.
Personally, I kind of like that it blocks the entire page, as we set a bit more deterministic and side-effect-free behavior (with less dependencies with the content of the theme).
b3049a4
to
7cc806f
Compare
7cc806f
to
e771c6b
Compare
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.
Great job, 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.
Thank you, @jamesmengo! Great job indeed ✨
I can no longer reproduce the issue I noticed before :) 🚀
@karreiro sorry, should have followed up. Special characters in the error message were causing the issue you saw last time! |
WHY are these changes introduced?
Fixes https://github.com/Shopify/develop-advanced-edits/issues/425
Builds on top of: #5220
Builds on top of
When using the
theme dev
command, some users were seeing discrepancies between thelocalhost preview @ 127.0.01
and the remote theme via the Online Store Editor.This scenario occurs when users are editing their assets and create an invalid change. This change prevents the file from getting uploaded to their remote theme. While this file is not saved to the remote theme, it is still being passed directly to SFR in our localhost preview (we do this to enable a snappy preview experience).
Error Page Design
WHAT is this pull request doing?
Video
This change will render an error page over the when an asset upload error is encountered (this depends on when the server responds).
These errors are asynchronous sine they come from the result of an upload operation, and can:
theme dev
theme dev
server is runningLimitations:
How to test your changes?
shopify-dev theme dev
in a valid themeErrors added while server is active
Demo.-.asset.upload.errors.whil.server.is.active.mp4
Pre-Existing Errors
iTerm2.-.jamesmeng@Jamess-MacBook-Pro-2_._src_github.com_Shopify_jm-theme.mp4
Post-release steps
vite
handles the error pageMeasuring impact
How do we know this change was effective? Please choose one:
Checklist