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

Allow using {% (end)raw %} tags #1220

Merged
merged 2 commits into from
Jun 2, 2020
Merged

Conversation

ang-zeyu
Copy link
Contributor

@ang-zeyu ang-zeyu commented May 3, 2020

### *netlify node_version needs to be updated to the current lts

What is the purpose of this pull request? (put "X" next to an item, remove the rest)

• [ ] Documentation update
• [x] Bug fix
• [ ] New feature
• [ ] Enhancement to an existing feature
• [ ] Other, please explain:

Resolves #762
Resolves #1206

What is the rationale for this request?
Allow usage of {% raw/endraw %} tags

What changes did you make? (Give an overview)

  • Patch a soft syntax conflict with markdown-it-attrs, allowing {% raw/endraw %} to be used
  • Auto add v-pre to code fences and inline code and <code> elements for convenience
    • usage of {% raw/endraw %} is still necessary to display {{ content }} - hence variables can still be used inside code fences / etc.
    • for all other cases ( <div/span/table/etc> ), one would need to add v-pre attribute on top of {% raw/endraw %} to disable vue compilation for that element

Is there anything you'd like reviewers to focus on?
na

Testing instructions:

  • {% raw/endraw %} should now work anywhere

Proposed commit message: (wrap lines at 72 characters)
Allow using {% (end)raw %} tags

Nunjuck's {% raw %} tags don’t work as expected due to a soft syntax
conflict with markdown-it-attrs.
In addition, variable interpolation syntax cannot be output in
code elements due to vue's variable interpolation.

Let's patch markdown-it-attrs to allow the slight syntax conflicts,
and automatically assign v-pre to code elements to skip vue compilation.

/*
Simple patch here - abort if the delimiters wrap around % %
*/
const isCharAfterStartPercent = str.charAt(start + 1) === '%';
Copy link
Contributor Author

Choose a reason for hiding this comment

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

*the only functional changes in this file are these 5 lines

Copy link
Contributor

Choose a reason for hiding this comment

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

Just to confirm, this won't break the other nunjucks templating syntax that use {% ...%} right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yup, if anything it should 'fix' it!

e.g.

{% for x in y %}
{{ x }}
{% endfor %}

this previously works (and still does) because nunjucks rendering is the first step and long precedes markdown rendering, so the {% for/endfor %} is 'erased' long before markdown-it-attrs touches it.
It dosen't work in the case of {% raw/endraw %} because it is still present at the time of markdown rendering though

So this should give more flexibility in future restructuring of the rendering order (if ever needed)

Copy link
Contributor

Choose a reason for hiding this comment

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

That makes sense, thanks for clarifying!

Copy link
Contributor

@marvinchin marvinchin left a comment

Choose a reason for hiding this comment

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

Mostly looks good to me 🙂 This is definitely a very welcome change that allows us to stop using dirty hacks in order to use variables in code blocks. Let's get the netlify build to work so that we can poke around at it to make sure that everything renders correctly.

.travis.yml Outdated
@@ -1,6 +1,6 @@
language: node_js
node_js:
- '10'
- 'lts/*'
Copy link
Contributor

Choose a reason for hiding this comment

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

What happens if we leave this as 10?

I wonder if we should leave it as a fixed version, rather than automatically updating to the latest. That would allow us to choose specifically which versions of node we develop on and support.

function preEscapeRawTags(pageData) {
return pageData.replace(REGEX, `${START_ESCAPE_STR}$&${END_ESCAPE_STR}`);
const tagMatches = pageData.matchAll(RAW_TAG_REGEX);
Copy link
Contributor

Choose a reason for hiding this comment

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

The netlify build failed because it doesn't recognise matchAll as a function. matchAll was added only in Node 12, but we support Node 10. Can we get around using matchAll?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ahh I didn't notice the supported versions. In fact node v10 is still listed under 'maintainence' here.

Will update shortly with a more verbose but compatible solution

Copy link
Contributor Author

Choose a reason for hiding this comment

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

updated with the solution suggested here https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp/exec, reverted the node version changes in travis.yml as well

/*
Simple patch here - abort if the delimiters wrap around % %
*/
const isCharAfterStartPercent = str.charAt(start + 1) === '%';
Copy link
Contributor

Choose a reason for hiding this comment

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

Just to confirm, this won't break the other nunjucks templating syntax that use {% ...%} right?

Nunjuck's {% raw %} tags don’t work as expected due to a soft syntax
conflict with markdown-it-attrs.
In addition, variable interpolation syntax cannot be output in
code elements due to vue's variable interpolation.

Let's patch markdown-it-attrs to allow the slight syntax conflicts,
and automatically assign v-pre to code elements to skip vue compilation.
Copy link
Contributor

@marvinchin marvinchin left a comment

Choose a reason for hiding this comment

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

LGTM!

@ang-zeyu ang-zeyu added this to the v2.15.0 milestone Jun 2, 2020
@ang-zeyu
Copy link
Contributor Author

ang-zeyu commented Jun 2, 2020

Thanks for looking through this! @marvinchin

@ang-zeyu ang-zeyu merged commit 8b3d3c6 into MarkBind:master Jun 2, 2020
@damithc
Copy link
Contributor

damithc commented Jun 8, 2020

@marvinchin @ang-zeyu we might have to do a release because the previous release version is no longer compatible with our own docs after this PR was merged. i.e., I can't build docs in the master branch using the previous released version of MarkBind.

@marvinchin
Copy link
Contributor

the previous release version is no longer compatible with our own docs after this PR was merged. i.e., I can't build docs in the master branch using the previous released version of MarkBind.

@damithc I think that it is reasonable for the previous release to be incompatible with the docs in master branch. Any new feature that is introduced to master that involves any syntax changes to the docs would not be compatible with the previous release. It should be sufficient that the docs on master is compatible with the markbind build on master.

That being said, it has been some time since we have done a release. Perhaps we can do one this week 🙂 @ang-zeyu shall we find some time to do the next release together?

@damithc
Copy link
Contributor

damithc commented Jun 8, 2020

@damithc I think that it is reasonable for the previous release to be incompatible with the docs in master branch. Any new feature that is introduced to master that involves any syntax changes to the docs would not be compatible with the previous release. It should be sufficient that the docs on master is compatible with the markbind build on master.

I agree @marvinchin , it's the normal case. Just that I want to do a doc PR and I don't have the dev setup.

@damithc
Copy link
Contributor

damithc commented Jun 8, 2020

But not very urgent. I can PR based on the last commit that is backward compatible. Release at your convenience.

@ang-zeyu
Copy link
Contributor Author

ang-zeyu commented Jun 9, 2020

But not very urgent. I can PR based on the last commit that is backward compatible. Release at your convenience.

Might want to hold off a little bit, let's discuss #1236 first which potentially breaks a lot of things

That being said, it has been some time since we have done a release. Perhaps we can do one this week 🙂 @ang-zeyu shall we find some time to do the next release together?

Sure! If its fine we could merge in #1189 and #1208 before doing so as well

@ang-zeyu
Copy link
Contributor Author

ang-zeyu commented Jun 9, 2020

I'm thinking of getting MarkBind/vue-strap#147 merged as well for now, so the release process is a tiny bit easier.

Not too sure if the repo merging process I mentioned there is the right/best way to do it though (aim being to preserve both repo's histories)

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.

Allow authors to use render syntax with curly braces {{ content }} Provide a way to escape nunjucks syntax
3 participants