[WIP] Hoist visual editor selection state to shell layer

[yeze322]

Description

Previous implementation is a hack, replace it with a recommended solution.

Changes:

1. Inside Visual Editor, hoist several related states to global store by migrating to useReducer hook
2. In ShellApi level, register a new API syncEditorState to enable state synchronization between Shell & Visual Editor
3. Inside Shell, consume a new computed state visualEditorActive (computed from editorState) to control if toolbar buttons (Copy/Cut/Delete) should be active.
4. Fix a bug: selected was passed as focusedSteps but it's actually a trigger (Form, Shell)

Following works:
Apply this pattern to clipboard action, will potentialy persist copied actions in shell layer to enable copy/paste across dialog files.

Todos:

1. [Visual Editor] reducer could be covered by UT
2. [Visual Editor] need to clean old local context / states

Task Item

#1170 - Resolve item 1

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Code refactor (non-breaking change which improve code quality, clean up, add tests, etc)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Doc update (document update)

Checklist

• I have added tests that prove my fix is effective or that my feature works
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have functionally tested my change

Screenshots

Please include screenshots or gifs if your PR include UX changes.

[yeze322]

WIP: add UT for reducer

[cwhitten]

Why is this called syncEditorState? We shouldn't be "syncing" anything, that suggested were mirroring state. The Shell data should hydrate the visual editor.

[yeze322]

Maybe its name should be onStateChange or onStoreChange: on each state change, notify container.

[yeze322]

There is a tricky problem here. Because of the iframe layer breaks change detection, state exchanging between Shell and editors has a really high cost (which resulted us to optimize it in #1106 ), so the normal pattern value + onChange no longer works fine. If we split 3 props into 3 pairs of 'value + onChange' to hydrate with Shell data, it will cause performance issue. Therefore, there is a onStateChange API for handling all state exchangings.

[yeze322]

According to comments below, we don't need the syncEditorState api. The interface will be:

<VisualEditor ... selection={selection} onChangeSelection={(selection) => shellApi.onChangeSelection(selection)} />

My only concern here is during a drag selection, the performance will be poor

[cwhitten]

I don't like how you've defined this to suggest that a grouping of nodes is a concern of the visual editor. This isn't the case. The visual editor has a mechanism to group nodes and nothing more.

Here is why: If the visual editor gets redrawn for whatever reason, we still want to hold the grouped nodes in state.

[yeze322]

Yes, This logic is supposed to be moved into lower level, at least down to ExtensionContainer / VisualEditorContainer.

[yeze322]

What about this one

<VisualEditor clipboardActions={actions} setClipboardActions={(actions) => shellApi.setClipboardActions(actions)} />

[yeze322]

@cwhitten I realized the issue you talked about. My following plan:

1. revert to the 'selectTo' api and compute the boolean in design page (a simple function should work)
2. add one more api 'setClipboard', pass clipboardActions as props

[yeze322]

Fix it in another approach, close this PR.