Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature: add component toolbar portal target #360

Closed
wants to merge 3 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions packages/core/components/DraggableComponent/index.tsx
Original file line number Diff line number Diff line change
Expand Up @@ -97,12 +97,14 @@ export const DraggableComponent = ({
{label && (
<div className={getClassName("actionsLabel")}>{label}</div>
)}
<div id={`DraggableComponentToolbarPortal-${id}`} />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the purpose of this portal? To inject new actions into the toolbar?

If so, I think a first party API might be a cleaner way of doing this instead of asking the user to inject via a portal. Something like <Puck toolbarActions={<div />} />

Copy link
Contributor Author

@4leite 4leite Mar 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want to be able to inject from the inline editor. eg https://inline-rich-text.vercel.app/edit (click on the heading).
In the above example they are at the end of toolbar, but I think the middle is better (that was just the easiest for me to target with getElement / css Query hack).
These are dynamically changing based on lexical plugins and contextual for each draggable component.
An alternative would be to set them via setUI, but I do think the portal option is much cleaner for my particular use case.

Copy link
Member

@chrisvxd chrisvxd Mar 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this API needs a bit more thought before we move forwards:

  1. I don't think we should be using portals for some elements of custom UI, and props for others.
  2. Users may wish to remove existing overlay controls (possibly a separate, but related API)

I'm now tracking this here: #377

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would still like the (amended) UI fix for the dropdown, which I can put as a separate PR.

#377 is good, but... I would still at the least like a stable data-* attribute I can target in the mean time, even if it's an experimental, undocumented solution.

<button className={getClassName("action")} onClick={onDuplicate}>
<Copy size={16} />
</button>
<button className={getClassName("action")} onClick={onDelete}>
<Trash size={16} />
</button>
<div className={getClassName("actionsMask")} />
</div>
</div>
<div className={getClassName("contents")}>{children}</div>
Expand Down
9 changes: 9 additions & 0 deletions packages/core/components/DraggableComponent/styles.module.css
Original file line number Diff line number Diff line change
Expand Up @@ -116,6 +116,15 @@
box-sizing: border-box;
}

.DraggableComponent-actionsMask {
position: absolute;
right: 0px;
top: 36px;
height: 11px;
width: 100%;
background: transparent;
}

.DraggableComponent--isSelected
> .DraggableComponent-overlay
> .DraggableComponent-actions {
Expand Down
Loading