I've created a Polymer element for rendering markdown which uses the marked.js library. I was wondering, what is the recommended way of loading in its dependencies?
Should I just use a script tag?
<script src="../marked/lib/marked.js"></script>
Or would it be better to put all of my dependencies into an html import and link to that one file. In this case I only have one dependency but I could easily have more.
<!-- in scripts.html -->
<script src="../marked/lib/marked.js"></script>
<script src="../foo/foo.js"></script>
<script src="../bar/bar.js"></script>
<!-- in mark-down.html -->
<link rel="import" href="scripts.html">
Note: These paths assume my element (and its dependencies) are being installed with bower so they should all be siblings in bower_components.
Private resources should be installed in your component folder and used directly. But shared resources, those resources that other components my also want to use (like marked), should be handled as dependencies.
We suggest two conventions for handling shared dependencies:
always use the canonical path which is ../<package-name> (you did this already). Polymer by convention expects a flat-dependency folder (as supported by Bower), so any resource you need must always be on this path.
refer to an import for the shared resource.
In this case,
<script src="../marked/lib/marked.js">
meets the first convention. Your component can depend on marked package and expect it to exist at ../.
The second convention supports sharing. If more than one component in a project uses a script tag to load a library, the library will load multiple times. Imports, on the other hand, are de-duplicated, so you don't have this problem.
For example, if all components load marked the standard way:
<link rel="import" href="../marked-import/marked-import.html">
then you will only ever have one copy of the script loaded.
Additionally, imports allow you to indirect the actual resource. For example, normally marked-import would depend on marked and use a script tag to load the JavaScript. But in fact, any particular project author can modify the local marked-import.html to load the main code from a CDN or from any other location. By indirecting all access through the import, we create a single point of control.
Today, marked and other libraries do not include import files, so we have to fill in those gaps. Additionally, it will require coordination with other components (to have agreement on what the standard import name will be for any particular shared resource). As (and if) these conventions are adopted, such questions will lessen over time.
So, your component installed would look something like this:
/components
/mark-down - depends on marked-import
/marked-import - (controlled by user, can just depend on `../marked`)
/marked
Related
I am developing a web component using Polymer v3, and need to include some custom elements defined in legacy Polymer 2 components in the template HTML of my new component.
Since HTML imports are no longer supported in Polymer 3, what approach should I take to include them? If I was using Polymer 2 I could just add the following in my component's HTML file:
<link rel="import" href="../my-legacy-component.html">
I have tried adding the above link into the template HTML of my component, but it appears that doesn't work. I have also tried various import commands to reference the JS files inside the legacy component directly, but received various inscrutable JS errors so I'm not sure if that is the correct way to go either.
I can't believe there isn't a simple way to do this - would the Polymer team really introduce a new version of the library that is completely incompatible with all the components created using older versions?
Did you try to use polymer-modulizer?
Modulizer performs many different upgrade tasks, like:
Detects which .html files are used as HTML Imports and moves them to .js
Rewrites in HTML to import in JS.
Removes "module wrappers" - IIFEs that scopes your code.
Converts bower.json to package.json, using the corresponding packages on npm.
Converts "namespace references" to the proper JS module import, ie: Polymer.Async.timeOut to timeOut as imported from #polymer/polymer/lib/util/async.
Creates exports for values assigned to namespace referencs. ie, Foo.bar = {...} becomes export const bar = {...}
Rewrites namespace objects - an object with many members intended to be used as a module-like object, to JS modules.
Moves Polymer element templates from HTML into a JS template string.
Removes s if they only contained a template.
Moves other generic HTML in the document into a JS string and creates it when the module runs.
more on github
I have ran into the same problem with the module js-yaml earlier. I don't have enough reputation for a comment yet so I just write it down here.
Run this sudo npm install -g js-yaml -> This will install the missing package for the tool
Then at the root of your project, run modulizer --import-style name --out . -> This will convert your component from Polymer 2 to Polymer 3. The option --import-style name tells the tool to use package name instead of path. --out will make the tool writes those files to the directory.
After that, if no error prompts. Try to serve it with polymer serve --module-resolution=node -> Since we are using node modules now, we have to provide the --module-resolution=node option.
How can I use a different React version with Reagent, Om, Rum, Quiescent or Brutha?
Self answer since this is asked frequently:
First you have to tell Leiningen to exclude the cljsjs/react dependencies:
[rum "0.6.0" :exclusions [[cljsjs/react] [cljsjs/react-dom]]]
If you have other dependencies pulling in cljsjs/react you can use a global exclusion:
:exclusions [[cljsjs/react] [cljsjs/react-dom]]
Next you have to satisfy the compiler since it won't find the namespaces cljsjs.react and cljsjs.react.dom. For this create two files that hold these namespaces in your source directory. For instance
- src/cljsjs/react.cljs
- src/cljsjs/react/dom.cljs
Both only need the namespace declaration and can otherwise be empty (ns cljsjs.react).
Now you can include any React version you'd like manually in your HTML file with a normal <script> tag.
Alternative:
You can also use foreign-libs compiler option.
Polymer dist/ folder has a single html file https://github.com/Polymer/polymer/tree/master/dist with a HTML import and a script tag. Most of the polymer elements doesn't even have a dist folder. Wouldn't it be a good practice to provide a single distribution bundle file like polymer.js and do the same for each polymer element available there?
There are some obvious advantages with this approach:
1. Minimum http requests to get the polymer core or a polymer element.
2. Easy to use for the clients, just include the required element.
Example: Elements that depend on other shared elements,
- shared-element: /webcomponents/font-roboto/roboto.js
- custom-element1: uses shared-element
- custom-element2: uses shared-element
An app using custom-element1 and custom-element2 downloads /webcomponents/font-roboto/roboto.js
only once with a single http request.
<script src="../webcomponents/webcomponentsjs/webcomponents.js"></script>
<script src="../webcomponents/custom-element1/custom-element1.js"></script>
<script src="../webcomponents/custom-element2/custom-element2.js"></script>
PS: the above custom-element1.js does the same thing as custom-element1.html expect that it is convenient to programmatically load and access the component.
I would like to hear from polymer team or other polymer developers/users on the best practices they are following to solve this.
If I'm understanding you correctly, what you want is Vulcanize.
As of the time of this writing, for polymer 1.0, the instructions are:
If you have an input HTML file, elements.html, that uses a number of HTML imports, you can run it through Vulcanize as follows:
vulcanize elements.html -o elements.vulcanized.html
The -o or --output flag will direct the output to a new file called elements.vulcanized.html. If you omit the -o flag, Vulcanize will print the output to stdout, which can be useful if you want to pipe it to another command.
elements.vulcanized.html now contains a version of elements.html with all imports inlined and dependencies flattened. Paths to any URLs are automatically adjusted for the new output location, with the exception of those set in JavaScript.
You can pass additional options to Vulcanize in the form of flags. For a full list of supported flags, see the official Vulcanize documentation.
Here’s the same example from above. The extra flags tell Vulcanize to strip out comments, and to merge external scripts and CSS files into the vulcanized file.
vulcanize -o elements.vulcanized.html elements.html --strip-comments --inline-scripts --inline-css
https://www.polymer-project.org/1.0/tools/optimize-for-production.html
I have a project containing a big package "global" of classes which is designed for Web, I need to share these classes with a new mobile project, but when i add them with :
Properties -> Flex Build Path -> Source path -> Add Folder
they start appearing with index [source path] before the package name, and since them Flash Builder start trowing error messages :
"A file found in a source-path must have the same package structure '', as the definition's package, 'global'."
How can i fix this issue ?
As we've discussed in the comments, I think it would be a better approach to compile your "global" classes into a library (.swc).
You were concerned about loading unnecessary classes: when you link to a library as 'merged', only the classes you use are actually compiled into the main application (and any classes they depend on), so there's no need to worry about that.
As a last argument I also think this is a more flexible approach. A compiled library is easier to reuse and version, so the code can more easily be distributed to other developers on your team.
Rename one of the packages with right click->refactor. Than is should work.
If not you can also try to have your two codes available at the same project, and then you can select which to run in Flash Builder, by right-clicking to that .as or .mxml file, and selecting set as ... (or something like that)
I guess if you will include 'src' fonder instead of 'src/global' that problem will disappear.
I've been banging my head against a wall for this for almost a couple days now and hoping that someone can point me in the right direction.
Working in a very large Flash application, previously in AS2/CS3 I would have a setup like the following:
root.swf
-- modules
---- code_a.swf
---- code_b.swf
-- views
---- view_a.swf
---- view_b.swf
Using _exclude.xml files, I could exclude the classes defined in code_a and code_b from the ouptut .swf of view_a and view_b. root.swf would be responsible for loading the code modules before view_a or view_b, ensuring that class definitions that view_a and view_b depended on existed.
The Problem
We've recently migrated to using Actionscript 3/CS5. *_exclude.xml files no longer exist. To get the same functionality as above, I've tried the following:
My setup now looks something like:
root.swf
-- modules
---- class_a.as
---- class_b.as
-- views
---- view_a.swf
---- view_b.swf
Use mxmlc to compile root.swf, view_a.swf and view_b.swf, passing it -externs option to specify classes that will be loaded externally (the two classes in modules). This ensures that the class is excluded from the compiled swf.
Use compc to compile class_a.as and class_b.as into classes.swf, using -directory=true to access library.swf for external loading.
However, when I try running one of the two view files which depend on classes.swf, I get runtime errors telling me that a class definition is not present.
Current Workaround
I've devised a workaround which I'm currently not happy with as it's backwards to the modular approach that I was previously using:
Rather than loading the code modules, I statically link all class definitions required by child movies into root.swf. When building root.swf, I use the -link-report option of mxmlc to provide a list of included classes. When building child swfs, I can the use -load-externs to ensure that class definitions that already exist will not be included in the compile output.
Is there a way that anyone is aware of to replicate the AS2/_exclude.xml solution that I had using AS3/CS5?
I'd recommend compiling shared libraries to SWCs.
There are other options such as RSLs:
http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf674ba-7fff.html#WS2db454920e96a9e51e63e3d11c0bf69084-7f1e
Hope that helps.