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

Consolidate EuiText and EuiMarkdownFormat styling #4663

Merged
merged 41 commits into from
Jul 22, 2021

Conversation

miukimiu
Copy link
Contributor

@miukimiu miukimiu commented Mar 24, 2021

Summary

This PR is a first step in making the EuiMarkdownFormat use the EuiText. So the EuiText improvements were thought in a way to benefit the EuiMarkdownFormat usage.

So given the complexity of this PR, we should improve issues like bottom margins of EUI components inside the EuiText in a different PR.

Or we should open a feature branch just to tackle styling issues that exist in the EuiText or in components when they live inside the EuiText. But I would say that this PR closes #4145.

Render markdown files in our docs

  • Probably it's not a necessary feature, but I started this attempt on 🎉 Documentation Section Examples Redesign #4449. There were still a few issues like the "scroll to" functionality not going to the exact position that it's now fixed.
  • The MD files are rendered with the EuiMarkdownFormat. Each h2 inside the MD files is transformed into a new section/side nav item.

Screenshot 2021-07-15 at 18 03 44

More components with Remark

  • The EuiCodeblock was fixed to have a better wrapper.
  • Blockquotes now uses a specific markdown format class
  • Tables now use a specific markdown format class
  • HRs are now using the EuiHorizontalRule

Scale text mixin

The euiScaleText mixing had some changes:

  • It now accepts a $sizingMethod that can be em or rem.
  • All the font sizes are calculated using a function fontSizeToRemOrEm($size, $sizingMethod: 'rem').
  • All the margin and paddings are calculated using a function called marginToRemOrEm($elementSize, $elementFontSize, $sizingMethod: 'rem').
  • The line-height used to return rem now returns unitless numbers. This way, it behaves the same for both rem and em font-size scenarios.

EuiText

  • It now receives a new size relative. This works for scenarios where we want to scale the font.
  • We can also pass a non-named color like a hex value.
  • Blockquotes font size now matches the base font size which is the same as paragraphs.

EuiMarkdownFormat styles

Text, Borders, and backgrounds change according to the color passed. They can also inherit or receive any EUI named color.
With this approach, I don't see the reason for having a reverseColorsFromTheme or a colorMethod that accepts solid or translucent as an option.
The decision of the color passed is on the consumer implementation. By knowing the theme context, consumers can pass colors that make sense. Also, the color prop accepts rgba colors for translucent scenarios.

Pages to test the new functionalities:

Checklist

  • Check against all themes for compatibility in both light and dark modes
  • [ ] Checked in mobile
  • Checked in Chrome, Safari, Edge, and Firefox
  • Props have proper autodocs and playground toggles
  • Added documentation
  • [ ] Checked Code Sandbox works for the any docs examples
  • Added or updated jest tests
  • [ ] Checked for breaking changes and labeled appropriately
  • [ ] Checked for accessibility including keyboard-only and screenreader modes
  • A changelog entry exists and is marked appropriately

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_4663/

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_4663/

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_4663/

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_4663/

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_4663/

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_4663/

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_4663/

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_4663/

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_4663/

Copy link
Contributor

@cchaos cchaos left a comment

Choose a reason for hiding this comment

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

❤️ I know this was a lot of work, especially the relative sizing and custom coloring. I see a lot of duplicated mixin/functions but I'm not to worried about "DRY" code at the moment because I'm really hoping Emotion will make this easier in the near future.

There are definitely a few changes to the margins/paddings/line-heights of certain text elements. It would be great to track these in a comment so that we can show the intentionality of the changes and to know exactly what has changed.


One specific formatting thing that I'm seeing with the Markdown formatter, is that is only seems to be wrapping multi-line code blocks with our actual EuiCodeBlock (not inline). It would be great that even just single line code blocks could be wrapped in EuiCodeBlock.
Screen Shot 2021-07-19 at 12 13 51 PM

