The memoizing of the tabs was causing the callbacks for
handleContextMenu to become dead ends. This makes more of the callbacks
into memoized callbacks and makes the handleContextMenu function itself
a memoized callback to ensure it's properly updated when its upstream
callbacks change.
This functions very similarly to VSCode's pinned tab feature. To pin a
tab, you can right-click on it and select "Pin tab" from the context
menu. Once pinned, a tab will be fixed to the left-most edge of the tab
bar, in order of pinning. Pinned tabs can be dragged around like any
others. If you drag an unpinned tab into the pinned tabs section (any
index less than the highest-index pinned tab), it will be pinned. If you
drag a pinned tab out of the pinned tab section, it will be unpinned.
Pinned tabs' close button is replaced with a persistent pin button,
which can be clicked to unpin them. This adds an extra barrier to
accidentally closing a pinned tab. They can still be closed from the
context menu.
Refactored to be more flexible. Now, it has three types
- solid
- outline
- ghost
and subtypes
- green
- grey
- red
- yellow
It defaults to solid and green when no className is provided. It
concatenates defaults if custom classNames are provided.
This PR adds support for Outer variants of each DropDirection.
When calculating the drop direction, the cursor position is calculated
relevant to the box over which it is hovering. The following diagram
shows how drop directions are calculated. The colored in center is
currently not supported, it is assigned to the top, bottom, left, right
direction for now, though it will ultimately be its own distinct
direction.
When an outer drop direction is provided for a move operation, if the
reference node flexes in the same axis as the drop direction, the new
node will be inserted at the same level as the parent of the reference
node. If the reference node flexes in a different direction or the
reference node does not have a grandparent, the operation will fall back
to its non-Outer variant.
This also removes some chatty debug statements, adds a blur to the
currently-dragging node to indicate that it cannot be dropped onto, and
simplifies the deriving of the layout state atom from the tab atom so
there's no longer another intermediate derived atom for the layout node.
This also adds rudimentary support for rendering custom preview images
for any tile being dragged. Right now, this is a simple block containing
the block ID, but this can be anything. This resolves an issue where
letting React-DnD generate its own previews could take up to a half
second, and would block dragging until complete. For Monaco, this was
outright failing.
It also fixes an issue where the tile layout could animate on first
paint. Now, I use React Suspense to prevent the layout from displaying
until all the children have loaded.
I am updating the layout node setup to write to its own wave object.
The existing setup requires me to plumb the layout updates through every
time the tab gets updated, which produces a lot of annoying and
unintuitive design patterns. With this new setup, the tab object doesn't
get written to when the layout changes, only the layout object will get
written to. This prevents collisions when both the tab object and the
layout node object are getting updated, such as when a new block is
added or deleted.
