feat: error boundary in layout to handle application errors / crashes

[catosaurusrex2003]

Description
As proposed and discussed here #1101 (comment).

Changes proposed in this pull request:

1. Added an error boundary in layout to handle errors generated by infinite recursion and such so that the application doesnt crash into an irrecoverable state.

2. Reused the already existing Error component to render error,

Related issue(s)
#1100

[catosaurusrex2003]

In Firefox:

In Chrome:

The Error Boundary is detecting the error being generated by the browser on too much recursion and rendering the Error component.

Used this asyncapi document for testing

asyncapi: 3.0.0
info:
  title: Account Service
  version: 1.0.0
  description: This service is in charge of processing user signups
channels:
  userSignedup:
    address: user/signedup
    messages:
      UserSignedUp:
        $ref: '#/components/messages/UserSignedUp'
    x-recursion:  #RECURSION here
      $ref: '#'
operations:
  sendUserSignedup:
    action: send
    channel:
      $ref: '#/channels/userSignedup'
    messages:
      - $ref: '#/channels/userSignedup/messages/UserSignedUp'
    x-recursion: #RECURSION here
      $ref: '#'
components:
  messages:
    UserSignedUp:
      x-recursion: #RECURSION here
        $ref: '#'
      payload:
        type: object
        properties:
          x-recursion: #RECURSION here
            $ref: '#'
          displayName:
            type: string
            description: Name of the user
          email:
            type: string

[catosaurusrex2003]

@reachaadrika could you please review this pull request too when you get a chance? 😄 Thanks in advance!

[AceTheCreator]

awesome improvement, but i noticed when i fix the recursive properties in the schema, the error still persists in the UI until i either refresh or re-paste a valid schema 🤔

[AceTheCreator]

Is this line still relevant? i mean since you've imported the error boundary in the layout container and it already includes the error component.

[catosaurusrex2003]

Yes it is important.

This line handles the errors in our document when parsing it. The errors are in turn diagnostics with severity 0. Introduced in this PR: https://github.com/asyncapi/asyncapi-react/pull/1082/files

The error boundary, on the other hand, is used to catch unexpected application errors, such as a recursion error, and is a separate concern.

[AceTheCreator]

This line handles the errors in our document when parsing it. The errors are in turn diagnostics with severity 0.

Aren't we already handling these errors here

asyncapi-react/library/src/containers/AsyncApi/Standalone.tsx

Line 79 in afd5e8c

concatenatedConfig.show?.errors && (

?

[AceTheCreator]

The error boundary, on the other hand, is used to catch unexpected application errors, such as a recursion error, and is a separate concern.

I agree with you 👍🏾

my question now is if {configShow.errors && error && <Error error={error} />} is relevant if we are already handling it in the standalone code, don't you think?

[catosaurusrex2003]

nice observation 👀

As far as i can tell, here in Standalone. Whenever there is an error in the document. Our asyncapi variable becomes undefined. So the if else statements here in standalone catch the error.

And it never reaches our Error component in Layout.

So maybe we can remove the Error component rendering in Layout. Correct me if i am wrong or missing out on something.

Or we can move the conditional statements into Layout to check in one place only.

[catosaurusrex2003]

with some modification of prop types
we can put this in Layout.tsx and remove the Error rendering from Standalone

  return (
    <ConfigContext.Provider value={config}>
      <section className="aui-root">
        {asyncapi ? (
          <SpecificationContext.Provider value={asyncapi}>
            <div
              className={`${observerClassName} relative md:flex bg-white leading-normal`}
              id={config.schemaID ?? undefined}
              ref={ref}
            >
              {configShow.sidebar && <Sidebar />}
              <div className="panel--center relative py-8 flex-1">
                <div className="relative z-10">
                  {configShow.info && <Info />}
                  {configShow.servers && <Servers />}
                  {configShow.operations && <Operations />}
                  {configShow.messages && <Messages />}
                  {configShow.schemas && <Schemas />}
                </div>
                <div className="panel--right absolute top-0 right-0 h-full bg-gray-800" />
              </div>
            </div>
          </SpecificationContext.Provider>
        ) : (
          configShow.errors && error && <Error error={error} />
        )}
      </section>
    </ConfigContext.Provider>
  );

which yeilds the same effect.

Let me know your thoughts on this.

[catosaurusrex2003]

but i noticed when i fix the recursive properties in the schema, the error still persists in the UI until i either refresh or re-paste a valid schema 🤔

Thanks for highlighting that. Have put some logic to rerender the component fresh.

[sonarcloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud