Request a feature.
Editor.toggleMarks doesn't exist (but used to, as toggleMark, before 0.50).
Slate: 0.50.2
Browser: Chrome
OS: Mac
I was wondering if there are plans to add this back-in... it's not difficult to implement in user-land, but it seems pretty useful to have.
For instance, the walkthroughs on https://docs.slatejs.org/walkthroughs/05-executing-commands (erroneously) uses "Editor.toggleMarks" as a way to handle a user bolding/unbolding text.
It's also implemented in the Rich Text example
That's a great question!
I don't feel solid about the current set of mark-related helpers at all. I don't love that activeMarks is a kind of weird edge case in the helpers API, with some baked-in logic about how to lookup the marks. I'd really like to be able to merge it into the Editor.marks iterable, or even make a Editor.matchMark for finding an instance of a mark instead. (The current activeMarks is kind of a leftover.)
So your question got me thinking, and I just pushed up some better Editor.marks and Editor.nodes behaviors for matching. Specifically to get the "active marks" you can now do:
const [...universalMarks] = Editor.marks(editor, { mode: 'universal', continuing: true })
And for matching a specific type:
const [bold] = Editor.marks(editor, { match: { type: 'bold' }, continuing: true })
Same goes for nodes:
const [...links] = Editor.nodes(editor, { match: { type: 'link' }})
Prior to these, I was reticent to have Editor.toggleMarks because it would have to use Editor.activeMarks internally which had hard-to-customize logic in it.
But I _think_ with these we could re-introduce Editor.toggleMarks by passing in these options to make it a bit more customizable. For example:
Editor.toggleMarks(editor, [bold, italic], { mode: 'universal' })
Would consider them "on" only if they are universally present. Or:
Editor.toggleMarks(editor, [underline])
Would consider them "on" if they are present on any text node.
So if you want to PR that, I'd gladly accept! (And help them with reviewing to get it right if you are unsure.)
@ianstormtaylor thanks for the thorough response!
I might take a crack at this PR in the coming weeks (but for anyone else reading, feel free to take this on also. I'll update here if I actually start begin working on it)
This is no longer relevant with the removal of marks. The toggling can be achieved in userland depending on domain-specific logic for determining whether a format is active.
Most helpful comment
That's a great question!
I don't feel solid about the current set of mark-related helpers at all. I don't love that
activeMarksis a kind of weird edge case in the helpers API, with some baked-in logic about how to lookup the marks. I'd really like to be able to merge it into theEditor.marksiterable, or even make aEditor.matchMarkfor finding an instance of a mark instead. (The currentactiveMarksis kind of a leftover.)So your question got me thinking, and I just pushed up some better
Editor.marksandEditor.nodesbehaviors for matching. Specifically to get the "active marks" you can now do:And for matching a specific type:
Same goes for nodes:
Prior to these, I was reticent to have
Editor.toggleMarksbecause it would have to useEditor.activeMarksinternally which had hard-to-customize logic in it.But I _think_ with these we could re-introduce
Editor.toggleMarksby passing in these options to make it a bit more customizable. For example:Would consider them "on" only if they are universally present. Or:
Would consider them "on" if they are present on any text node.
So if you want to PR that, I'd gladly accept! (And help them with reviewing to get it right if you are unsure.)