Skip to content

Instantly share code, notes, and snippets.

@jordanyaker
Created July 20, 2016 01:53
Show Gist options
  • Save jordanyaker/2a0f3c9e13e7347aee796bdc970b39eb to your computer and use it in GitHub Desktop.
Save jordanyaker/2a0f3c9e13e7347aee796bdc970b39eb to your computer and use it in GitHub Desktop.
Notes On Polymer

Initial Thoughts

  • Polymer Elements should be able to observe when a data collection changes without multiple instances of the collection being created. For the following example:

example-list would receive notifications about changes to the data collection when elements are added or removed.

  • Polymer Elements should be able to observe when an object in a data collection changes without multiple instances of a collection or the object being created. For the following example:

All instances of elements in both #list1 and #list2 to receive notifications for changes to item.property.

  • Data Collections should contain the logic for data management (i.e., API proxying, storage drivers, etc.). This means that when considering:

The data object should contain all of the properties for actual access and the Polymer element should only be charged with initializing the element as follows:

ready: function() { this.data = new PolymerData.Collection(); }

  • Data Objects should contain the light-weight business logic for the object if necessary. In other words, business-rule-based transformations such as formatting should be contained within the object such as follows:

    DataModel.prototype.setName = function(first, last) { this.first = first; this.last = last; this.fullName = 'some specific format'; };

This results in model-specific behaviors being isolated within the model prototypes that they are relevant to.

  • Polymer Elements should only be concerned with the behaviors and logic necessary to create the user experience they are responsible for.
  • The interface between Polymer Elements and Data Elements should be managed via Callbacks/Promises, Observer/Observables, and simple events (in that order).
  • Object Oriented behaviors (i.e., passing objects as messages) should be avoided in favor of more Functional paradigms.

Second Thoughts

The problem is never whether or not the references are cascading - everything with JS is passed by reference and not by value. This means that unless you're copying the property values (i.e., shallow clone) to a new object, it's always the same object.

It's just a problem of getting the notification chain to be proper.

Updating the properties of a Data Object bound to an element using this.set will create notification up and for the element itself. This, however, will not result in the proper cascading of elements back down to other child elements.

To create the proper cascade of updates from the master element down to all child elements you need to call the collection/path notification methods:

  • this.splice('data', 1 /* start /, 2 / count */)
  • this.set('data.1', {name: 'foo', id: 1234})
  • this.set('data.1.name', 'foo'})

In order for a proper architecture to be formed, Data Model Objects and the Collections they are a part of need to contain functions which have a closure reference to the Polymer Element that they belong to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment