Repository navigation
Replies: 2 comments
|
Feature has been implemented and will be available in the upcoming release |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Problem
On web,
EnrichedLinkhardcodesopenOnClick: false, so links insideEnrichedTextInputcan never be followed.onLinkPressexists only onEnrichedText, andonLinkDetectedonly reports caret position — neithergives an editor a way to open a link.
Our users write documents in an always-editable editor and report the links
as broken, because on the web a link that does nothing when clicked reads as
a bug. We currently work around it with a
document-level capture clicklistener that finds the anchor and calls
window.open— brittle, and itfights the library rather than using it.
Proposed solution
An opt-in prop on
EnrichedTextInputfor web, defaulting to today'sbehaviour so nothing changes for existing users. Either:
onLinkPress?: (e: { url: string }) => void— same shape asEnrichedText, letting the app decide what to do; oropenLinksOnClick?: boolean— forwarded to the Link extension'sopenOnClick.We'd prefer
onLinkPressfor symmetry withEnrichedText.Alternatives considered
onLinkDetected+ a custom link bubble. Workable, but it's a lot of UI tobuild for "open this link", and it only fires on caret entry, not on click.
openOnClick.documentcapture listener, which is what we ship today.Additional context
We understand the current behaviour is deliberate and cross-platform: a
native text input can't both place the caret and follow a link on one tap,
and
onLinkPresswas removed from the Android input in #60. This request isscoped to web only, where a mouse can distinguish a click on a link from a
click to place the caret, and where users have strong expectations about
links being clickable.
react-native-enriched-html 1.1.1
All reactions