aem2doc parsing now done in da-collab

[bosschaert]

Description

da-collab now does its own aem2doc and vice versa parsing. This PR is to accommodate this on the client side.
It additionally contains a panel to show error messages from the server if there are any.

It also contains a bugfix to close the current websocket if the client navigates to a different document.

Related Issue

This is the client-side change for
adobe/da-collab#38

Screenshots

Of the new error panel.

Basic error message:

Stack trace can be seen when expanding:

How Has This Been Tested?

• Locally with da-collab and da-admin
• Unit tests

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[aem-code-sync]

Hello, I'm the AEM Code Sync Bot and I will run some actions to deploy your branch and validate page speed.
In case there are problems, just click a checkbox below to rerun the respective action.

• Re-run PSI checks
• Re-sync branch

Commits

• 5bab93d ✅ (latest)
• 1ff6820 ✅
• edecc35 ✅
• 1d2f5ac ✅
• 0e43796 ✅
• 4ad2f6b ✅
• d882b21 ✅
• 99daa75 ✅
• c79c893 ✅
• 7c67739 ✅
• f742b9d ✅
• 69a2242 ✅
• 0db0606 ✅

[bosschaert]

Note that the Playwright tests should pass again once adobe/da-collab#38 has been merged.

[auniverseaway]

I don't think we should expose these error messages to the authors. No author will ever understand a stack trace and developers have the console for debugging. This does raise some interesting considerations on parsing and what we should show in the event of an error.

It's also a little scary we already think we will have errors. Do we know what those will be? 😬

[bosschaert]

I don't think we should expose these error messages to the authors. No author will ever understand a stack trace and developers have the console for debugging. This does raise some interesting considerations on parsing and what we should show in the event of an error.

It's also a little scary we already think we will have errors. Do we know what those will be? 😬

Hi @auniverseaway, starting at the end. We're not expecting any specific errors. As a matter of fact, I have only experienced such an error once during development which was then quickly fixed by @karlpauls - after that I haven't seen any. On the other hand, as with any running process there is always the possibility of errors, albeit small.

So then the question becomes. What do we do if there is an error?

Some options:

• Nothing - in this case the Author might be wondering why things aren't working.
• Log to console - in this case the Author still doesn't see anything and is probably wondering why things don't work as the Author likely doesn't look at the console.
• Show a message - the Author realises there is something wrong and contacts support.

So my thinking was that with a message the Author is alerted to a problem and guided to contact support. The stack trace in there could be used to send to support to help them fix the problem, but I agree that maybe this is too much for on the screen.

So while I don't anticipate errors popping up what do you think the strategy should be if we have one?

[bosschaert]

This PR is now replaced by #163