Expanding on a Riff: PhotoShelter in the Polymer.js community

At PhotoShelter, we take our participation in the open source projects we benefit from very seriously, which is one reason why we are very excited to be part of the burgeoning conversation around Polymer.js v2.0. This new major release will be taking advantage of the v1.0 specifications for Custom Elements and Shadow DOM steadily making their way through the various development channels. We have already started to develop versions of our build tools that target v2.0 in preparation for the transition and are excited to move even further towards using the native web platform as the basis of our features. While participating in that conversation is a high priority, we also realize that v1.0 will still be around for a while, so we continue to take part in the vibrant community developing Polymer Elements. We use many of these elements, so we have a stake in making them great, but we also know that the better the community in general the better

One Polymer Element that we depend on is <iron-list/>, which “displays a virtual, ‘infinite’ list”. Straight off the shelf that supplies an implementer with some really awesome rendering performance when you have the data to populate a list of any size. However, when we looking to apply it to our gallery list pages (which can contain thousands of images), the lack of proper lazy loading strategies was quickly apparent. Luckily, this issue was not unique to our product and the Polymer team released <iron-scroll-threshold/> which allowed for a traditional “infinite scroll” right in the middle of our development schedule. However, for our implementation this approach left a few issues unaddressed. As with any “infinite scroll” the fluidity of the scroll bar profile made it difficult to reason the actual size of a fixed set of images. Loading image by threshold meant that there would be times when data was requesting/processing which would block a visitor’s interaction with the site, meaning, if they knew they were looking for an image closer to the end of the list, they would not be able to get there immediately. Our hope was to be able to deliver a list of items with a fixed scroll profile that displayed tombstone listings for those that had yet to be returned from the server. To that end we updated iron-list with a defaultItem property that allows you initialize items = Array(n) and the defaultItem will be used to populate those array members that are left undefined.

While we have successfully applied this technique to static lists, the concept of virtual lists are applicable in many other situations. Because PhotoShelter helps its members manage their files by structuring them in collections and galleries that mimic the folder structure of an OS, one application we are particularly excited about is the delivery of navigation trees. When delivering data in this way, an interface can expect tombstone elements not only at the beginning and end of a list, but also spliced internally of the list as the user opens successive folder depths. In conjunction with the defaultItem additions to iron-list we will be adding behaviors and wrapper components developed to take advantage of this technique to our open source repository.

We are pleased with the options this presents and are looking into ways to further extend the power of iron-list. Earlier in the year we took part in the conversation, and subsequent PR, around getting the grid view option added to the component. Now we are looking into ways that we can continue to add value through additional PRs and/or our own fork of the project. Specifically we are interested in expanding the layout options available to implementers of the component. Internally, the ability to use iron-list as a vehicle for common natural aspect ratio image layouts like masonry columns or fixed height rows is of high import. Whether that is something that should simply be added to the component as an extended set of options or not is unclear. In the interest of having the broadest number of options and the best possible performance our current avenues of research include a pluggable system of layout types. Thereby PhotoShelter and the community at large could have a simple interface through which to continue to expand the collection of layout types available through the use of iron-list. This lies firmly inline with our goals to continue to expand on the options available to our members as they manage and display assets with PhotoShelter tools.

One of those options is the ability to more simply embed PhotoShelter hosted files in sites not delivered by PhotoShelter. To do this we are making some big changes through the end of the year to our image and video components. On top of simply open-sourcing these solutions, we will be implementing a more holistic system for data management, codifying our build processes, and much more. Stay tuned for a more intimate introduction to those components and the decisions going into their broader distribution soon.

The PhotoShelter Engineering Team is excited to be part of the growing web component community the opportunity to #useThePlatform that comes with it. Checkout our thoughts on a web of components and some of our early steps in converting a ten year old product to them. Also, we are hiring, so if this sounds like the type of community you could get excited by as well, we would love to talk to you about joining our team.