Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Add MissingElementError and use it within the Skip Link #4177
Add MissingElementError and use it within the Skip Link #4177
Changes from 3 commits
462146a
b56cebf
c61fb5a
e1eff14
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
For JavaScript built-in: Error: cause browser support are we happy treating this as optional?
If so, do you mind adding a bit of safety to the
GOVUKFrontendError
constructor?i.e. Use feature detection, not a polyfill
We'll need to:
For 3) it's mainly because
'cause' in Error.prototype
didn't work 🙈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.
Or we remove
{ cause }
for another day?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'm leaning toward leaving
{ cause }
for now - feels like p'raps we need a bit more thinking about how we make it work and can do that as part of iterating on these errors.I've pushed a change to use the error messages to convey the error to the user, whaddya reckon?
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.
Very clever, absolutely love it
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.
Not a blocker, but it's triggered a discussion
To keep file size down, could we use Error
{ cause }
to keep our custom errors to a minimum? Otherwise our published package will grow as custom errors are addedE.g. Using TypeError "…not of the expected type" for
null
or missing thingsComponent errors
Here's an example with nested
{ cause }
to make the error more informative:But using the nested
{ cause }
approach to surface all that useful information. It's handy for monitoring tools like Sentry which links chained errors + stack tracesFor extra user friendliness a custom
toString()
(see below) could log the component name: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.
There's also a gotcha
We'd need to confirm Babel transforms or a polyfill for JavaScript built-in: Error: cause