Why?

To make it easy for front-end developers to create a fully decoupled app without having to write their own integration.

Why polymer?

It works (with polyfill) pretty good across all browsers and most of it can be done by writing only HTML and css.

Example using api-d7 as an example, once GraphQL is ready it can use that as a backend

<link rel="import" href="../bower_components/polymer/polymer.html">
<link rel="import" href="../drupal-app.html">
<link rel="import" href="../drupal-entity.html">

<dom-module id="my-test">
  <template>
    <style include="shared-styles">
      :host {
        display: block;
      }
    </style>

    <div class="card">
      <drupal-app url="https://www.drupal.org/api-d7/"></drupal-app>
      <drupal-entity uuid="2547919" entity-type="node" entity="{{entity}}"></drupal-entity>
      <h2>{{entity.title}}</h2>
      <div>{{entity.body}}></div>
    </div>
  </template>

  <script>
    Polymer({
      is: 'my-test'
    });
  </script>
</dom-module>

Comments

attiks created an issue. See original summary.

cilefen’s picture

I don't know enough about this to speak with authority but does it perhaps qualify for an idea phase? Or, is this a straightforward enhancement?

attiks’s picture

Project: Drupal core » Drupal core ideas
Version: 8.3.x-dev »
Component: rest.module » Idea

#2 You're right, still getting used to the idea

cosmicdreams’s picture

I'm all in for this idea. I think the first step is to convert a pattern library for Drupal into proper components.

The next question is, is there a proper pattern library for Drupal?

cosmicdreams’s picture

And this doesn't really need to be Polymer specific. The main advantage is having a set of reusable components.

Also, what other pattern libraries could be draw from. I've heard many argue for the use of bootstrap-based components in the past. We could consider bringing in selected components are simply start from that base.

attiks’s picture

#4 This issue was meant to build an external SDK so it will be easy to connect to Drupal using REST, I think what you propose is a library inside Drupal, perhaps something like this https://github.com/attiks/cruftless. For the moment all done in the theme, but it's a playground to see how much can be done.

mori’s picture

Ohhhh yessss please. i´m currently starting with polymer and really love it.

yoroy’s picture

Maybe #2645250: [META] Start using reactive declarative JS programming for some new core admin UIs is the more current and active thread around this topic?

cosmicdreams’s picture

I see the road ahead for "Polymer SDK" or more broadly adoption of the Web Components Standards as three separate initiatives:

1. Creating a comprehensive set of Drupal-namespaced components.
2. Make library integration easier
3. A secondary effort to focus on adapting headless Drupal platforms: Contenta / Reservoir

Drupal Components

I've been considering that it might be good to focus on building a set of presentational and structural components that comprises all of the components found in Drupal's administrative UI as a good first step. If you look on Webcomponents.org you'll find that other platforms have started this effort by searching for wordpress- , joomla- , etc. components. The fine folks working out of Penn State already have shown how to setup a library where all the components share the same namespace.

Eventually, we may decide we don't need a specific Drupal-#### component if a community provided component is better / sufficient. From the get-go, folks will be able to swap out what they want to use.

Integrating our various JS efforts

The web components community is gearing up towards adopting ES6 modules for component registration and packaging. Given time, adopting components will be as ordinary as using that standard for other things. So in a sense, yes, focusing on ES6 module adopting throughout Drupal's javascript libraries is a good step

The extra Polymer-y step here would be to use the polymer-cli to generate a metadata file that could then be read by the system to figure out component dependencies, attributions and other things in the metadata. I guess that could be useful?

Data driven elements

Presentational elements are nice but data driven elements can really demonstrate the power of working with web components. Who wouldn't want a set of components that could read Drupal's data and be easily used in any platform. That's one of the goals of Web components.

It might be a fun exercise to make a sample implementation of Contenta like many other sample implementations that are being made for that platform. Then see how much work it would take to adapt it to Reservoir.

attiks’s picture

#9 Part 3 is quite easy and can be done with existing components, I build a small POC at https://github.com/attiks/poc-drupal-issue-list/blob/master/src/test-app... which consists of only 2 components to build something functional that works with a json backend.

Adapting this to work against another json backend is quite easy.