Per-link native context menus would let apps provide actions for specific Markdown destinations while keeping the long-press menu anchored to the link. The existing onLinkLongPress callback can still handle other links and platforms.
Proposed optional API for iOS 17 and later:
linkContextMenus={{
'./notes.md': {
title: 'Notes',
items: [{ text: 'Open', icon: 'doc.text', onPress: ({ url }) => openDocument(url) }],
},
}}Items follow the existing contextMenuItems text/icon/visible conventions, with disabled and destructive flags. Icons are SF Symbols. Keys and action events retain the original Markdown URL, including relative paths. Labels are unique within each URL's menu. Navigation, copying, and other actions stay in JavaScript.
A nonempty menu would replace the system preview and take precedence over onLinkLongPress. Empty, hidden-only, and unconfigured menus would keep existing behavior. Older iOS, Android, macOS, and web would continue using the callback integration. This would cover CommonMark text and GitHub-flavor text segments, nested quotes, and tables without changing text-selection or block-copy APIs.
I have prepared an independent implementation and targeted regression coverage. Would this optional API fit the project's direction?
Per-link native context menus would let apps provide actions for specific Markdown destinations while keeping the long-press menu anchored to the link. The existing onLinkLongPress callback can still handle other links and platforms.
Proposed optional API for iOS 17 and later:
Items follow the existing contextMenuItems text/icon/visible conventions, with disabled and destructive flags. Icons are SF Symbols. Keys and action events retain the original Markdown URL, including relative paths. Labels are unique within each URL's menu. Navigation, copying, and other actions stay in JavaScript.
A nonempty menu would replace the system preview and take precedence over onLinkLongPress. Empty, hidden-only, and unconfigured menus would keep existing behavior. Older iOS, Android, macOS, and web would continue using the callback integration. This would cover CommonMark text and GitHub-flavor text segments, nested quotes, and tables without changing text-selection or block-copy APIs.
I have prepared an independent implementation and targeted regression coverage. Would this optional API fit the project's direction?