You are currently browsing the Polymer archives.

Polymer Behaviors in ES6

Friday, March 25th, 2016

Being a typical aspect of Object Oriented Design, inheritance, and mixins, provide the means by which modular reuse patterns can be facilitated within a given system. Similarly, Polymer facilitates code reuse patterns by employing the notion of shared behaviors modules. Let’s take a quick look at how to leverage them in Polymer when using ES6 classes.

Implementing Behaviors

Implementing a Behavior is quite simple, just define an object within a block expression or an IIFE, and expose it via a namespace, or module loader of choice:

some-behaviors.js

Then, include the behavior in a corresponding .html document of the same name so as to allow the behavior to be imported by subsequent elements:

some-behavior.html

Extending Behaviors

After having defined and exposed a given Behavior, the Behavior can then be extended from element classes by defining a behaviors getter / setter as follows:

Once the behavior has been extended, simply import the behavior in the element’s template (or element bundle, etc.) and it is available to the template class:

Try it

Implementing Multiple Behaviors

Similar to individual behaviors, multiple behaviors can also be defined and extended:

first-behavior.js

second-behavior.js

In certain cases, I have found it helpful to group related behaviors together within a new behaviors (array) which bundles the individual behaviors together:

Note: As can be seen in the FourthBehavior, a behavior can also be implemented as an Array of previously defined behaviors.

Extending Multiple Behaviors

As with extending individual behaviors, multiple behaviors can also be extended using a behaviors getter / setter. However, when extending multiple behaviors in ES6, there are syntactic differences which one must take note of. Specifically, the behaviors getter must be implemented as follows:

Try it

And that’s basically all there is to it. Hopefully this article helped outline how Polymer Behaviors can easily be leveraged when implementing elements as ES6 classes. Enjoy.

Property Change Observers in Polymer

Wednesday, January 6th, 2016

When building Web Components the ability to observe property / attribute changes on custom elements and respond to them accordingly can prove quite useful.

Fortunately, Polymer makes this incredibly easy. Let’s take a quick look …
(note, we’ll be using ES6 here)

Single Property Observers

In it’s most basic form, a Single Property Observer can be defined by simply implementing a method and adding it to the property’s observer configuration:

Now, whenever the property changes, Polymer will automatically invoke the observer method; handily passing two arguments: the updated value, and the previous value:

Try it

Pretty cool, right? It gets even better…

Multi-Property Observers

In addition to Single Property Observers, multiple properties can be observed for changes using the observers array:

The observers array is rather self-explanatory: each item is simply a string representation of the method to be invoked with the observed properties specified as arguments:

Try it.

For more information, see multi-property-observers.

Sub-Property Observers

Similar to Multi-Property Observers, sub-properties can be observed as well (e.g. user.username, or user.account.name, etc.). For instance:

Try it

Deep Sub-Property Observers

As with explicit Sub-Property Observers, (n-level) arbitrary sub-properties can be observed using wildcard notation:

Try it.

Both Sub-Property Observers and Deep Sub-Property Observers differ from Single-Property Observers in that a changeRecord is passed to the observer method as opposed to the updated value. A changeRecord is simply an object which contains the following properties (as per the Polymer Docs):

  • changeRecord.path: Path to the property that changed.
  • changeRecord.value: New value of the path that changed.
  • changeRecord.base: The object matching the non-wildcard portion of the path.

It’s important to keep in mind that Sub-Property, and Deep Sub-Property observations can only be made using either property bindings or the set method.

Array Mutation Observers

Complimentary to Single, Multi, Sub, and Deep Property Observers, Polymer provides Array Mutation Observers which allow for observing Array and Array element properties for changes.

This is where the API requires a little getting used to IMHO, and so I would recommend reading the Docs in detail.

That being said, Array Mutation Observers are quite powerful, for example:

Try it.

When observing Arrays, in order for bindings to reflect properly, Polymer’s Array Mutation Methods must be used. This is quite simple in that the API is the same as that of the corresponding Native Array methods, with the only difference being the first argument is the path to the array which is to be modified. For example, rather than: this.items.splice(...) one would simply use: this.splice('items', ...).

Conclusion

Hopefully this simple introduction to Polymer Observers has demonstrated some of the powerful capabilities they provide. Understanding how each can be implemented will certainly simplify the implementation of your custom elements, therefore leveraging them where needed is almost always a good design decision.

Feel free to explore any of the accompanying examples.

Chuck Norris on Polymer

Wednesday, December 16th, 2015

