Using CoffeeScript, SASS, etc. with Polymer components

[Ahuth]

What are your thoughts on using web technologies that require a compilation step, such as CoffeeScript and SASS, inside Polymer components?

I posted the other day about a ruby gem I made called Emcee. Essentially, it allows you to declare in your Rails app what web components to import. It then handles putting those and their dependencies into the asset pipeline, and inserting html import tags into the page for them. In production, it even concatenates everything into one import tag, and runs basic compressing on it (removing comments and newlines).

So pretty much Vulcanize, except for Rails. And it handles everything automatically when the app runs.

I've been thinking about where to go next, and I realized that it will (hopefully) be pretty straightforward to add CoffeeScript or SASS compilation to the processing of Polymer components.

You could define an element like this:

<polymer-element name="my-element">
  <template>
    <span>stuff</span>
  </template>
  <script type="application/coffeescript">
    # CoffeeScript code here
  </script>
</polymer-element>

and when you load your web app, the CoffeeScript will have been converted to Javascript. The same would go for SASS.

Does anyone have an thoughts on this, and is this something people want to see? Or am I barking up the wrong tree here?

P.S. Does anyone know a better way to format code on here? It seems like the box the code example in is HUGE.

Thanks

[Scott Miles]

Just want to note that the script portion of a Polymer element can live anywhere, there is no requirement that it be inside the <polymer-element>, we just like to write it that way in most cases.

This is why you have to repeat the element name when invoking `Polymer` function, but it allows you to use any kind of system for working with script (CoffeeScript, TypeScript, ES6 modules, requirejs, whatever).

Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/a5c4e055-9506-49af-b6cd-ed89a4f093fd%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[andre...@gmail.com]

That's a good point.

If I understand you correctly, because an element can refer to an external script tag, you could easily have a build step that compiles your stand-alone coffeescript (or whatever) file. Then, your element just has to reference the compiled file. It never refers to the original CoffeeScript.

Makes sense, and that's probably a better way of handling other languages/systems than inlining them.

[Martin Kleinschrodt]

If you want you can take a look at Padlock, which is using SASS in the exact way you suggested: https://github.com/maklesoft/padlock

For complex components, I like to keep the markup, styles and js in separate files in any case. Makes it look a lot cleaner imo.

[Ahuth]

Thanks for linke. That's a great example. I'll definitely have to dig into it.

[Martin Kleinschrodt]

Btw, there is one issue with using SASS: It currently does not recognize the ^ and ^^ combinators as valid syntax and will throw a compilation error if you use them.

[Eric Bidelman]

Hi Martin, 

^ and ^^ have been replaced by /shadow/ and /shadow-deep/ in SD styling spec. Chrome Canary picked up native support as of a few days ago (make sure to have the "experimental web platform feature" flag turned on) and polyfill support works in the latest 0.2.1 release.  We updated the styling article yesterday to reflect the renames. 

Re: SASS. I opened this bug against the compiler some time ago, but now it's moot. The updated  /shadow/ and /shadow-deep combinator names work with the sass compiler.

The other gotcha with css pre-processors is that they strip out Polymer's /*@polyfill-* */ directives (because they're comments). To address this, we've moved to a css selector based approach that should be less error prone.

Example polyfill rule:

/*@polyfilll :host > .foo */

::content > .foo { ... }

