-
Notifications
You must be signed in to change notification settings - Fork 1
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: Add generic error page and replace old ErrorView #877
Conversation
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.
Overall, except the 5 comments, I have not much more to say. My main issue is all these makeHTML stuff. What do we lose by rendering them with native views? We have all the UI components needed now
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 sure about that here, for me makeHtmlErrorPage is linked to view and not to domain (business logic)
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 moved it here: bf91bb6
I chose to merge the type definitions in the same file, are you ok with that?
}: MakeErrorPageProps): string => { | ||
const dimensions = getDimensions() | ||
const navbarHeight = dimensions.navbarHeight | ||
const statusBarHeight = dimensions.statusBarHeight | ||
|
||
const theme = invertedTheme ? 'theme-inverted' : 'theme-light' |
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.
can't the string be passed directly as an enum in props? that way this view file doesn't handle this trinary operator logic
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 did the change here: a821d18
The only thing we haven't done yet is to display SVG images in the native views. |
8786022
to
5f33b1b
Compare
8360d04
to
030dfbd
Compare
5f33b1b
to
9c02f92
Compare
7536879
to
91415ee
Compare
9c02f92
to
6616e21
Compare
In the next commit we will want to display an Error page using a light background This commits add the possibility to chose between light and inverted themes Default theme is inverted to keep compatibility with existing error pages
In case of unexpected error we want to display a generic error page that displays the error message and allow to display the error's technical details if needed This page is meant to replace the current ErrorView used in Login and Onboarding screens. This replacement will be done in the following commit
Current ErrorView implementation doesn't contains any design so the displayed error is very raw and is not user friendly We want to improve this UI but instead of modifying the ErrorView we replace it by the new generic error page from ErrorScreen. This would improve code homogeneity Also we now use the `navigateToError` function to analyse the error object and chose which error to display
Contact email is already displayed on the error body so we don't need the footer to be displayed
91415ee
to
7c02549
Compare
Current ErrorView implementation doesn't contains any design so the displayed error is very raw and is not user friendly
We want to improve this UI but instead of modifying the ErrorView we replace it by a new generic error page from ErrorScreen. This would improve code homogeneity
Also we now use the
navigateToError
function to analyse the error object and chose which error to displayResult page
Note that the error message is from code, so it is not translated
Result page after clicking "voir les détails de l'erreur"
Note that the details are displayed using a js
alert()
so we cannot copy its content, but it should be ok for a first iteration