You are currently browsing the JavaScript archives.

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 …

Quick Tip: Backbone Collection Validation

Sunday, January 19th, 2014

Often times I find the native Backbone Collection implementation to be lacking when compared to it’s Backbone.Model counterpart. In particular, Collections generally lack in terms of direct integration with a backend persistence layer, as well as the ability to validate models within the context of the collection as a whole.

Fortunately, such short comings can easily be circumvented due to the extensibility of Backbone’s design as a generalized framework. In fact, throughout my experience utilizing Backbone, I can assert that there has yet to be a problem I have come across which I was unable to easily solve by leveraging one of the many Backbone extensions, or, more often than not, by simply overriding Backbone’s default implementation of a given API.

Validating Collections

Perhaps a common use-case for validating a collection of Models can be found when implementing editors which allow for adding multiple entries of a given form section (implemented as separate Views), whereby each section has a one-to-one correlation with an individual model. Rather than invoke validation on models from each individual view, and manage which model’s are in an invalid state from the context of a composite view, it can be quite useful to simply validate the collection from the composite view which, in turn, results in all models being validated and their associated views updating accordingly.

Assuming live validation is not being utilized, validation is likely to occur when the user submits the form. As such, it becomes necessary to validate each model after their views have updated them as a result of the form being submitted. This can be achieved quite easily by implementing an isValid method on the collection which simply invokes isValid on each model within the collection (or optionally, against specific models within the collection). A basic isValid implementation for a Collection is as follows:

As can be seen in the above example, the Collection’s isValid method simply invokes isValid on it’s models. This causes each model to be re-validated which, in turn, results in any invalid models triggering their corresponding invalidation events, allowing for views to automatically display validation indicators, messages, and the like; particularly when leveraging the Backbone.Validation Plugin.

This example serves well to demonstrate that, while Backbone may not provide everything one could ever ask for “out of the box”, it does provide a design which affords developers the ability to quickly, easily, and effectively extend the native framework as needed.

Clearing Web Notifications Permissions in Chrome

Tuesday, December 3rd, 2013

When implementing features which leverage HTML5 Web Notifications, specifically in Chrome, it can be rather convenient to have the ability to clear notification permissions from the host for which the feature is being implemented.

As would be expected, Chrome allows for easily managing any setting; however, one needs to navigate through quite a few of Chrome’s settings in order to locate Web Notification permissions, the path to which being:
Settings > Show advanced settings… > Content Settings > Notifications > Manage Settings…

Navigation of settings can be simplified by using Chrome’s Search box, which allows for quickly navigating to any specific setting:

While Chrome’s settings Search feature is quite useful, it still requires more interactions then desired. Fortunately, there is an even simpler approach for quickly accessing a specific setting, in this case, Notifications.

Simplifying Clearing Web Notification Permissions

Web Notification Settings can be directly accessed for all hosts via the following path:
chrome://settings/contentExceptions#notifications

As with any URL protocol, the above path can be bookmarked, allowing for easy and convenient management of Notifications.

Bookmarking Chrome Settings

While the focus here may be on the topic of managing Web Notification settings, it is important to note that any Chrome setting can be bookmarked as a convenience shortcut for quickly navigating to any given setting. For instance, Chrome’s cache setting can be bookmark at:
chrome://settings/clearBrowserData

Then, commonly used settings can be accessed simply from their respective bookmarks:

Function Modules in RequireJS

Wednesday, October 16th, 2013

Having leveraged RequireJS as part of my preferred client-side web stack for some time now, I find it rather surprising how often I recall various features from the API docs which I have yet to use, and how they may apply to a specific solution I am implementing.

One such feature is the ability to define a module as a function. While at first this may seem a rather basic feature, and indeed it is, there are quite a few practical purposes in which returning a function as a module definition can prove useful.

Function Modules

As one may expect, returning a function as a Module in RequireJS is rather straight-forward. For example, a simple random function can be defined as a module as follows:

Then, the function module can simply be invoked as follows:

Function Modules as Factories

Perhaps a more practical example of implementing a function module is in the context of a Factory Method.

For instance, a function module can be used as a convenient means of creating a specific type of object on a clients behalf based on certain conditions.

Take (an intentionally simple) example of a function module which, given a specific role type, returns a corresponding view implementation (in this example, a Backbone View) for an Editor feature:

Client code can then simply invoke the factory in order to retrieve the appropriate Editor view implementation based on the specified role type:

Defining modules as functions which serve as factory methods can help simplify client code implementations, as the responsibility of determining the type of object to create, configure, etc., can be delegated to a dedicated object; thus allowing for simpler designs which better facilitate code reuse, testing, and maintenance.

As a general rule of thumb, I typically reserve implementing modules as functions for cases in which a package level method would be appropriate, or for factory implementations. However, there are other scenarios in which function modules may apply, and so they are certainly worth noting.

You can fork the above example here.

Fluent APIs and Method Chaining

Thursday, August 1st, 2013

Of the vast catalog of Design Patterns available at our disposal, often times I find it is the simpler, less prominent patterns which are used quite frequently, yet recieve much less recognition; a good example of which being the Method Chaining Pattern.

Method Chaining

The Method Chaining Pattern, as I have come to appreciate it over the years, represents a means of facilitating expressiveness and fluency when used articulately, and mere convenience in it’s less sophisticated use-cases.

Design Considerations

When considering Method Chaining, one should take heed not to simply use the pattern as merely syntactic sugar from which writing fewer lines of code can be achieved; but rather, Method Chaining should be used, perhaps more appropriately, as a means of implementing Fluent APIs which, in turn, allow for writing more concise expressions. By design, such expressions can be written, and thus read, in much the same way as natural language, though they need not be the same from a truly lexical perspective.