src/components/text/text_color.tsx Outdated Show resolved Hide resolved
src/components/text/text_color.tsx Outdated Show resolved Hide resolved
src/components/text/text_color.tsx Outdated Show resolved Hide resolved
src/components/text/text.tsx Outdated Show resolved Hide resolved
src-docs/src/views/markdown_editor/markdown_format_sink.js Outdated Show resolved Hide resolved
src-docs/src/routes.js Outdated Show resolved Hide resolved
src-docs/src/components/guide_page/_guide_page.scss Outdated Show resolved Hide resolved
@@ -84,6 +85,19 @@ export const getDefaultEuiMarkdownProcessingPlugins = (): [
) : (
<EuiCode {...props} />
),
// When we use block code "fences" the code tag is replaced by the `EuiCodeBlock`.
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't expect any trouble, but for visibility, #4970 also edited this file and will likely merge first.

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_4663/

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_4663/

@miukimiu
Copy link
Contributor Author

miukimiu commented Jul 21, 2021

@cchaos I went through your comments and I fixed all of them expect the following one:

One specific formatting thing that I'm seeing with the Markdown formatter, is that is only seems to be wrapping multi-line code blocks with our actual EuiCodeBlock (not inline). It would be great that even just single line code blocks could be wrapped in EuiCodeBlock.

Right now this part of the code checks if there are linebreaks to use code block or otherwise inline code.

code: (props: any) =>
// If there are linebreaks use codeblock, otherwise code
/\r|\n/.exec(props.children) ? (
<EuiCodeBlock fontSize="m" paddingSize="s" {...props} />
) : (
<EuiCode {...props} />
),

I can use the technique mentioned here: rehypejs/rehype-react#6 (comment). If the props contain a className like className='language-js' is a codeblock, otherwise inline code.

code: (props) => {
          return props.className ? (
            <EuiCodeBlock fontSize="m" paddingSize="s" isCopyable {...props} />
          ) : (
            <EuiCode {...props} />
          );
        },

But I tried and if consumers don't pass a language like ```js and just pass triple backticks ``` no className is created and with this technique, it assumes it's an inline code and used the <EuiCode {...props} />. So consumers would always have to specify a language when using triple backticks.

So not sure how can we better solve this issue. Ideally, if it's passed triple backticks with or without a language it should use a EuiCodeBlock otherwise EuiCode.

But I couldn't find better solutions. @thompsongl any idea on how we can solve this?

@cchaos
Copy link
Contributor

cchaos commented Jul 21, 2021

Does that mean that rehype-react doesn't support differing between triple backticks and single backticks?

@miukimiu
Copy link
Contributor Author

I think the problem starts before. When the code gets to rehype-react the node it's already transformed without many options to distinguish if it is inline code or not.

This seems a good solution: rehypejs/rehype-react#6 (comment). Somehow we need to inject a class property at the node in order to distinguish inline/fenced code. So when it gets to rehype-react we know it's inline or not.

@thompsongl
Copy link
Contributor

thompsongl commented Jul 21, 2021

Latest commit fixes the inline (single tick) vs. fenced (triple tick) code block discrepancy.
In reality, it had more to do with whether language was provided for a fenced block. Regardless, we now get the appropriate code type by making the distinction clear in remark-prismjs.

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_4663/

Copy link
Contributor

@cchaos cchaos left a comment

Choose a reason for hiding this comment

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

💯 LGTM! I still think it's a good idea to track the differences in the text element renders. For instance the blockquote text size has been reduced. (I think it looks better, but others might not realize).

Maybe you can also update the home_view link to the new Getting Started page? 😉

I'd like an engineer to do a quick pass and then don't forget to merge with upstream to get changelog changes.

@thompsongl thompsongl self-requested a review July 21, 2021 19:16
@snide
Copy link
Contributor

snide commented Jul 22, 2021

cc @gjones You'll want to watch for this one coming downstream after it merges. We utilize the EuiText side a bit in docs.

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_4663/

@miukimiu
Copy link
Contributor Author

@cchaos I confirmed if all the margins, paddings, line-heights and font-sizes were matching the old sizes: https://github.com/elastic/eui/blob/master/src/components/text/_text.scss

It seems that I only changed blockquotes to match the base font-size/line-height. I added a CL entry with this change and updated the PR summary.

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_4663/

Copy link
Contributor

@thompsongl thompsongl left a comment

Choose a reason for hiding this comment

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

Code changes LGTM! Thanks for all the work on this 🙏

@miukimiu
Copy link
Contributor Author

Thanks @thompsongl and @cchaos for the help! 🎉

@miukimiu miukimiu merged commit 3e4beeb into elastic:master Jul 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[DRAFT] Consolidate EuiText and EuiMarkdownFormat styling
5 participants