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

Replace font size dropdown with font size entry component #5451

Merged
merged 10 commits into from Jan 17, 2024

Conversation

Shubhankerism
Copy link
Collaborator

This PR replaces the font size drop down with an font size entry component. This will allow the user to add custom font sizes ranging from 8to 72. There are also increment and decrement buttons, which allow font size update relative to the current size.
For font sizes:

  • 8-12: Step size is 1
  • 12-20: Step size is 2
  • 20-36: Step size is 4
  • 36-72: Step size is 12

This PR also fixes the issue where the user can format the codeblock if the selection begins outside the codeblock. The issue is illustrated below:

code-block-isssue

Font size entry component:

font-entry

Copy link

vercel bot commented Jan 4, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
lexical ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jan 17, 2024 0:26am
lexical-playground ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jan 17, 2024 0:26am

@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Jan 4, 2024
patch: Record<string, string | null>,
patch: Record<
string,
string | null | ((currentStyleValue: string | null) => string)
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 $patchStyle method can now accept a function that fetches the next value for the property, instead of just absolute values. This also separates the concern of calculating the value for a property away from the selection package.

@@ -5,6 +5,7 @@
* LICENSE file in the root directory of this source tree.
*
*/
import {$isCodeHighlightNode} from '@lexical/code';
Copy link
Contributor

Choose a reason for hiding this comment

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

This is sort of problematic, as it creates a dependency between these two packages. If someone were to implement code highlighting differently, they wouldn't be able to do this for their node. Typically, in these situations, we try to abstract the behavior out somehow so that's it's a heuristic on the node class, like "isUnstylable" or whatever the case is here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Hi, thanks for the review. I removed the package interdependency by exposing isStylable method from the node.

I also tried implementing by adding a class "isUnstylable" to the node DOM, but this approach required more modification to $patchStyleText method for checking the classList for each node, like calling getElementByKey for each node. Also, required changing several exisiting tests as the codeblock DOM would change.

The first approach seemed like a more cleaner and less complicated way to get the task done with minimal code changes to existing $patchStyleText method, so went ahead with it. Please let me know if this works. :)

@ivailop7
Copy link
Collaborator

ivailop7 commented Jan 7, 2024

Once, you address the package inter-dependency:
Also, could we fix up the styling a bit:

  • Add a separator before the minus button
  • Either the hover over the buttons is misaligned or the icons inside are not centered
  • Let's remove this 'shadow' inside border effect to a something lighter fitting the toolbar a bit better

@Shubhankerism
Copy link
Collaborator Author

Once, you address the package inter-dependency: Also, could we fix up the styling a bit:

  • Add a separator before the minus button
  • Either the hover over the buttons is misaligned or the icons inside are not centered
  • Let's remove this 'shadow' inside border effect to a something lighter fitting the toolbar a bit better

Thanks for the review, fixed it.

@@ -136,6 +136,14 @@ export class CodeHighlightNode extends TextNode {
return self.__highlightType;
}

/**
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't think you need this comment in here

@@ -440,6 +440,14 @@ export class TextNode extends LexicalNode {
return toggleTextFormatType(format, type, alignWithFormat);
}

/**
*
* @returns true if the text node can be formatted, false otherwise.
Copy link
Collaborator

Choose a reason for hiding this comment

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

@returns true if the text node supports font styling

Copy link
Member

@zurfyx zurfyx left a comment

Choose a reason for hiding this comment

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

LGTM, thank you! Added a comment on the new API method that might need some small additional tweaks to the existing code

Comment on lines 447 to 449
isStylable(): boolean {
return true;
}
Copy link
Member

Choose a reason for hiding this comment

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

What about canHaveFormat and canHaveStyle so that it follows the functions and properties we already have in the Node?

Copy link
Collaborator

Choose a reason for hiding this comment

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

canHaveFormat it is 🙂 Thanks, Gerard!

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Thanks for the suggestion, will make the change! :)

Copy link
Member

Choose a reason for hiding this comment

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

Sorry, I meant, should we split the functionality into two? So canHaveFormat controls the format property whereas the canHaveStyle controls the style property

Copy link
Collaborator

@ivailop7 ivailop7 left a comment

Choose a reason for hiding this comment

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

LGTM

@ivailop7 ivailop7 merged commit 931b5c2 into facebook:main Jan 17, 2024
35 of 45 checks passed
@Shubhankerism Shubhankerism deleted the font-text-entry branch January 17, 2024 15:20
amanharwara pushed a commit to standardnotes/lexical that referenced this pull request Jan 18, 2024
@placeba
Copy link

placeba commented Jan 18, 2024

Does canHaveFormat have to spread on FORMAT_TEXT_COMMAND?
If a text node doesn't support formatting (canHaveFormat returns false) we cannot apply bold, italic and other types.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants