Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(rich-text-editor): allow any block inside list item #157

Merged
merged 17 commits into from
Jul 25, 2022

Conversation

KyleMit
Copy link
Collaborator

@KyleMit KyleMit commented Jul 7, 2022

Closes #63

Describe your changes

Schemas dictate which elements are allowed to appear under each node. The previous schema for list item content was paragraph block*, meaning the first child must be a paragraph then 0 or more blocks under that.

If we want to allow blockquotes directly inside a list item, we'll have to open up and just allow block+, meaning one or more of any of the block level elements that we've allowed - including paragraphs, as well as blockquotes, codeblocks, etc.

PR Checklist

  • All new/changed functionality includes unit and (optionally) e2e tests as appropriate
  • All new/changed functions have /** ... */ docs (no changes to top level functions)
  • I've added the bug/enhancement and other labels as appropriate

Additional context

Change is a somewhat simple one here. One thing I wanted to investigate in making this change is how other rich text editors handle this in the UI / Action.

  • Jira - Will exit list, create new-line, and start blockquote there
  • Reddit - Will exit list, and convert list item to blockquote
  • Default ProseMirror Editor - does not allow, because default schema only allows paragraph items as the direct child of a list item

So support for this specific feature elsewhere is not widespread. We already do allow someone to create a new line within a list item and insert a blockquote on it's own line.

That said, if our goal is to ever have parity between markdown editor and rich text editor, any content restrictions will hurt our ability to do that. In markdown, you are certainly allowed to type * > blockquote list item - so anyone starting from markdown can get themselves into a situation that our Rich Text schema would consider "invalid" if we have strict schema policies. So it's probably better to relax them, even if it leads to some odd (but perfectly valid) markup

@netlify
Copy link

netlify bot commented Jul 7, 2022

Deploy Preview for nifty-lalande-39c157 ready!

Name Link
🔨 Latest commit 49acd27
🔍 Latest deploy log https://app.netlify.com/sites/nifty-lalande-39c157/deploys/62d880bdcd0511000829d8a2
😎 Deploy Preview https://deploy-preview-157--nifty-lalande-39c157.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site settings.

@KyleMit KyleMit changed the title allow any block inside list item fix: allow any block inside list item Jul 7, 2022
@KyleMit KyleMit added the bug Something isn't working label Jul 11, 2022
@KyleMit KyleMit requested a review from a team July 11, 2022 19:12
@KyleMit KyleMit marked this pull request as ready for review July 11, 2022 19:14
@KyleMit KyleMit changed the title fix: allow any block inside list item fix(rich-text-editor): allow any block inside list item Jul 11, 2022
@@ -169,7 +169,7 @@ const nodes: {
},

list_item: {
content: "paragraph block*",
content: "block+",
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only change to allow blockquotes in list items, is from forcing the content to have the first child be a paragraph with 0 or more block decadents, to having one or more of any block level element

Copy link
Collaborator

@b-kelly b-kelly Jul 20, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just double checked the commonmark spec for absolute correctness™, and it seems that list items allow basically any block element that isn't a horizontal rule, so this is good to go.

https://spec.commonmark.org/0.30/#list-items

@@ -37,7 +37,7 @@ import { _t } from "../../shared/localization";
export * from "./tables";

//TODO
function toggleWrapIn(nodeType: NodeType) {
export function toggleWrapIn(nodeType: NodeType) {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

needed to test blockquote command which is generated via this method. Other commands (like toggleHeadingLevel) are exported from here as well, so no over-arching reason to keep private

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you expose this method, you need to write documentation and unit tests for it 😉

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so, in a sense, this is actually the system under test when testing blockquotes can be inserted into lists. What we want to check is a) can we execute this command and b) does it apply the right transform. So there's a single existing test for it, but I added some more test cases for some basic coverage of toggling back and forth

@KyleMit KyleMit requested a review from b-kelly July 12, 2022 11:39
Copy link
Collaborator

@b-kelly b-kelly left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change seems appropriate to me. You'll need to add new tests and documentation for the newly exported function though.

@@ -37,7 +37,7 @@ import { _t } from "../../shared/localization";
export * from "./tables";

//TODO
function toggleWrapIn(nodeType: NodeType) {
export function toggleWrapIn(nodeType: NodeType) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you expose this method, you need to write documentation and unit tests for it 😉

@KyleMit KyleMit requested a review from b-kelly July 14, 2022 17:15
@KyleMit
Copy link
Collaborator Author

KyleMit commented Jul 18, 2022

@b-kelly - should be all set - added node tree string to custom matchers

Copy link
Collaborator

@b-kelly b-kelly left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to add some parsing/serialization tests here as well. I'll do this later today before merge. Otherwise, I think this all looks good

@b-kelly
Copy link
Collaborator

b-kelly commented Jul 20, 2022

@KyleMit I've added some markdown parsing and serializing tests - can you look into the failing one for me?

@KyleMit
Copy link
Collaborator Author

KyleMit commented Jul 20, 2022

@b-kelly, biggest gap was that there was a <code> block, but not the actual text inside it. Also some white space stuff - valid markup to just adding four spaces to create a code block, even in a nested list - and that's what the markdown serializer is doing, so adding that into the test. Should be fixed now

@KyleMit KyleMit requested a review from b-kelly July 21, 2022 15:57
@b-kelly
Copy link
Collaborator

b-kelly commented Jul 25, 2022

@KyleMit 🤦 Wow, that was a dumb mistake on my part! I knew the test should be working, but I guess I was too braindead at the time to realize it was that simple. I'll give this one last pass today and merge.

@b-kelly b-kelly merged commit f59b72f into main Jul 25, 2022
@b-kelly b-kelly deleted the kylemit/blocks-inside-list-item branch July 25, 2022 14:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Blockquote, etc buttons aren't enabled in list items
2 participants