The resulting terseness afforded by Method Chaining, while convenient, is in most cases not in-of-itself a reason alone for leveraging the pattern.

Implementation

Method Chaining, when considered purely from an implementation perspective, is perhaps the simplest of all design patterns. It’s basic mandate simply prescribes returning a reference to the object on which a method is being called (in most languages, JavaScript in particular, the this pointer).

Consider the following (intentionally contrived) example:

As can be seen, implementing Method Chaining requires nothing more than simply having methods return a reference to this.

API Simplicity

Method Chaining is typically used when breaking from traditional Command Query Seperation (CQS) principles. The most common example being the merging of both getters (Queries) and setters (Commands). I especially like this technique, as, aside from being very easy to implement, it allows for an API to be used in a more contextual manner from the developers perspective as oppossed to that specified by the API designer’s preconceptions of how the API will be used. For example:

As can be seen, the message method serves as both a getter and setter, allowing users of the API to determine how the method should be invoked based on context, as well as affording developers the convenience of needing only to remember a single method name. This technique is used quite heavily in many JavaScript libraries and has undoubtedly contributed to their success.

We could further expand on this concept by determining a method’s invocation context based on the arguments provided, or the types of specific arguments, thus, in turn, merging various similar methods based on a particular context.

An important design recommendation to consider is that if you are writing an API which violates CQS (which is quite fine IMHO), as always, API consistency is important, thus all getters and setters should be implemented in the same manner.

Fluency

As was mentioned, in most cases, Method Chaining is leveraged to facilitate APIs which are intended to be used fluently (e.g. an Internal DSL). Such implementations typically provide methods which, by themselves, may have little meaning; however, when combined, allow for writing expressions which are self-descibing and make logical sense to users of the API.

For example, consider the way one might describe a Calendrical Event:

Vacation, begins June 21st, ends July 5th, recurs Yearly.

We can easily implement a Fluent API such that the above grammar can be emulated in code as follows:

The same methods can also be chained in different combinations, yet yield the same value:

Given the above example, we could further improve on the fluency of the implementation by adding intermediate methods which can, by themselves, simply serve to aid in readability, or, provide an alternate modifier for chaining:

When implementing Fluent APIs, we can design such that different logical chaining combinations can yield the same result, thus affording users of the API the convenience of determining the most appropriate expressions based on context or personal preference, even grammatically so. Illogical chaining combinations can be handled by either throwing an exception, or they can simply be ignored based on the context of a preceding invocation – though, of course, one should aim to avoid designs which allow for illogical chaining.

The Ubiquitous Example – jQuery

While Method Chaining and Fluent APIs, as with most design patterns, are language agnostic, in the JavaScript world perhaps the most well known implementation is the jQuery API; for example:

In addition to jQuery, there are numerous additional JavaScript Method Chaining and Fluent APIs of note, Jasmine in particular has a very expressive API which aligns excellently with it’s design goals. The various libraries which implement the Promises/A spec also provide very clear and concise Fluent APIs.

Concluding Thoughts

Over the years I have leveraged Method Chaining to facilitate the design of Fluent APIs for various use-cases. The two patterns, when combined, can be especially useful when designing Internal DSLs; either third-party libraries, or APIs specific to a particular business domain.

Pseudo-abstraction in Backbone

Thursday, May 2nd, 2013

As has been mostly disseminated, JavaScript, being a dynamic, prototypal language, affords developers the ability to design outside the rigid confines inherent to statically typed languages. Interestingly, perhaps even somewhat paradoxically, this same flexibility also allows for programmatically simulating specific features commonly found in statically typed languages, if desired.

While JavaScript does not have a traditional type system, nor does it provide traditional constructs by which user defined types are specified, it is still, necessarily so, a common and desirable design goal to implement a system with the notion of classes in order to provide data types which encapsulate domain logic and facilitate reuse; both of which being key design attributes which help mitigate the complexity of large applications.

Nearly all JavaScript MV* frameworks provide such facilities, and do so in a consistent and convenient manner; most of which allowing for practical circumvention of the prototype system almost entirely. It is also worth noting that while most libraries themselves are generally implemented in the succinct and terse, large applications typically call for a more traditional object oriented design, while also being prudent to do so in alignment with the conventions and idioms particular to JavaScript itself.

Abstraction

At times it will be necessary to design a system with reusable abstractions. In fact, it is quite hard to imagine a modern SPA of even marginal complexity as being maintainable without some level of base class functionality.

For instance, it can be particularly useful to implement base Models and Collections which provide general functionality common amongst all Models and Collections; such as the parsing and appropriate routing of service API exceptions to error callbacks, and successful service results to success callbacks, and so forth.

Since such base classes generally do not provide any concrete behaviors themselves (hence the abstraction), they are of considerable value, specifically when reused amongst various large scale, distributed projects; and, from a design perspective, it is often important for one to ensure such classes are only used as intended.

While one can convey the intended usage of a base class easily enough simply by means of comments alone, indicating their usage as such (and that is quite fine if you prefer), it is also just as easy to ensure base classes are only used as intended programmatically by implementing a simple conditional which checks an instance’s constructor against the base class’ constructor function. For example (in the context of backbone, though any framework applies):

Then, one can simply extend the base class, invoking defaults as needed:

Concluding Thoughts

Like many in the JavaScript community, I, too, am of the opinion that JavaScript should not be made to reflect that which is common to other languages simply for the sake of familiarity; but rather, one should be prudent to leverage the flexibility inherent to the language itself, and this example serves as a demonstration of how such flexibility can be utilized to provide what a specific design calls for at the discretion of the developer.