|
| 1 | +# UI Plugins to refactor |
| 2 | + |
| 3 | +These are the plugins that are the main target for refactoring. The goal is to reduce complexity by only storing the minimal state needed to render the UI element, & everything else to be derived from that state or moved into the UI layer (React). The main reason for needing to store any state at all is to allow different parts of the UI to be updated independently, like one menu being able to open another menu. |
| 4 | + |
| 5 | +- FilePanel |
| 6 | + - `blockId`: the id of the block that the file panel is associated with |
| 7 | +- FormattingToolbar |
| 8 | + - `show`: whether the formatting toolbar is shown |
| 9 | + - `.getReferencePos()`: based on the bounding box of the selection |
| 10 | +- LinkToolbar |
| 11 | + - State-driven only React now |
| 12 | +- SideMenu |
| 13 | + - `show`: whether the side menu is shown |
| 14 | +- TableHandles |
| 15 | + - decorations |
| 16 | + - `draggingState`: the state of the dragging operation |
| 17 | +- SuggestionMenu |
| 18 | + - decorations |
| 19 | + - `query`: the current query string for the suggestion menu |
| 20 | + |
| 21 | +## Plan |
| 22 | + |
| 23 | +- Move most plugin state from plugin views into react |
| 24 | + - If that is not possible, move into an extension which has a tanstack store |
| 25 | +- Migrate things to use `useEditorState` which is a hook with a better pattern for selecting the correct parts of the editor state that we are interested in |
| 26 | +- Move plugins managing menus into floating UI hooks & React |
| 27 | + - If it is a UI state, it should be in React |
| 28 | + - Examples: menu position, menu open/close, etc. |
| 29 | + - If it is an editor state, or accessible across plugins, it should be in an extension |
| 30 | + - Examples: active blocks, exposing methods, etc. |
| 31 | + |
| 32 | +<!-- ## How to execute the plan |
| 33 | +
|
| 34 | +### Phase 1: Refactor plugin state |
| 35 | +
|
| 36 | +Reduce derived state, and move anything UI state into React. --> |
0 commit comments