Feat/mark affinity #3147
Feat/mark affinity #3147
Conversation
|
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
felixfeng33
force-pushed
the
feat/mark-affinity
branch
from
a40eef8
to
f4f47cc
Compare
|
@12joan I have accept your suggestion. I intend to spilt this feature into three plugin.This is the The third plugin will conflict with the first plugin, resulting in a cursor that moves in steps. |
Is this the bug where setting the affinity to the left while at the start of an inline code mark creates a new, empty inline code mark to the left of it? If it's possible to fix that (which I'm not 100% sure it is), that would have to be fixed in slate-react. In my app, I've addressed this by switching to an inline code style without any padding. |
yeah,it have to be fixed in slate-react I think it will be not easy. |
| @@ -82,6 +82,7 @@ | |||
| "@udecode/plate-line-height": "workspace:^", | |||
| "@udecode/plate-link": "workspace:^", | |||
| "@udecode/plate-list": "workspace:^", | |||
| "@udecode/plate-marks-affinity": "workspace:^", | |||
There was a problem hiding this comment.
| "@udecode/plate-marks-affinity": "workspace:^", | |
| "@udecode/plate-mark-affinity": "workspace:^", |
| @@ -0,0 +1,15 @@ | |||
| # Plate marks affinity plugins | |||
There was a problem hiding this comment.
Needs proofreading and editing, but this can wait until we're closer to merging.
| "name": "@udecode/plate-marks-affinity", | ||
| "version": "31.0.0", | ||
| "description": "marks affinity plugin for Plate", |
There was a problem hiding this comment.
| "name": "@udecode/plate-marks-affinity", | |
| "version": "31.0.0", | |
| "description": "marks affinity plugin for Plate", | |
| "name": "@udecode/plate-mark-affinity", | |
| "version": "31.0.0", | |
| "description": "Mark affinity plugin for Plate", |
| import { NodeEntry } from 'slate'; | ||
|
|
||
| export interface MarkAffinityPlugin { | ||
| validMarks?: string[]; |
There was a problem hiding this comment.
Do we want to support using a function here to support more advanced use cases?
| * boundary, then the affinity should be forward. If the deletion removes | ||
| * a character from the left mark, then the affinity should be backward. | ||
| */ | ||
| editor.deleteBackward = (unit) => { |
There was a problem hiding this comment.
This should also be controlled by the plugin option
There was a problem hiding this comment.
You'll probably want to refactor out the query logic into a helper that can be reused in all the places that need to determine if a mark affinity behaviour is active.
There was a problem hiding this comment.
afterMarkBoundary is the mark boundary that should be considered for the query
| /** | ||
| * check the validMarks exclude the marks which have padding like `MARK_CODE` | ||
| */ |
There was a problem hiding this comment.
This is the consumer's responsibility, since many apps won't have padding on their code marks.
| if (!validMarks) return move(options); | ||
| if (marks.length > 0) { | ||
| for (const mark of marks) { | ||
| if (!validMarks.includes(mark)) return move(options); | ||
| } | ||
| } |
There was a problem hiding this comment.
The text nodes either side of the mark boundary should be compared against the list of allowed marks, such that the plugin is active if at least one allowed mark is present either side of the boundary
Ideally, to support more advanced use cases, we should also let the consumer specify a function that takes a mark boundary and returns a boolean.
This logic might be useful as a starting point:
typeof query === 'function'
? query(markBoundary)
: markBoundary.some(
(leafEntry) => leafEntry && Object.keys(getNodeProps(leafEntry)).some(
(mark) => query.includes(mark)
)
)| const beforeMarkBoundary = getMarkBoundary(editor); | ||
|
|
||
| /** | ||
| * If the cursor is at the start or end of a list of text nodes | ||
| * then moving outside the mark should set the | ||
| * affinity accordingly. | ||
| */ | ||
| if ( | ||
| beforeMarkBoundary && | ||
| beforeMarkBoundary[reverse ? 0 : 1] === null && | ||
| getMarkBoundaryAffinity(editor, beforeMarkBoundary) === | ||
| (reverse ? 'forward' : 'backward') | ||
| ) { | ||
| setMarkBoundaryAffinity( | ||
| editor, | ||
| beforeMarkBoundary, | ||
| reverse ? 'backward' : 'forward' | ||
| ); | ||
| return; | ||
| } |
There was a problem hiding this comment.
This behaviour should be moved into a separate plugin with its own list of allowed marks, since we probably don't want it enabled for marks like bold.
recording.mp4
In my app, I've enabled this only for code marks, since those don't have a keyboard shortcut and so are more frustrating to disable at the end of a line.
Since Plate's default code marks have padding, perhaps the default playground should only enable this behaviour for code marks at the end of a line, not at the start? If we go with that solution, there would need to be an option to re-enable it at the start of the line too.
There was a problem hiding this comment.
beforeMarkBoundary is the mark boundary that should be considered when performing the query for this behaviour.
|
|
||
| move(options); | ||
|
|
||
| const afterMarkBoundary = getMarkBoundary(editor); |
There was a problem hiding this comment.
afterMarkBoundary is the mark boundary that should be considered when performing the query for the natural mark affinity behaviour below.
|
Thank your valuable advice. @12joan |
@12joan We have discussion at #2530 .Are these the contents you expressed?