tkps · HackerTrans

Correction to OP: In Polymer, ajax CAN be an element. Or not. You can build whatever elements you want in Polymer (even non-visual utility elements like xhr and localStorage), but it's YOUR job (the developer) to choose the elements that fit in with the goals and architecture of your project.

Equating the fact that Polymer PROVIDES a declarative ajax element with the inevitability that any project you build will be fraught with bad code factoring and memory bloat because you MUST use it is like saying that because jQuery UI provides a Tab View, all of your jQuery UI's will be horrible because you must build them only out of Tab Views. Polymer just provides the sugar for minting your own custom elements, as well as a solid reference set of pre-built elements (core-, paper-); which ones you choose to use is up to you.

Most of this discussion largely misses the point and elegance of what Web Components generally and Polymer specifically are gunning for: The ability to create, reuse, and share well-factored, arbitrary pieces of web functionality (which may or may not include presentation) that have a well-defined imperative API (instance properties, methods) as well as a familiar, serializable declarative syntax (HTML) that can be manipulated imperatively after the fact (DOM), that will (one day, fingers crossed) be consumed natively by all browsers, without today's existing framework-based silos (React components, Angular directives, etc.). When it makes sense in your application (i.e., when you determine you get more use out of factoring it as a reusable element), then promote that functionality to an element; otherwise, you're free to embed that functionality (including ajax requests) as imperative JavaScript inside the component using the techniques you use today.

As for why you might be interested in a declarative <ajax> element: Polymer also provides declarative property binding and templating, which makes this possible (and absurdly simple, and very cool IMO):

    <select value="{{department}}">
      <option value="eng" selected>Engineering</option>
      <option value="sales">Sales</option>
      <option value="hr">Human Resources</option>
    </select>

    <core-ajax url="/{{department}}.json" handleAs="json" response="{{employees}}" auto></core-ajax>

    <template repeat="{{employee in employees}}">
      <div>{{employee.name}}</div>
      <img src="{{employee.avatar}}">
    </template>

Note from the above example: - Completely declarative (no imperative JS required) - No boilerplate querySelectors required - No boilerplate addEventListeners required - Good points for readability and understanding author intent - Are there times where you may need to dynamically create and throw away XHR's based on complex heuristics that don't readily fit into a declarative model like above, or when the maintainability benefits of doing so don't justify whatever (hopefully small) cost there is to instantiating an element and holding it in the DOM while the view is in use vs. using the xhr API imperatively? (rhetorical question: survey says...?) - In those cases, Polymer doesn't force it's opinion on you that in a lot of cases declarative elements can be good. In those cases, make your xhr calls imperatively like you do today, and apply the component model in the vast majority of other cases where it does make sense.

Time will tell how developers apply this new component model, and Polymer is doing a lot of experimentation in the open to try and push those boundaries and see what sticks.

comments