[lexical-react][lexical-playground] Feature: Makes the sidebar available inside Column Layout #7361
Conversation
sescandell
requested review from
zurfyx,
fantactuka,
acywatson,
Fetz,
ivailop7,
Sahejkm and
potatowagon
as code owners
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
facebook-github-bot
added
the
CLA Signed
| @@ -43,17 +43,56 @@ const Downward = 1; | |||
| const Upward = -1; | |||
| const Indeterminate = 0; | |||
|
|
|||
| let prevIndex = Infinity; | |||
| interface ElementInfosHolder { | |||
There was a problem hiding this comment.
This name is kinda redundant, information doesn't have a separate plural form in english and generally speaking any data structure is a "holder" (particularly in a language like JS) so "InfosHolder" doesn't make sense. I would just call it BlockElement because that's how you're referring to it in the API (e.g. getBlockElementFromNodes returns this type)
| interface ElementInfosHolder { | |
| interface BlockElement { |
| [draggableElement, editor], | ||
| ); | ||
|
|
||
| const $getInnerNodes = useCallback( |
There was a problem hiding this comment.
There's no reason to wrap this with useCallback, it could just be a top-level function since it doesn't close over any variables in the component
| function getBlockElementFromNodes( | ||
| // Array of array: from left to right then top to bottom | ||
| nodeKeys: string[][], |
There was a problem hiding this comment.
I haven't done a very close audit of all of these changes but I am not sure this is the right data structure and API for this purpose. I think a better solution might be to have a function that's more like $getBlockDescendants: (key: ElementNode) => ElementNode[], working directly with keys is something that's more of an implementation detail rather than a good interface for users to specify.
There was a problem hiding this comment.
Now that you mention it... I should be able to use the isInline() method to determine whether I need to go deeper or not, and create something more dynamic and general, rather than being limited to the Column Layout.
Give me some time to rework this PR. 👍
There was a problem hiding this comment.
I think for this case a parent with $isRootOrShadowRoot is likely what you need to be looking at rather than isInline, e.g. RootNode, LayoutItemNode, TableCellNode, CollapsibleContentNode are probably the only nodes in the playground that should have this UX for managing their children and they are all roots or shadow roots. There are other shadow roots but there's generally some command listeners that prevent selections from falling there, e.g. TableNode, TableRowNode, CollapsibleContainerNode, etc.
sescandell
changed the title
sescandell
changed the title
Description
The DraggablePlugin currently only works on top-level nodes. For instance, when using the Column Layout block, users cannot access the "Add Above" or "Add Below" buttons inside a column. This limitation makes it difficult to work with nested structures.
This PR introduces a new mechanism allowing users to provide a function to control how deeply the plugin navigates and how to retrieve inner nodes within complex structures. This enhancement gives users greater flexibility to customize the plugin's behavior and user interface.
Additionally, this PR introduces the ability to replicate Notion-like behaviors for column layouts. However, it does not address drag-and-drop functionality inside columns, as that is already unsupported. This PR serves as a first step toward enabling drag-and-drop within column layouts, which will be probably tackled in a separate PR.
Test plan
Before
msedge_98hS6Oa8t9.mp4
After
msedge_0qxeOMlMnV.mp4