-
Notifications
You must be signed in to change notification settings - Fork 9
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
fix: updates to html block #906
Conversation
There was a problem hiding this 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.
processor/compile/html-block.ts
Outdated
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>`; |
There was a problem hiding this comment.
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:
return `<HTMLBlock${runScripts != null ? ' runScripts="' + runScripts + '"' : ''}>{\`\n${ reformatHTML(html) }\n\`}</HTMLBlock>`; | |
return `<HTMLBlock ${runScripts != null ? `runScripts="${runScripts}"` : ''}>{\` | |
${reformatHTML(html)} | |
\`}</HTMLBlock>`; |
There was a problem hiding this comment.
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 😂
processor/compile/html-block.ts
Outdated
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>`; |
There was a problem hiding this comment.
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"
!
There was a problem hiding this comment.
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!
There was a problem hiding this 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.
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('')); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What kind of messy way, cause it seems wrong to me: https://github.com/readmeio/markdown/pull/910/files#diff-3abd1a08f8ea2dfcc23db22057e28a7278deda6fb0f0e81583b1babe581edf76R17-R29
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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
There was a problem hiding this 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.
@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 oh and i'm totally fixing the test, just had to figure out what was the "correct" outcome of it first 😂 |
There was a problem hiding this 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!
This PR was released!🚀 Changes included in v6.75.0-beta.60 |
🧰 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