Skip to content
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

Frontend Error Handling #667

Merged
merged 29 commits into from
May 15, 2019
Merged

Conversation

kschiffer
Copy link
Member

@kschiffer kschiffer commented May 9, 2019

Summary

This PR adds a start for handling errors in the console / oauth app.
Closes #41
Closes #659

image
image

Changes

  • Extend the error utils
  • Add an error boundary component
  • Add top-most error boundary to the console app (to catch any unhandled exceptions)
  • Add error boundaries to application api key and collaborators management
  • Add a full view error component to display (critical) errors
  • Add a sub view error component to display (non-critical) errors inside sub-views
  • Refactor <ErrorMessage /> component to use new error utils
  • Refactor error handling to throw errors, to be caught by error boundaries
  • Add a container component for the header, for easier reuse (necessary in full view error)
  • Add logic to make links in the header also work as plain anchor links (necessary in full view error)
  • Add a generic not found view for routes not matching any react router route
  • Small related styling tweaks
  • Add top-most error boundary to oauth app
  • Add error view for oauth app
  • Add detection of PAGE_DATA errors in both console and oauth

Notes for Reviewers

Using this approach, we can throw errors from anywhere in the render tree and have them handled by the nearest error boundary. I believe the exact granularity of where to place error boundaries will be figured out by us as we go. Also, the exact content of the error views needs to be adapted by us later based on user feedback and progressive insight. The overall goal should be to hint the user towards problem resolution whenever possible.

Otherwise:

  • I decided against using a shared error view for oauth and console, I sense that we will need to distinguish between them more clearly later. For now they use more or less the same (duplicated) error view component
  • The error boundary and page data error check could be made a part of the shared <Init />-component but I decided to do this more explicitly for now

@kschiffer kschiffer added the c/console This is related to the Console label May 9, 2019
@kschiffer kschiffer added this to the May 2019 milestone May 9, 2019
@kschiffer kschiffer requested a review from bafonins May 9, 2019 15:34
@kschiffer kschiffer self-assigned this May 9, 2019
if (error) {
return 'ERROR'
return <FullViewError error={error} />
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to this comment #659 (comment) we want to avoid this, right?
namely:

We would then have to use portals to be able to show full page errors. Otherwise, we could only display within the boundaries of the dom that the component is rendered into. E.g. in case of 404 of an entity we would still have to show the sidebar, which is not what we want. And even with portals, it would still render unnecessarily, unless we add logic to prevent that.

here is how the page looks when using this approach:
Screenshot 2019-05-10 at 17 47 42

)

/**
* Returns wether the error has a shape that is well-known
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

misleading comment imo
according to the comment i would expect the function to return true when the error shape is well-known

'407': 'Proxy Authentication Required',
'408': 'Request Timeout',
'409': 'Conflict',
'410': 'Gone',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really want to have this?
I dont see how the user can benefit from seeing Gone in the error view.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have removed all status codes here that do not have a connected grpc error.

@kschiffer kschiffer force-pushed the feature/695-frontend-error-handling branch 2 times, most recently from fb631e4 to a91ba36 Compare May 14, 2019 09:15
@kschiffer kschiffer marked this pull request as ready for review May 14, 2019 09:17
@kschiffer kschiffer requested a review from bafonins May 14, 2019 09:18
@coveralls
Copy link

coveralls commented May 14, 2019

Coverage Status

Coverage decreased (-0.01%) to 73.464% when pulling 852aa4e on feature/695-frontend-error-handling into 56f8af3 on master.

@kschiffer
Copy link
Member Author

Description updated

@@ -12,21 +12,31 @@
// See the License for the specific language governing permissions and
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is wrongfully labeled as moved file by github 🤷‍♂.

}

ErrorView.propTypes = {
ErrorComponent: PropTypes.element.isRequired,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

causes:

Warning: Failed prop type: Invalid prop `ErrorComponent` of type `function` supplied to `ErrorView`, expected a single ReactElement.
    in ErrorView (created by ConsoleApp)
    in ConsoleApp (created by WithEnv(ConsoleApp))
    in WithEnv(ConsoleApp) (created by Route)
    in Route (created by withRouter(WithEnv(ConsoleApp)))
    in withRouter(WithEnv(ConsoleApp)) (created by Console)
    in SideNavigationProvider (created by Console)
    in BreadcrumbsProvider (created by Console)
    in Router (created by ConnectedRouter)
    in ConnectedRouter (created by Connect(ConnectedRouter))
    in Connect(ConnectedRouter) (created by Console)
    in IntlProvider (created by UserLocale)
    in UserLocale (created by WithEnv(UserLocale))
    in WithEnv(UserLocale) (created by Connect(WithEnv(UserLocale)))
    in Connect(WithEnv(UserLocale)) (created by Console)
    in Init (created by Connect(Init))
    in Connect(Init) (created by Console)
    in Provider (created by Console)
    in EnvProvider (created by Console)
    in Console

@@ -129,6 +138,8 @@ Header.propTypes = {
action: PropTypes.func,
icon: PropTypes.string,
})),
/** Flag identifying whether links should be rendered as plain anchor link */
anchored: PropTypes.bool,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

apparently, this breaks the header:
Screenshot 2019-05-14 at 11 45 27

user: state.user.user,
}))
@bind
export default class Header extends Component {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

proptypes missing

@@ -24,7 +24,7 @@ import Icon from '../../../components/icon'
import DateTime from '../../../lib/components/date-time'
import Message from '../../../lib/components/message'
import Button from '../../../components/button'
import { isNotFoundError, isErrorTranslated } from '../../../lib/errors'
import { isNotFoundError, isTranslated } from '../../../lib/errors/utils'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isNotFoundError throws TypeError when creating a new gateway

<Route path={`${match.path}/add`} component={ApplicationCollaboratorAdd} />
<Route path={`${match.path}/:collaboratorId`} component={ApplicationCollaboratorEdit} />
</Switch>
<ErrorView ErrorComponent={SubViewError}>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ErrorView is not imported to the file. causes ReferenceError

@kschiffer kschiffer requested a review from bafonins May 14, 2019 13:00
@kschiffer kschiffer force-pushed the feature/695-frontend-error-handling branch 2 times, most recently from 1581eb0 to 79be69b Compare May 14, 2019 16:15
@kschiffer
Copy link
Member Author

Updated once more

@kschiffer kschiffer force-pushed the feature/695-frontend-error-handling branch 2 times, most recently from eeb4dd6 to d9a114e Compare May 15, 2019 10:10
@kschiffer kschiffer force-pushed the feature/695-frontend-error-handling branch from d9a114e to 7c9584b Compare May 15, 2019 10:13
@kschiffer kschiffer merged commit 862b340 into master May 15, 2019
@kschiffer kschiffer deleted the feature/695-frontend-error-handling branch May 15, 2019 11:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c/console This is related to the Console
Projects
None yet
3 participants