Is now written using `polyfill-next-selector. The value of content is the selector to replace the next rule with:

polyfill-next-selector { content: ':host > .foo'; }

::content > .foo { ... }

We don't have documentation yet, but you can read more about it in https://github.com/Polymer/platform/issues/55.

Follow Polymer on Google+: plus.google.com/107187849809354688692

---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/af308274-88e3-40a4-9620-2c439724572c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Martin Kleinschrodt]

Awesome. Thanks, Eric! It's a shame though, I kinda liked the hat and cat combinators. Looking at those little pointy ears always makes me chuckle :)

[Ahuth]

Thanks for the info. This definitely would have bit me.

[Martin Kleinschrodt]

^ and ^^ have been replaced by /shadow/ and /shadow-deep/ in SD styling spec. Chrome Canary picked up native support as of a few days ago (make sure to have the "experimental web platform feature" flag turned on) and polyfill support works in the latest 0.2.1 release.  We updated the styling article yesterday to reflect the renames.

 I was just testing this in Canary 36 with no luck. This is what the demo in the styling guide looks like: 

Intriguingly I get the same result with experimental platform features turned off. Does this mean native shadom dom is enabled by default in the latest Canary? The polyfill seems to work as expected (both lines red in latest chrome without native shadow dom).

On Saturday, March 8, 2014 11:34:20 PM UTC+1, Eric Bidelman wrote:

[Alex Komoroske]

On Thu, Apr 3, 2014 at 9:07 AM, Martin Kleinschrodt <makl...@googlemail.com> wrote:

^ and ^^ have been replaced by /shadow/ and /shadow-deep/ in SD styling spec. Chrome Canary picked up native support as of a few days ago (make sure to have the "experimental web platform feature" flag turned on) and polyfill support works in the latest 0.2.1 release.  We updated the styling article yesterday to reflect the renames.

 I was just testing this in Canary 36 with no luck. This is what the demo in the styling guide looks like: 

Intriguingly I get the same result with experimental platform features turned off. Does this mean native shadom dom is enabled by default in the latest Canary?

Yup! It passed the Intent to Ship process in Blink about a week ago, and began its journey along the release train towards the stable channel.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/b9a2273a-6fe4-40f2-9d3c-e1056ac7a51d%40googlegroups.com.

[Eric Bidelman]

The styling guide was updated yesterday to use the latest SD css syntax. The PR is still out so the changes aren't up on the site yet.

https://github.com/Polymer/docs/pull/350

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAPwaZpXbcPkimkfOL%2BR1im%2BfhMNxJKAa9gRU3yaj_q2kdS88%2Bg%40mail.gmail.com.

[Martin Kleinschrodt]

Yup! It passed the Intent to Ship process in Blink about a week ago, and began its journey along the release train towards the stable channel.

Ah, exciting times!

 The styling guide was updated yesterday to use the latest SD css syntax. The PR is still out so the changes aren't up on the site yet.

Thanks! Seems like I'm always a step behind...

[Don Olmstead]

How close are we to a finalized version of the SD CSS syntax?

[Eric Bidelman]

After a lot of churn, the Shadow DOM css features were moved into their own spec, "CSS Scoping Module" (http://dev.w3.org/csswg/css-scoping/). The FPWD was published today! Since it's a WD, there is likely to be a bit more churn, but we're in a much better place than before. Things are settling down. It's also worth noting that Chrome Canary's implementation is up to date with the published draft.

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/514d83bd-e8e1-455f-9232-49957a87f049%40googlegroups.com.

[Benjamin Lupton]

We use pre-processors and post-processors successfully with polymer here: https://github.com/bevry/interconnect/tree/rtc.io-polymer/src/documents/components

We use DocPad for compilation, then use the compiled version on the client-side. It works really well, especially with using Browserify to bundle a component's js together.

[Andrew Huth]

For anyone stumbling across this thread, Emcee now allows users to do SASS compilation with Polymer web components and Rails. It doesn't work for inline styles, but works great for references to external scss stylesheets.

[Ian MacLeod]

Wow, how did I miss this!

I've been hacking away on https://github.com/nevir/sprockets-htmlimports and github.com/nevir/polymer-rails on the side as well. Interested in combining forces?

On Tue Jun 17 2014 at 8:33:18 AM, Andrew Huth <andre...@gmail.com> wrote:

For anyone stumbling across this thread, Emcee now allows users to do SASS compilation with Polymer web components and Rails. It doesn't work for inline styles, but works great for references to external scss stylesheets.

Follow Polymer on Google+: plus.google.com/107187849809354688692

---
You received this message because you are subscribed to the Google Groups "Polymer" group.

To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/40ceb3d4-3be3-42fe-a89c-565c60e922ea%40googlegroups.com.

[Ryan Watkins]

I also noticed that the LESS compiler throws an error on /deep/ - has anyone pursued filing an issue or fixing this?

On Saturday, March 8, 2014 5:34:20 PM UTC-5, Eric Bidelman wrote:

^ and ^^ have been replaced by /shadow/ and /shadow-deep/ in SD styling spec. Chrome Canary picked up native support as of a few days ago (make sure to have the "experimental web platform feature" flag turned on) and polyfill support works in the latest 0.2.1 release.  We updated the styling article yesterday to reflect the renames. 

Re: SASS. I opened this bug against the compiler some time ago, but now it's moot. The updated  /shadow/ and /shadow-deep combinator names work with the sass compiler.