Problem
There's no way to attach a native action sheet / menu to an arbitrary in-content element. The only menu primitive today lives inside native_navbar_tag:
<%= native_navbar_tag do |navbar| %>
<% navbar.button "More", icons: { ios: "ellipsis.circle" } do |menu| %>
<% menu.item "Mark finished", click: "#finish-button" %>
<% menu.item "Delete", click: "#delete-button" %>
<% end %>
<% end %>
That's the trailing/leading navbar surface only. A common pattern that doesn't fit is "tap a status pill, see the alternative statuses, pick one" — the trigger is a content element, not a navbar button.
Came up in the Shelf showcase demo (demos/showcase). The Book Detail page has a status pill ("Want to read" / "Currently reading" / "Finished"). Ideal UX is tap the pill, an iOS action sheet slides up with the other two options. Today we'd have to either bury the options in the trailing nav menu or push a separate status-edit screen presented as a modal sheet.
Possible API
Something like:
<button id="status-pill">Want to read</button>
<%= native_menu_tag anchor: "#status-pill" do |menu| %>
<% menu.item "Currently reading", click: "#mark-reading" %>
<% menu.item "Finished", click: "#mark-finished" %>
<% end %>
The native shell observes taps on #status-pill and presents a UIAlertController action sheet (iOS) / BottomSheet (Android) populated from the menu items. Existing menu.item semantics (icons, selected, click, href) reused.
Alternative API shape: a data-native-menu attribute on the trigger element that references the menu's id, similar to how popovers work in HTML.
Out of scope here
- Cancel button text customization (defaults to "Cancel" / system standard)
- Destructive item styling (could reuse a
destructive: true flag on menu.item)
- Title/message header on the sheet (start without one)
Problem
There's no way to attach a native action sheet / menu to an arbitrary in-content element. The only menu primitive today lives inside
native_navbar_tag:That's the trailing/leading navbar surface only. A common pattern that doesn't fit is "tap a status pill, see the alternative statuses, pick one" — the trigger is a content element, not a navbar button.
Came up in the Shelf showcase demo (
demos/showcase). The Book Detail page has a status pill ("Want to read" / "Currently reading" / "Finished"). Ideal UX is tap the pill, an iOS action sheet slides up with the other two options. Today we'd have to either bury the options in the trailing nav menu or push a separate status-edit screen presented as a modal sheet.Possible API
Something like:
The native shell observes taps on
#status-pilland presents a UIAlertController action sheet (iOS) / BottomSheet (Android) populated from the menu items. Existingmenu.itemsemantics (icons, selected, click, href) reused.Alternative API shape: a
data-native-menuattribute on the trigger element that references the menu's id, similar to how popovers work in HTML.Out of scope here
destructive: trueflag onmenu.item)