cc @koke - This should fix what I mentioned on #643 (review)

Thank you @hypest !
I'll push the new bundles to create the WP Apps PRs.

I'm fine with this as a hotfix, but also not super happy with the naming of things. I think it's OK if we need to abandon the didMount naming and have an editorReady event that we ensure fires just once as soon as the editor is initially set up.

I am concerned that componentDidUpdate is not called in the initial render, so the event won't be triggered unless the props/state change. With this refactor I understand this is happening right now (otherwise the code on componentDidMount would still work), but it doesn't seem future-proof.

What if a future refactor changes the behaviour again and everything is ready on componentDidMount, and the component doesn't update until the user makes a change (which sounds like the desired behaviour)? In that case, the user could open a post, the editor_session_start even wouldn't get triggered right away, and they could potentially switch to classic/html without having triggered the session start.

I agree!
For those reasons I'd prefer to keep sending the editorDidMount event from the componentDidMount component lifecycle, and separate hasUnsupportedBlocks to be more flexible on when to emit that event. Whenever we emit it, we need to be sure that props.isReady == true, and to be sure we are sending it just once.

I'd prefer if we don't expose/bubble RN/React lifecycle events to the parents, as it makes it hard to understand what the intention is by looking at the interface. Instead, the interface to the parents should be as close as possible to certain functionalities.

We already do various things in wpandroid based on the editorDidMount event (sending analytics, hiding a progress bar, focusing the title bar and initiate a new media block), which means we already overloaded the initial intent (signal the presence of unsupported blocks) so, separating the events into 2 makes sense. Since this PR is about a hotfix of an important regression though, it makes sense to keep it short and quick as is, and handle the events splitting in a separate PR.

Ah oh, by the way, great job adding a test for the regression @etoledom ! 👏