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/64965632-4903-4551-b03c-90e3f24dcbce%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
