Enterprisey Polymer

127 views
Skip to first unread message

Rob Stone

unread,
Mar 7, 2016, 3:28:30 PM3/7/16
to Polymer
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

Colin Cannon

unread,
Mar 8, 2016, 11:30:53 AM3/8/16
to Polymer
HI Rob,  I am interested to hear how you do your unit tests and how splitting the js from the html makes it easier.

Rob Stone

unread,
Mar 8, 2016, 2:38:23 PM3/8/16
to Polymer
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 

Daniel Reyes

unread,
Apr 27, 2016, 12:56:14 AM4/27/16
to Polymer
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?

Rob Stone

unread,
Apr 27, 2016, 3:00:54 AM4/27/16
to Polymer
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
Reply all
Reply to author
Forward
0 new messages