Draft-js: RichUtils.currentBlockContainsLink doesn't work with collapsed selection

Created on 29 Jun 2016  Â·  2Comments  Â·  Source: facebook/draft-js

RichUtils.currentBlockContainsLink(this.state.editorState) will return true if I have selected a span inside of a link. However, if I have the cursor inside the link but not actually a selection (a collapsed selection) then it return false. I think it should return true whether or not the selection is collapsed.

Also, it would be nice to have a function which actually returns the link instead of just true or false.

Also, the name 'currentBlockContainsLink' seems inaccurate. It should really be currentSelectionContainsLink.

Thanks. DraftJS is wonderful!

question

Most helpful comment

Perhaps some context would help. I want to create a link editing experience similar to what you get in google docs and other WYSIWYG editors. Select text to turn it into a link. When the cursor goes through an existing link it should display somewhere what the link is, and that the cursor is currently inside of a link. To edit the link or remove it you should merely need the cursor inside of the link text, not completely select the link with a selection.

So perhaps: cursorInsideLink() or EditorState.getCurrentEntity(). Or even better: getEntityAtCursor(). If it returns null then there’s nothing. If it returns a link then you not only know it’s inside of a link, but now have a reference to the entity so you can manipulate it.

As a side note, it would be great to have a code sample for updating the data of a link. I’ve managed to make it work but the code doesn’t seem quite right. It updates inline instead of returning a new content to set the state.

  • J

On Jul 3, 2016, at 8:43 PM, Isaac Salier-Hellendag [email protected] wrote:

Also, the name 'currentBlockContainsLink' seems inaccurate. It should really be currentSelectionContainsLink.

That...is weird. I don't know what that's about. It should be renamed. :)

I'm not entirely sure what the right move is here. My thoughts:

If a selection is collapsed, it's not really true that the selection contains a link.
Assuming the link is a MUTABLE entity, characters should adopt the entity too. In this sense, it is true that there is a relationship between the SelectionState and the entity.
This seems similar to EditorState.getCurrentInlineStyle(), which jumps through some hoops to try to identify the right style for the selection.
The right thing to do may be to have a method that provides the following information:

That the next typed character will adopt a link, based on the SelectionState and ContentState. Not couched in terms of "contains", but some other helpful verb.
The entity that corresponds to that link, as you propose.
What do you think?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/facebook/draft-js/issues/498#issuecomment-230199213, or mute the thread https://github.com/notifications/unsubscribe/AAQ5yvhhl73J1aoajofdSID-AeQCWPKNks5qSIFvgaJpZM4JAvY6.

All 2 comments

Also, the name 'currentBlockContainsLink' seems inaccurate. It should really be currentSelectionContainsLink.

That...is weird. I don't know what that's about. It should be renamed. :)

I'm not entirely sure what the right move is here. My thoughts:

  • If a selection is collapsed, it's not really true that the selection _contains_ a link.
  • Assuming the link is a MUTABLE entity, characters should adopt the entity too. In this sense, it is true that there is a relationship between the SelectionState and the entity.
  • This seems similar to EditorState.getCurrentInlineStyle(), which jumps through some hoops to try to identify the right style for the selection.

The right thing to do may be to have a method that provides the following information:

  • That the next typed character will adopt a link, based on the SelectionState and ContentState. Not couched in terms of "contains", but some other helpful verb.
  • The entity that corresponds to that link, as you propose.

What do you think?

Perhaps some context would help. I want to create a link editing experience similar to what you get in google docs and other WYSIWYG editors. Select text to turn it into a link. When the cursor goes through an existing link it should display somewhere what the link is, and that the cursor is currently inside of a link. To edit the link or remove it you should merely need the cursor inside of the link text, not completely select the link with a selection.

So perhaps: cursorInsideLink() or EditorState.getCurrentEntity(). Or even better: getEntityAtCursor(). If it returns null then there’s nothing. If it returns a link then you not only know it’s inside of a link, but now have a reference to the entity so you can manipulate it.

As a side note, it would be great to have a code sample for updating the data of a link. I’ve managed to make it work but the code doesn’t seem quite right. It updates inline instead of returning a new content to set the state.

  • J

On Jul 3, 2016, at 8:43 PM, Isaac Salier-Hellendag [email protected] wrote:

Also, the name 'currentBlockContainsLink' seems inaccurate. It should really be currentSelectionContainsLink.

That...is weird. I don't know what that's about. It should be renamed. :)

I'm not entirely sure what the right move is here. My thoughts:

If a selection is collapsed, it's not really true that the selection contains a link.
Assuming the link is a MUTABLE entity, characters should adopt the entity too. In this sense, it is true that there is a relationship between the SelectionState and the entity.
This seems similar to EditorState.getCurrentInlineStyle(), which jumps through some hoops to try to identify the right style for the selection.
The right thing to do may be to have a method that provides the following information:

That the next typed character will adopt a link, based on the SelectionState and ContentState. Not couched in terms of "contains", but some other helpful verb.
The entity that corresponds to that link, as you propose.
What do you think?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/facebook/draft-js/issues/498#issuecomment-230199213, or mute the thread https://github.com/notifications/unsubscribe/AAQ5yvhhl73J1aoajofdSID-AeQCWPKNks5qSIFvgaJpZM4JAvY6.

Was this page helpful?
0 / 5 - 0 ratings