Refine Back-End Independence #14
Description
Breaking out this feedback from @arkihillel in #10:
Back-End Independence — Can the component retrieve its content from a variety of a back-end services?
This rule will be practically impossible to enforce in some cases. Take the
<google-map>Polymer element for example. While, in theory, it could support other services, it just wouldn't make sense to bundle them all under the same component
Agreed. I think it's appropriate for a component to depend on a specific backend if that's the entire purpose of the component. The main concern here is to avoid components that depend on a specific service that's incidental to the component's stated purpose.
If the page were rewritten along the following lines, would that help?
✓ Back-End Independence
Does the component avoid unnecessary dependency on a specific back-end service?
Some components are designed to be used only with a specific company or organization's services. A case in point might be the google-map component which renders a map using Google Maps. Since the purpose of the component is to expose that specific back-end service, it's reasonable that the component only works with that service. The component's name clearly expresses that focus/limitation.
However, front-end components that solve more general-purpose problems should ideally support a range of back-end services. If you are creating a rich text editor component and want to offer a way to store and load editing preferences, it's probably best to avoid embedding a dependency on a specific back-end service like Dropbox into your otherwise general-purpose editor. A better solution might be to factor the preference storage aspect into something that permits storing preferences in a variety of services (both public and private), and offer a connector that saves preferences to Dropbox as a separable option.