Hi Daniel, The JS is imported via a 'script' statement in the custom element html file, the css is imported using 'link rel="import"' as described here: https://www.polymer-project.org/1.0/docs/devguide/styling.html (see the shared style and external stylesheets section).
The gulp tasks are nothing special and without the rest of the code to put it into context probably would do more to confuse then help you ;) Rob On Wednesday, 27 April 2016 05:56:14 UTC+1, Daniel Reyes wrote: > > Hey Rob, > > Would you be willing to share the gulp task you have and also how you > import the css and JS files to the markup-file in dev? > > El martes, 8 de marzo de 2016, 13:38:23 (UTC-6), Rob Stone escribió: >> >> Hi Colin, >> >> The unit tests are written using Jasmine, I have a gulp task that runs >> them (using phantomjs) whenever the code is saved in the editor for instant >> feedback. This is something we started doing on a previous project and I >> wanted to make sure we got the same advantages with this new project. I >> mock out the polymer and browser parts of the interface in the test specs, >> this helps keep the tests fairly simple and fast running. >> >> Separating the code from the dom/template/polymer code helps to make the >> logic side of the application much easier to see. I tend to have 3 files in >> each element folder, one containing the mark-up, one the styling and the >> last containing the majority of the JavaScript. Vulcanizing it turns it >> back into a single file so having a large number of files isn't a problem. >> >> The only slight downside to the above approach is a small amount of >> duplication between the Polymer side of the element and the JavaScript >> module, any methods exposed by the element are simply thin wrappers around >> calls into the module. I don't see this as a huge problem though as the >> elements have fairly simple interfaces so it isn't particularly onerous. >> >> Rob >> >> On Tuesday, 8 March 2016 16:30:53 UTC, Colin Cannon wrote: >>> >>> HI Rob, I am interested to hear how you do your unit tests and how >>> splitting the js from the html makes it easier. >>> >>> On Monday, March 7, 2016 at 12:28:30 PM UTC-8, Rob Stone wrote: >>>> >>>> Just looking for some feedback on the approach I am taking for an >>>> application at work. >>>> >>>> The application in question is an administration console for one of our >>>> products, it needs to be easily extendible so that new modules can be >>>> added >>>> in for different parts of the product. >>>> >>>> I'm creating the shell/framework using vanilla JS & Polymer (not using >>>> Material Design as we have our own look and feel). I'm using behaviours to >>>> define the various interfaces that the plugin modules support with each >>>> behaviour having a handler for the registration event that injects it into >>>> the correct part of the shell. >>>> >>>> The shell consists of several elements with a master element acting as >>>> a mediator, I adopted this approach after watching one of the excellent >>>> polyconf videos. >>>> >>>> The plugins are defined as Polymer elements and are loaded dynamically >>>> as each user of the system will have access to potentially different >>>> plugins. >>>> >>>> The framework supports i18n by dynamically loading and injecting >>>> language specific JSON files on start up. >>>> >>>> On the Polymer side, I'm splitting the style and JS into separate files >>>> to try and give a bit more structure than dumping it all in the .html >>>> file, >>>> this primarily helps when explaining the code to non-Polymer fluent devs. >>>> It also allows me to have continuously running unit tests in the dev >>>> environment. I'm planning on using web component tester for integration >>>> level tests as it is a little too heavy weight for unit testing. >>>> >>>> Traditionally we style our apps using LESS, however I've found that CSS >>>> custom properties have removed the need for this. >>>> >>>> The application shell is Vulcanized, and each of the plugin modules are >>>> also Vulcanized. This is giving me nice small file sizes and minimal >>>> network overhead :) >>>> >>>> I deliberately avoided using Polymer Starter Kit, as although it is >>>> great for getting you up and running quickly, I wanted to be able to >>>> investigate different solutions without being too hampered by an existing >>>> framework. >>>> >>>> One of my aims when putting this framework together was to try to keep >>>> as close to 'html as the framework' as possible. Polymer behaviours were >>>> too tempting to ignore as they give a really nice way of defining the >>>> plugin interfaces and I am using Polymer helper methods and data binding. >>>> However compared to the angular/react solutions being used elsewhere in >>>> the >>>> company this application feels far closer to a vanilla JS solution. >>>> >>>> My adhoc testing so far shows that the application performs well across >>>> all the desktop browsers we support (Chrome, Firefox, IE) and Safari on >>>> iPad. >>>> >>>> I'm very satisfied with how easy it has been to produce a robust >>>> solution in a small amount of time using Polymer, it's good to finally be >>>> using it in anger after spending the last year or so playing around with >>>> the technology. It certainly feels production ready to me now and I plan >>>> to >>>> make as much use of it as possible in the future. >>>> >>>> Cheers >>>> Rob >>>> >>>> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/b6b33683-5f0a-4e49-92e3-d40d6235d9ff%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
