requirejs+polymer

[Joern Turner]

sorry, if that's a recurring question having answered elsewhere already. After searching the discussions i only found some remarks on that but no defnitive answer.

We're also very interested to load polymer with requirejs or at least use them in conjunction. Anybody found a solution to that? Any pragmatic approach would be welcome.

Second: after reading for a while i haven't found answers to the questions what polymer does to the global objects (window, document ...) and how/if it changes the javascript language.

Thanks,

Joern

[Addy Osmani]

As a long-time RequireJS user, I personally haven't yet run into a situation where I've needed to use AMD alongside Polymer or HTML imports just yet. It does however look like someone has tried to work on a general Web Components plugin for Require which supports Polymer, though I haven't personally tested this myself: https://github.com/tmorin/requirejs-plugin-wc

[cletusw]

I think it's useful to clarify why this is the case. RequireJS has three goals (http://requirejs.org/docs/why.html#2):

• Some sort of #include/import/require
• ability to load nested dependencies
• ease of use for developer but then backed by an optimization tool that helps deployment

HTML Imports solves the first two easily. <link rel="import"> works within an imported HTML file just as well as it does from the main index.html (or whatever) file.

The third point has been addressed here (http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0479.html) and here (https://groups.google.com/forum/#!searchin/polymer-dev/concatenate/polymer-dev/jXkjkwjbIG8/WJN90ck6v9wJ). Basically, HTML Imports places no restrictions on what's in the imported file. For example, Vulcanizer (https://github.com/Polymer/labs/tree/master/vulcanize) is a tool that concatenates all of your individual component HTML files into a single one. Then all you have to do is rewrite your main HTML file to pull in that one instead of the individual ones. See the second link (the Google Groups one) for Addy Osmani's progress on doing all of this with grunt.js.

In short: There's really no reason to use RequireJS *and* HTML Imports unless you're jumping into an app that's already using RequireJS and can't easily be modified to change that.

As to your second question, here are the changes I could find (this list is by no means comprehensive):

• Adds a "register" function to "document" (http://www.polymer-project.org/platform/custom-elements.html#documentregister)
• Overrides "document.createElement" to support creation of custom elements (http://www.polymer-project.org/platform/custom-elements.html#using-a-custom-element)
• Adds a "createShadowRoot" method and a "shadowRoot" property to the HTMLElement prototype (http://www.polymer-project.org/platform/shadow-dom.html#basic-usage)
• Modifies HTMLElement's prototype's "innerHTML" and "firstChild" properties, as well as basically anything that returns a Node (http://www.polymer-project.org/platform/shadow-dom.html#wrappers)
• Adds a "bind" method to all DOM Node objects (https://github.com/Polymer/mdv/blob/master/docs/node_bind.md#why-nodeprototypebind)
  
• Looks like there's a "createBinding" method on HTMLElement's prototype. Don't have any docs for this.

Clayton

[michaels...@gmail.com]

What about global scope issues?

With AMD, you don't have to worry about using or implementing a `noConflict` method as found in popular libraries like lodash, as a module doesn't cause side-effects in the global scope (i.e. `window`) unless the script's author deliberately causes such a side-effect.

But with HMTL Imports, it's not clear to me that you can achieve a similar level of encapsulation -- is it achievable?

Now, if every library in use was implemented as a custom element that hung everything on its constructor and/or instances, then this would be a moot point. However, it seems unlikely that one would or would want to re-implement or somehow wrap a lib like lodash into a custom element -- or maybe I'm wrong on that point and that *is* the direction component-proponents would expect things to go. Thoughts?

Thanks for your insights.

--

Michael Bradley, Jr.

@michaelsbradley

On Friday, July 26, 2013 4:51:21 PM UTC-5, cletusw wrote:

I think it's useful to clarify why this is the case. RequireJS has three goals (http://requirejs.org/docs/why.html#2):

• Some sort of #include/import/require
• ability to load nested dependencies
• ease of use for developer but then backed by an optimization tool that helps deployment

HTML Imports solves the first two easily. <link rel="import"> works within an imported HTML file just as well as it does from the main index.html (or whatever) file.

The third point has been addressed here (http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0479.html) and here (https://groups.google.com/forum/#!searchin/polymer-dev/concatenate/polymer-dev/jXkjkwjbIG8/WJN90ck6v9wJ). Basically, HTML Imports places no restrictions on what's in the imported file. For example, Vulcanizer (https://github.com/Polymer/labs/tree/master/vulcanize) is a tool that concatenates all of your individual component HTML files into a single one. Then all you have to do is rewrite your main HTML file to pull in that one instead of the individual ones. See the second link (the Google Groups one) for Addy Osmani's progress on doing all of this with grunt.js.

<snip>

[Eric Bidelman]

There was a good thread on the namespace question a few weeks back:

https://groups.google.com/d/topic/polymer-dev/90Dq_2bk8CU/discussion

Basically, HTMLImports has nothing to say about encapsulation or conflict

avoidance. It's simply a convenient tool for including HTML in other HTML.

To prevent global pollution for Custom Elements, one thing you could do is wrap the constructor returned by document.register() in a namespace:

http://www.polymer-project.org/faq.html#constructorattr

--
 
---
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.
Visit this group at http://groups.google.com/group/polymer-dev.

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/3f285843-6e60-4038-8645-5c72eabeef09%40googlegroups.com.

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

[michaels...@gmail.com]

I'm already wrapping, always, as a rule.

The situation I describe is with respect to loading via script tag 3rd party libraries that aren't themselves implemented as custom elements.

Suppose I have a project which imports CustomA, which loads by script tag PopularLibX version 1.3; and I also import 3rd party CustomB, which also loads by script tag PopularLibX, but incompatible version 2.1.

If both PopularLibX versions are setting up `window.popLibX` and the PopularLibX author didn't implement something like a lodash `noConflict` method, then there's going to be a problem.  The problem is exacerbated if my project imports lots of elements which may in turn load by script tag lots of libraries with conflicting versions or conflicting use of the global namespace.

This is exactly the type of thing that AMD (e.g. RequireJS) can help with inasmuch as loading a module doesn't depend on hanging something on `window`, and thus it's possible to have two incompatible versions of a library loaded at the same time without causing any problems for the consuming modules.

I'm not saying that I think integrating RequireJS into Polymer is necessarily the way to go. But I think that as Polymer grows up in the near term, and we look toward a future where custom elements, potentially quite a lot at a time, are specified as dependencies by way of something like bower (and they in turn have non-custom element dependencies like PopularLibX, which they load by script tag), then this will be more of an issue.

It's possible I've overlooked something and am overblowing this concern, so I appreciate your feedback.

Thanks.

--

Michael Bradley, Jr.

@michaelsbradley

[michaels...@gmail.com]

I replied a bit too quickly.

By "always wrapping" I meant I am wrapping my `Polymer(...)` code in IIFEs. I realize now that you were referring to something different.

However, my other points still stand.

Thanks again for your feedback.

On Friday, July 26, 2013 9:49:13 PM UTC-5, michaels...@gmail.com wrote:

I'm already wrapping, always, as a rule.

The situation I describe is with respect to loading via script tag 3rd party libraries that aren't themselves implemented as custom elements.

Suppose I have a project which imports CustomA, which loads by script tag PopularLibX version 1.3; and I also import 3rd party CustomB, which also loads by script tag PopularLibX, but incompatible version 2.1.

If both PopularLibX versions are setting up `window.popLibX` and the PopularLibX author didn't implement something like a lodash `noConflict` method, then there's going to be a problem.  The problem is exacerbated if my project imports lots of elements which may in turn load by script tag lots of libraries with conflicting versions or conflicting use of the global namespace.

This is exactly the type of thing that AMD (e.g. RequireJS) can help with inasmuch as loading a module doesn't depend on hanging something on `window`, and thus it's possible to have two incompatible versions of a library loaded at the same time without causing any problems for the consuming modules.

I'm not saying that I think integrating RequireJS into Polymer is necessarily the way to go. But I think that as Polymer grows up in the near term, and we look toward a future where custom elements, potentially quite a lot at a time, are specified as dependencies by way of something like bower (and they in turn have non-custom element dependencies like PopularLibX, which they load by script tag), then this will be more of an issue.

It's possible I've overlooked something and am overblowing this concern, so I appreciate your feedback.

Thanks.

--

Michael Bradley, Jr.

@michaelsbradley

On Friday, July 26, 2013 8:04:48 PM UTC-5, Eric Bidelman wrote:

There was a good thread on the namespace question a few weeks back:

https://groups.google.com/d/topic/polymer-dev/90Dq_2bk8CU/discussion

Basically, HTMLImports has nothing to say about encapsulation or conflict

avoidance. It's simply a convenient tool for including HTML in other HTML.

To prevent global pollution for Custom Elements, one thing you could do is wrap the constructor returned by document.register() in a namespace:

http://www.polymer-project.org/faq.html#constructorattr

<snip>

[Scott Miles]

Here is an example of using Polymer with requirejs. 

http://jsbin.com/efojap/2/edit

> the PopularLibX author didn't implement something like a lodash `noConflict` method

Unless I am mistaken, requirejs doesn't solve this problem. You would have to make a requirejs module that loads 'PopularLibX' to even try to solve it, and it still may not be possible. 

S

P.S. Don't get me wrong, `requirejs` is a great piece of engineering, top shelf IMO.

--

 
---
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.
Visit this group at http://groups.google.com/group/polymer-dev.

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/94b747d1-9039-4efd-b2b6-e4607bb29bce%40googlegroups.com.

[Joern Turner]

Thanks a lot for the detailed and helpful response. Very much appreciated. We just start using polymer and still try to find our way around and how it'll fit into the big picture we got. We would love to go for web components but are still also scared by the early status and the bleeding-edgeness of it ;)

We tend to work with plain html imports for now (reducing our initial setup complexity).

Two more side remarks inline...

Am Freitag, 26. Juli 2013 23:51:21 UTC+2 schrieb cletusw:

I think it's useful to clarify why this is the case. RequireJS has three goals (http://requirejs.org/docs/why.html#2):

• Some sort of #include/import/require
• ability to load nested dependencies
• ease of use for developer but then backed by an optimization tool that helps deployment

* asynchronous loading

Not sure which effect it'll have when my components relies on several javascript imports which may itself being loaded async but how does it look like for the ones in the component? Surely a detail issue and we have many other things to deal with before ;)
 

HTML Imports solves the first two easily. <link rel="import"> works within an imported HTML file just as well as it does from the main index.html (or whatever) file.

The third point has been addressed here (http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0479.html) and here (https://groups.google.com/forum/#!searchin/polymer-dev/concatenate/polymer-dev/jXkjkwjbIG8/WJN90ck6v9wJ). Basically, HTML Imports places no restrictions on what's in the imported file. For example, Vulcanizer (https://github.com/Polymer/labs/tree/master/vulcanize) is a tool that concatenates all of your individual component HTML files into a single one. Then all you have to do is rewrite your main HTML file to pull in that one instead of the individual ones. See the second link (the Google Groups one) for Addy Osmani's progress on doing all of this with grunt.js.

In short: There's really no reason to use RequireJS *and* HTML Imports unless you're jumping into an app that's already using RequireJS and can't easily be modified to change that.

As to your second question, here are the changes I could find (this list is by no means comprehensive):

• Adds a "register" function to "document" (http://www.polymer-project.org/platform/custom-elements.html#documentregister)
• Overrides "document.createElement" to support creation of custom elements (http://www.polymer-project.org/platform/custom-elements.html#using-a-custom-element)
• Adds a "createShadowRoot" method and a "shadowRoot" property to the HTMLElement prototype (http://www.polymer-project.org/platform/shadow-dom.html#basic-usage)
• Modifies HTMLElement's prototype's "innerHTML" and "firstChild" properties, as well as basically anything that returns a Node (http://www.polymer-project.org/platform/shadow-dom.html#wrappers)
• Adds a "bind" method to all DOM Node objects (https://github.com/Polymer/mdv/blob/master/docs/node_bind.md#why-nodeprototypebind)
  
• Looks like there's a "createBinding" method on HTMLElement's prototype. Don't have any docs for this.

Ok, quite understandable. I just wondered with there's some overloading of '$' which might collide (or at least require precaution) with might internally use jquery?

Joern

 

[Joern Turner]

Am Samstag, 27. Juli 2013 02:38:24 UTC+2 schrieb michaels...@gmail.com:

What about global scope issues?

With AMD, you don't have to worry about using or implementing a `noConflict` method as found in popular libraries like lodash, as a module doesn't cause side-effects in the global scope (i.e. `window`) unless the script's author deliberately causes such a side-effect.

But with HMTL Imports, it's not clear to me that you can achieve a similar level of encapsulation -- is it achievable?

Now, if every library in use was implemented as a custom element that hung everything on its constructor and/or instances, then this would be a moot point. However, it seems unlikely that one would or would want to re-implement or somehow wrap a lib like lodash into a custom element -- or maybe I'm wrong on that point and that *is* the direction component-proponents would expect things to go. Thoughts?

Probably not lodash - or maybe not getting your point...

i consider it a requirement for us to be able to wrap the thousands of 'components' that already exist outside. Just considered the huge amount of jquery plugins that are there for free use and often would make up a good web component once wrapped up as such. We simply want to re-use all that stuff if it comes in handy for the application that must be build. E.g. i don't want to implement a complete tree view implementation from scratch as a component - instead i'd like to use one of the wonderful 'pseudo-components' out there (be it jquery or whatever), import my dependencies and use them as a component. I'm not sure if that's realistically achievable and is a scenario considered by the web components group but it's definitely a critical factor to us.

Of course on the longer run it's preferrable to have leaner implementations as 'native' web components. But there will be years (hopefully not) that web components rule the browser world.

[Joern Turner]

Am Samstag, 27. Juli 2013 04:49:13 UTC+2 schrieb michaels...@gmail.com:

I'm already wrapping, always, as a rule.

The situation I describe is with respect to loading via script tag 3rd party libraries that aren't themselves implemented as custom elements.

Suppose I have a project which imports CustomA, which loads by script tag PopularLibX version 1.3; and I also import 3rd party CustomB, which also loads by script tag PopularLibX, but incompatible version 2.1.

If both PopularLibX versions are setting up `window.popLibX` and the PopularLibX author didn't implement something like a lodash `noConflict` method, then there's going to be a problem.  The problem is exacerbated if my project imports lots of elements which may in turn load by script tag lots of libraries with conflicting versions or conflicting use of the global namespace.

This is exactly the type of thing that AMD (e.g. RequireJS) can help with inasmuch as loading a module doesn't depend on hanging something on `window`, and thus it's possible to have two incompatible versions of a library loaded at the same time without causing any problems for the consuming modules.

I'm not saying that I think integrating RequireJS into Polymer is necessarily the way to go. But I think that as Polymer grows up in the near term, and we look toward a future where custom elements, potentially quite a lot at a time, are specified as dependencies by way of something like bower (and they in turn have non-custom element dependencies like PopularLibX, which they load by script tag), then this will be more of an issue.

It's possible I've overlooked something and am overblowing this concern, so I appreciate your feedback.

i absolutely agree with you - both in the analysis and the conclusion - there shoud be something handling the described situation (and keep the global namespace clean) one day but it really doesn't need to be requirejs.

Joern
 

[jer...@marzhillstudios.com]

Just saw this thread when I was looking for info on using requirejs packaged modules with web components.

Don't know if any additional progress has been made on this but I'm experiementing on porting an application that uses requirejs over to polymer and needed a way to load requirejs dependencies and whipped up this: https://gist.github.com/zaphar/6564897

It's kind of rough at the moment but it works and by listening for the event in in my other components I can get any of the requirejs modules I might need. Comments on the approach or pointers to someone's more complete solutions would be appreciated.

[nicolas....@gmail.com]

I use polymer module and get them to use some module defined using require.js.

In the polymer  I do:

    NBLuciole=require("lucioles"); 

and then I can call all exported functions (here NBLuciole is an object with methods)

     lu= new NBLuciole.NBLuciole(v)

     if(debug) console.log("lal lu= ",lu.str());

I import require.js in my main html file (a django template in this case). Then it loads polymer.js and my 

web components.

<script data-main="/static/ffs/js/miniMain" src="/static/ffs/js/require.js"></script>

    <script src="/static/ffs/js/polymer.js"></script>

   <link rel="import" href="/static/ffs/src/canrect-js.html">

    <link rel="import" href="/static/ffs/src/canrectfull-js.html">

    <link rel="import" href="/static/ffs/src/cancirc-js.html">

    <link rel="import" href="/static/ffs/src/cancirc-rel-js.html">

    <link rel="import" href="/static/ffs/src/canimage-js.html">

minMain.js requires some modules, one of which requires "lucioles".        

The way it is setup is so that require loading takes place before polymer starts working.

All this takes place before  

[matt.c...@gmail.com]

In short: There's really no reason to use RequireJS *and* HTML Imports unless you're jumping into an app that's already using RequireJS and can't easily be modified to change that.

Well there are really several reasons that you'd still want to use requirejs (or some other require tool like gluejs) instead of html imports.

Consider having several web components that depend on q.js, some others that depend on d3 and maybe others on largelocalstorage.

You'd need a module loader like requirejs to elegantly solve this problem.  Having a module loader (and a module_path for that loader) would allow each component to do:

var Q = require('Q');
var d3 = require('d3');
var storage = require('lls');
...

without the component ever having to know the paths to those modules.  The application developer would also not have to figure out what html imports they need in their index.html since the imports for each component are taken care of by the component and module loader.

Using a module loader will also ensure that duplicate libraries are not loaded since libraries would be referred to by their name and not their path in this configuration (https://npmjs.org/package/grunt-bower-requirejs).

Module installation would be taken care of by the component's package/bower.json and a package manager.

Granted that in some cases package managers would need to be updated to recursively look for package.json files and reconcile the dependencies they discover (e.g., the case where you are developing, and using, several new components in the same repo).

[Gabriel Gartz]

I like the idea of using requirejs and polymer project together, some points:

* Requirejs system migration: you just can't re-develop everything to work with only polymer from one day to another.

* Using logical libs for a custom element: Some custom elements can be very complex, using the require js allow you to easier coding with namespace and modules dependence.

Other points, it's possible to create a Custom Element to trigger and manipulate requirejs, but you need to load polymer project before the requirejs.

And finally the problem with requirejs loading before polymer project it's in the way that requirejs create and use script elements to append on the head from the DOM, where the ShadowDOM from Polymer decorate the elements and if isn't decorated it throw a assert exception, so if require is loaded before to load polymer it wont work.

[Eric Bidelman]

Scott, don't you have a new HTML import + JS module loader POC or brain dump somewhere? Am I making that up?

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/ca2cc747-8c1e-476e-8f9d-774f622a9ebb%40googlegroups.com.

[a.cog...@samsung.com]

Hi,

is there any progress related to this topic?

BR,

Alessandro

[Jan Schreyer]

I am unsure if I get everything right, but I think this answer is only true when the developer is fully embracing the 'everything is an element' paradigm.

Personally, I don't do that. While I really appreciate Polymer for its syntactic sugar on web-components, I just can't stand having to add an element to my markup when I want to use it only for script operations. It feels wrong to me.

It would be fantastic if I could use HTML imports for each visual component (that might contain logic, if necessary) and require() to fetch a service function.

[Max]

I think you have to add an element to use script even without polymer - the <script> element. 'Element'? 'Tag'? Hrm.
Anyway, with Polymer, you have to add *two* elements, a <link> element and the actual polymer element you want. I wonder if you need to add the polymer element to the body, or can you put script-only polymer elements in the head?

It *is* somehow different though, isn't it...requires a change in thinking which can be a bit painful. Using script only polymer elements *can* help with binding though, which can simplify things.

Max.

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/58da4fe4-caee-4119-b8d9-5e09651aebc9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jan Schreyer]

I concatenate my scripts, so I need to implement a single <script> tag.

Yet, I will try to get comfy with the approach until a better solution comes up from somewhere.

[imos...@gmail.com]

I really hoped integration with other libraries, such as requirejs, would be easily available by now.
I agree with Jan as I do want to use Polymer in my projects but only for handling UI components.
When I implement a large scale BI code which involves many modules requirejs becomes a blessing.

I see no reason why I can't simply use both.

An idea one can try and implement:
By using requirejs plugins one could use HTML imports as a module dependency and add the link tags only when it's relevant.

When optimizing the code using rjs the same polymer elements can be embedded into the module file.

This way optimized polymer elements will be injected into the page using requirejs instead of the HTML imports.

I've seen a few nodejs packages to compile polymer, but I didn't have the chance to try anything yet.