davidjamesstone / superviews.js

Template engine targeting incremental-dom
http://davidjamesstone.github.io/superviews.js/playground/
246 stars 15 forks source link

Make the interpolation symbols configurable #33

Open willatwork opened 8 years ago

willatwork commented 8 years ago

Style tags such as the following create errors in the generated javascript:

<style>.my-class { background: red; }</style>

Superviews tries to interpolate the stuff within the curly braces.

For my purposes, I've changed the interpolate function to

function interpolate (text) {
  text = text.replace(/\{%/g, '" + (')
  text = text.replace(/%\}/g, ') + "')
  text = text.replace(/\n/g, ' \\\n')
  return strify(text)
}

Which works great for me, but forces people to use {%variable%} instead of {variable}. Instead of introducing a breaking change, I suggest making the interpolation symbols configurable.

davidjamesstone commented 8 years ago

That could be a useful option, although I can't think of a scenario apart from yours that would call for it.

I wouldn't want to encourage putting style tags into html. While it's sometime necessary, css should probably be in .css files, no? Any reason you can't import your styles using a link tag?

willatwork commented 8 years ago

We're working with web components so I'm using superviews.js in conjuction with skate.js. I gave the prototype to our web dev and he created the following snippet to test out the shadow dom:

<template name='renderMe' args="count func">
    <style>.my-class { background: red; }</style>
    <div class='my-class'>
    <span>Count: {%count%}</span>
    <script>func()</script>
    </div>
</template>

For web components, many advocate to keep the styles local to the template. Even when we want to make it external for sharing, they recommend to put it in a webcomponent template. Some are even leaning away from external style sheets.

davidjamesstone commented 8 years ago

I see - thanks for the link.

Looking at it, style tags should be treated like script tags and not iterpolated. See here. That way you wouldn't need to override the symbols.

There are probably other tags e.g. <pre> that should just be output literally.

Would this better solve your issue?

BTW, out of interest, why would you choose superviews over jsx when using skate? I'm looking at skate at the moment so I'm keen to understand. Personally don't have much experience with jsx, do you?

willatwork commented 8 years ago

Our initial fix was to use literal like the <script> tag does but we thought we may want to interpolate on the styles. While that works, it would lose some flexibility.

As for jsx, while I like React, it really is a heavy library to use (it is 10x bigger than Skate). Our particular use case requires us to be as small as possible. There are jsx solutions out there that aren't React, but we haven't found an alternative that mature/still supported.

davidjamesstone commented 8 years ago

OK I'll take a look at it then and see what changes will be required.

I don't think it's a case of just modifying the interpolation function to use the new configurable symbols though. I think the getAttrs method will need to change too as it uses the hardcoded token variable.

alexsad commented 8 years ago

Ferrugemjs also use superviewsjs and the only way do that is by importing <require from="./mystyle.css!"></require> But this would be a good feature.

willatwork commented 8 years ago

Ferrugemjs probably only supports style imports because the underlying superviews does not support the style tag. (I wonder if the maintainers would advertise that they now support style tags if this is fixed :) )

That being said, just because this bug gets fixed does not mean that you have to use style tags. You can continue to use style imports. Nothing should break.

dak commented 7 years ago

@davidjamesstone I've run into a similar issue trying to use pattern for zip codes in a form. The regex pattern for zip codes is pattern="(\d{5}([\-]\d{4})?), which fails due to the { and }.

davidjamesstone commented 7 years ago

Thanks dak.

I'll try and get this in ASAP. I'm currently overhauling the documentation for superview which is why it's been a while since the last update.