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: updates to html block #906

Merged

Conversation

jennspencer
Copy link
Contributor

PR App Fix RM-10043

🧰 Changes

Reworks HTML blocks a bit so they're nicer and easier for the user to interact with (makes sure the HTML is always nicely formatted for slate and the markdown/mdx doc)

🧬 QA & Testing

Copy link
Contributor

@rafegoldberg rafegoldberg left a comment

Choose a reason for hiding this comment

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

Looking good! Had some questions/suggestions, but nothing major.

return `<HTMLBlock${attributes && ' ' + attributes}>{\`${ html }\`}</HTMLBlock>`;
const { runScripts, html } = getHProps<HTMLBlock['data']['hProperties']>(node);

return `<HTMLBlock${runScripts != null ? ' runScripts="' + runScripts + '"' : ''}>{\`\n${ reformatHTML(html) }\n\`}</HTMLBlock>`;
Copy link
Contributor

@rafegoldberg rafegoldberg Jun 17, 2024

Choose a reason for hiding this comment

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

If we're converting this to use a template string, we should probably also make it easier to read while we're at it:

Suggested change
return `<HTMLBlock${runScripts != null ? ' runScripts="' + runScripts + '"' : ''}>{\`\n${ reformatHTML(html) }\n\`}</HTMLBlock>`;
return `<HTMLBlock ${runScripts != null ? `runScripts="${runScripts}"` : ''}>{\`
${reformatHTML(html)}
\`}</HTMLBlock>`;

Copy link
Contributor Author

Choose a reason for hiding this comment

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

sure! although i'm aesthetically offended by the extra space that's left if there's no runScripts prop 😂

return `<HTMLBlock${attributes && ' ' + attributes}>{\`${ html }\`}</HTMLBlock>`;
const { runScripts, html } = getHProps<HTMLBlock['data']['hProperties']>(node);

return `<HTMLBlock${runScripts != null ? ' runScripts="' + runScripts + '"' : ''}>{\`\n${ reformatHTML(html) }\n\`}</HTMLBlock>`;
Copy link
Contributor

@rafegoldberg rafegoldberg Jun 17, 2024

Choose a reason for hiding this comment

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

Ahhh, so it looks like you're setting the runScripts prop to a string on compile here. I'll betchya anything that's the reason it's sometimes coming in as a string, per my above question? Can we update this to be a JSX-y value instead?

- `runScripts="${runScripts}"`
+ `runScripts={${runScripts}}`

If I'm understanding correctly, I believe ^that should resolve to true rather than "true"!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

for some reason MDX was treating {true} as an object. it's on my list to work out, but i had just put this in as a stop-gap so the functionality could be tested!

processor/utils.ts Outdated Show resolved Hide resolved
types.d.ts Show resolved Hide resolved
Copy link
Collaborator

@kellyjosephprice kellyjosephprice left a comment

Choose a reason for hiding this comment

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

Some questions and I really think we shouldn't munge the html value.

processor/transform/readme-components.ts Show resolved Hide resolved
processor/utils.ts Show resolved Hide resolved
const { position } = node;
const children = getChildren<HTMLBlock['children']>(node);
const { runScripts } = getAttrs<Pick<HTMLBlock['data']['hProperties'], 'runScripts'>>(node);
const html = formatHTML(children.map(({ value }) => value).join(''));
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think trimming the content is fine, but I worry that changing the indent could be problematic. I'm inclined to say we shouldn't munge the string beyond trimming leading and trailing whitespce?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah i'm not a big fan of the munging, which is why i tried to keep it to a minimum. if you just .trim(), the raw HTML displays in a messy way in the widget code editor/the recompiled markdown :(

Copy link
Collaborator

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

it reindents the HTML so it's not at the same indentation as the main HTMLBlock component. i admit it was a subjective style choice, but it helps make the md doc easier to read?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

(while also keeping the original structure as much as possible)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

(and i totally admit that there are a few scenarios here i need to account for)

| [![PR App][icn]][demo] | Fix RM-XYZ |
| :--------------------: | :--------: |

## 🧰 Changes

Describe your changes in detail.

## 🧬 QA & Testing

- [Broken on production][prod].
- [Working in this PR app][demo].

[demo]: https://markdown-pr-PR_NUMBER.herokuapp.com
[prod]: https://SUBDOMAIN.readme.io
[icn]:
https://user-images.githubusercontent.com/886627/160426047-1bee9488-305a-4145-bb2b-09d8b757d38a.svg
Copy link
Collaborator

@kellyjosephprice kellyjosephprice left a comment

Choose a reason for hiding this comment

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

Code looks good! But I think the failing test with whitespace is a blocker. And I'm not sure I understand the motivation for this???

I understand trimming so we can get something like:

<HTMLBlock>{`
...
`}</HTMLBlock

That's nice and good. But I'm still not keen on messing with the internal whitespace. I think leaving it unindented would be fine:

<HTMLBlock>{`
<h2>
  <img>
  Hello!
</h2>
`}</HTMLBlock>

Is there something I'm missing with regards to the editor? The thing that makes this important to me, is that if we start applying a particular formatting to this block, and it turns out to be a problem later, we'd probably have to run a big migration to fix it.

@jennspencer
Copy link
Contributor Author

jennspencer commented Jun 20, 2024

@kellyjosephprice i stg greg made a comment somewhere that he preferred the scenario i was trying to munge, but i can't find anywhere it so it's possible i'm losing my mind.

if the user does decide to indent the html in the HTMLBlock, it'll show up in the widget's code editor with the indents though. is that enough of an issue to do something about or just leave it? i'm wildly ambivalent, mostly because users probably tend to stick with their preferred way of editing (editor vs raw markdown)

oh and i'm totally fixing the test, just had to figure out what was the "correct" outcome of it first 😂

Copy link
Collaborator

@kellyjosephprice kellyjosephprice left a comment

Choose a reason for hiding this comment

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

Sorry and thank you!

@jennspencer jennspencer merged commit ddc97db into beta Jun 20, 2024
9 of 11 checks passed
@jennspencer jennspencer deleted the jenn/rm-10043-custom-html-blocks-not-rendering-in-editor branch June 20, 2024 21:38
rafegoldberg pushed a commit that referenced this pull request Jun 20, 2024
## Version 6.75.0-beta.60

### 🛠 Fixes & Updates

* updates to html block ([#906](#906)) ([ddc97db](ddc97db))

<!--SKIP CI-->
@rafegoldberg
Copy link
Contributor

This PR was released!

🚀 Changes included in v6.75.0-beta.60

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants