[dev] Create toasts for console errors and warnings in dev mode.

[clintandrewhall]

Summary

As titled. This addition will surface any console.warn or console.error messages as toasts in Kibana in dev mode.

This is essentially a pre-requisite for completion of #138222 by surfacing any issues to developers as they work or navigate.

[elasticmachine]

Pinging @elastic/appex-sharedux (Team:SharedUX)

[clintandrewhall]

@spalger - That's one of my better screenshots, if I do say so myself. :elasticheart:

[Ikuni17]

Is the plan to revert this after the React upgrade is completed? A method to disable this might be good if it is going to be around for awhile.

[clintandrewhall]

@Ikuni17 I actually want to keep it around. We have lots of warnings and errors that appear in the console-- that are only logged in dev mode-- and live for a very long time without being addressed.

I'm actually curious why we'd disable it, given that we should be in the habit of fixing warnings and errors in our application?

[Dosant]

Regarding the React upgrade, my concern is a bit different. When we update, we’ll receive a warning for every ReactDOM.render call. This will be very noisy given the number of React trees we have. I don’t think spamming toasts for these warnings would be helpful, as they are expected during this transitional period.

Instead, I wanted to dedupe these ReactDOM.render warnings in the console to minimize noise during the upgrade (print console warning only once)

I also suggest to look at the toast notifications for console messages independently from the React upgrade. So suggest we have as follows:

• In dev mode, console errors pop up as toasts.
• Add the ability to mute or ignore specific messages.
• During the React 17 to 18 transition period, we mute ReactDOM.render toasts and print these warnings only once in the console to avoid having a completely red console
• After some time when most of Kibana is migrated, we can unmute the ReactDom.render toasts and remove deduplication from console, so that teams that are not helping with the upgrade catch up

[clintandrewhall]

@Dosant So the good news is:

• the interception of warnings and errors gives us the flexibility to do a lot of what you're describing.
  • we could actually suppress a lot of React 18 warnings, if we so chose
  • I think I'll split this logic into a dev package so we can have a lot more granular control of what messages appear
• toasts already dedupe the error messages, (see below)

I'll take this feedback into account, see if I can clean it up a bit in preparation for what you propose. I think simple regex would be enough to dedupe/suppress some warnings, would you agree?

[elasticmachine]

🤖 Jobs for this PR can be triggered through checkboxes. 🚧

ℹ️ To trigger the CI, please tick the checkbox below 👇

• Click to trigger kibana-pull-request for this PR!

[Dosant]

thanks!

I think simple regex would be enough to dedupe/suppress some warnings, would you agree?

yes, sure, even str.startsWith() would be good enough for the particular message I have in mind.

toasts already dedupe the error messages, (see below)

I know, I wanted to suppress/dedupe a particular warning in console also

[Ikuni17]

@clintandrewhall

I actually want to keep it around. We have lots of warnings and errors that appear in the console-- that are only logged in dev mode-- and live for a very long time without being addressed.

I'm actually curious why we'd disable it, given that we should be in the habit of fixing warnings and errors in our application?

I agree the warnings and errors should be fixed, and it is a good habit to get into. The toasts could even be opt out, but I don't think a dev should be required to use this. They may prefer to have the messages in browser dev tools only. Forcing the dev to see the toasts doesn't necessarily equate to issues being fixed, and some may find it a hinderance.

Also, we likely want to disable this in FTR and Cypress tests to avoid test flake with elements not being visible or clickable.