For the past several months I have been evaluating potential frameworks which could facilitate the implementation of context aware Web Components such that each component can be assembled declaratively into recombinant features and higher-level applications. After a focused period of prototyping each candidate framework, Polymer 1.x has proven to be the most effective approach to satisfy these particular design goals, and many others as well.

While I have also been leveraging Angular 2 for implementing self-contained Web Applications which need not be composed outside the scope of the application’s root component / template, the requirement to provide elements which can be arbitrarily composed within an html document declaratively or imperatively independent of using any one particular framework is one which proves somewhat challenging; yet, can easily be satisfied by leveraging Web Components, and Polymer simplifies the process of doing so considerably.

Polymer 1.x

On a high-level, Polymer provides some much welcomed sugaring over the four Web Component specifications; HTML Templates, Shadow DOM, HTML Imports, and Custom Elements, respectively. The higher level abstraction and API offered by Polymer significantly simplifies the process of Web Component development, while reducing the time and effort required to meet both simple and complex use-cases alike.

Features provided out-of-the-box embrace that which developers have come to expect from a modern library or framework, such as one-way and two-way binding annotations, template helpers, a Local and Light DOM API, declarative and imperative event mappings, declared properties with observers and attribute reflection, and much more.

Add to this the growing Catalog of Elements provided by the Polymer Project, a complete Web Component Testing solution via WCT, optimization features such as Vulcanization with tooling support for Gulp, API Documentation components via Iron Component Page (though still pending ES6 Support) concise documentation with easy to use examples, and developers are afforded a rather elegant solution for building high quality, future facing Web Components, today.

In addition, Polymer comes in three specific layers, each of which builds upon the previous lower-level implementation. This allows for a nice level of flexibility in choosing the most appropriate implementation based on your specific needs. Depending on what is required, one can choose from the mirco-implementation for providing basic custom element sugaring, the mini-implementation for more advanced local DOM and life-cycle hooks, and the standard-implementation which provides the full suite of Polymer features.

Given the capabilities Polymer has to offer, as well as the growing number of organizations using Polymer, and some rather interesting applications being built with Polymer, if you haven’t already, I highly recommend given it a try.

Chuck Norris!

So what does any of this have to do Chuck Norris?

Well, nothing actually.

Except, like Chuck Norris, Polymer is cool – very cool, and so after accidentally coming across the ICNCB service, I thought a simple Web Component which displays some comical facts about Chuck Norris could serve as a useful Polymer example.

And so, if you like to laugh a bit while learning something new, feel free to clone the repo over on Github to get familiar with a few of Polymer’s general capabilities, or simply check out the app here and have a few laughs.

Coming up, Chuck Norris on Angular 2 …

Back from the Peripheral

Tuesday, October 20th, 2015

Hello again…

Indeed, a greeting may be appropriate here as it has been quite some time since I have actively blogged which, for all intents and purposes, has been for good reason.

After a decade of continuous blogging with a minimum of at least one (hopefully) informative article per month, I had made a conscious decision to take a step back, re-evaluate, and, on the peripheral, dedicate my otherwise allocated writing time towards focusing on the many aspects of future Web Development.

With that in mind, my time spent has been put to good use, and so, I’ve decided to begin sharing my experiences here more frequently once again; both trivial and non-trivial alike.

The fact is, I miss writing, and outside of day to day writing of general API docs and the occasional technical spec, I haven’t had a dedicated space to share my more subjective, creative thoughts about modern Web Development. Enough about me, though, I’ll get to the point…

Before I delve into the specific topics I plan to discuss, I think it makes sense to first outline an underlying theme which will permeate throughout my future articles. Specifically, I plan to to focus on topics and technologies which I believe will, to a certain extent, transcend the more immediate trends within the Web Development landscape that tend to come and go with the times. I strongly believe it is essential for our community to continue on a path of sustainable growth, and the path of least resistance will more than likely be in our ability to move from library to library, framework to framework, easily and with minimal transition. This is imperative as the rate at which technologies are changing has grown exponentially in the past few years, perhaps no where more so than in the Web Development space. As such, the ability to identify and focus on core underlying concepts, principles and technologies which will remain relevant for some time to come becomes ever more important.

The simple fact is, we need to pay particular attention to what we dedicate our time to learning, and ensure our learning is focused on key aspects that can carry over as each new technology increases in adoption, and then makes way for the next in line.

With that in mind, I plan to focus this space on my findings and most recent experiences with current Web Development technologies of interest, particularly, but not limited to, the recent work of the TC39 Committee, all things ES2015 / ES2016, React / Redux, Webpack, Web Components, Polymer, Angular 2, and the many other complimentary tools and technologies surrounding modern workflows.

So stay tuned, as always, there’s a lot to talk about! Good things to come …