Cannot load Google's jsapi inside of a component #115
Comments
|
Remember that inside of an import (target of <link rel="import"...) we have to simulate parser jobs. In particular, we must use XHR to fetch resources. In any case 'jsapi' is particularly hard to load because it makes a lot of assumptions about where and how it's being loaded. The bottom line is that it's best to load that code directly in your application. This is how we use it in the Pica project. <!DOCTYPE html>
<html>
<head>
<title>Pica</title>
<script src="https://www.google.com/jsapi"></script>
... |
|
That would work, but then there's no way to make a self-contained component that can be dropped in anywhere if it relies on libraries like this. Will support for this be added in the future? |
|
The issue is in 'jsapi' not in toolkit. |
|
Ya. jsapi loads a lot of "crap" on the dom :) I have it working where user has to include a JS file on the page, then all the components that depend on the library will work. I moved all my JS logic into external JS files since it's easier to compile / test. I guess I'd like to also better understand packaging for larger projects. |
This is an area we haven't concentrated on yet. You folks are helping us blaze the trail. =P Maybe you can help identify the biggest areas of concern: Testing? Validation of dependencies? Reuse? Reducing network transactions? Versioning? All of the above? |
|
XD xhr "issue" is filed in HTMLImports: https://github.com/toolkitchen/HTMLImports/issues/1 |
:D that sounds about right. Personally, I'd like to see something similar to requirejs for loading javascript vs using |
|
Technically, HTMLImports gives you a file loader that tracks dependencies. Unfortunately, something needs to bootstrap that into existence first :(. |
|
I think code reuse is important. In my app I have different logic being called from multiple components, so I have JS in it's own file. Also today I can compile that, which is nice. I also have a bunch of html components that I now have to distribute, users have to serve, and include on every page. It would be nice if users could have a single file that included all the dependencies external JS + HTML for a set of components. |
|
(resubmitting this comment as the last one got deformatted by goblins) Web components already provide a lot of these facilities for you. As Daniel points out, the de-duping mechanism allows you to import a dependency in N files without worrying about duplicates. Additionally, imports can often simply be concatenated (certainly definitions can). It's easy to make a 'grunt' task, for example, that builds a single import for an entire collection. Some minor amount of tooling will be needed to 'minify' code inside of imports (I assume this is what you mean by 'compile'), but this is not a difficult problem. Lastly, you can use Custom Elements to provide 'module pattern'. See below how 'my-comp' uses 'my-module' by creating an instance of it, similar to how one might 'require' an interface using some AMD tool. For example, // mymodule.html
<element name="my-module">
<script>
var privateRegistry = {};
this.register({
register: function(inName, inValue) {
privateRegistry[inName] = inValue;
},
byName: function(inName) {
return privateRegistry[inName];
}
})
</script>
</element>
// mycomp.html
<link rel="import" href="my-module.html">
<element name="my-comp">
<script>
var storage = document.createElement('my-module');
this.register({
itemName: ''
work: function() {
this.item = storage.byName(this.itemName);
...
}
})
</script>
</element>Scott |
|
Closing since this issues have been addressed via the discussion here. |
I'm trying to load this script at the top of the html file, outside of the element definition:
which produces this error:
These are the request headers:
Loading the library this way does work, but it causes issues with the api itself:
The text was updated successfully, but these errors were encountered: