Skip to content
This repository was archived by the owner on Jul 22, 2020. It is now read-only.

Render extension not being parsed as HTML #11

Closed
jnschrag opened this issue Apr 23, 2019 · 4 comments
Closed

Render extension not being parsed as HTML #11

jnschrag opened this issue Apr 23, 2019 · 4 comments
Labels

Comments

@jnschrag
Copy link

Hi there! I'm hoping this is a case of user error, but if it is, I can't figure out how to fix it and would appreciate some help.

I've got a barebones install of Fractal and switched to using Nunjucks instead of Handlebars. When I try to reference a component from another component, it's not being parsed as HTML, but rather as HTML characters.

For example:

<p>{{ text }}</p>
{% render '@button', {label: 'Test'} %}

results in

Screen Shot 2019-04-23 at 4 46 41 PM

My expectation is that it would render the actual button like in the image below. That does happen if I use {% include '@button' %} instead, but then I lose the ability to pull in the context data.
Screen Shot 2019-04-23 at 4 47 39 PM

For reference, here is the relevant part of the fractal.js file:

const components = fractal.components;
components.engine("@frctl/nunjucks");
components.set("ext", ".njk");
components.set("default.preview", "@preview");

Any help is much appreciated. Thank you! 🙏

@LeBenLeBen LeBenLeBen added the bug label Apr 24, 2019
@LeBenLeBen
Copy link
Member

I was able to reproduce your issue. It seems to be a regression introduced in version 2 as it works in 1.0.3, probably caused by #8. If you need it to work right now the easiest solution would be to temporarily downgrade to version 1.

@khawkins98
Copy link
Contributor

khawkins98 commented Apr 24, 2019

We had the same issue with v2, resolved by turning autoescape off and our fractal.js config includes:

  const nunj = require('@frctl/nunjucks')({
    env: {
      autoescape: false
      // Nunjucks environment opts: https://mozilla.github.io/nunjucks/api.html#configure
    }
    // ...
  });

  fractal.components.engine(nunj); 

LeBenLeBen added a commit that referenced this issue Apr 24, 2019
@LeBenLeBen
Copy link
Member

A fix has been released under 2.0.1, thanks for reporting!

@jnschrag
Copy link
Author

Thanks so much for the quick fix! It works perfectly now.

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

No branches or pull requests

3 participants