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/fe7922b4-5d14-4b38-b764-ebb28ec807be%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
