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/0137d819-a45c-4b15-8d6d-ee0fd7276b69%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
