simplajs / simpla

Open, modular, and serverless content management for a modern web
https://www.simplajs.org
MIT License
527 stars 36 forks source link

Add Element Mixin #86

Open bedeoverend opened 6 years ago

bedeoverend commented 6 years ago

Addresses #79

Adds the new ES6 SimplaElement mixin, converted from the ES5 Polymer Behavior at https://github.com/simplaelements/simpla-element-behavior to be a generic mixin for v1 Web Components.

Usage

import SimplaElement from 'simpla/mixins/element';

class SimplaImg extends SimplaElement(HTMLElement) {
    static get simplaConfig() {
      return {
        type: 'Image',
        dataProperties: [ 'src', 'alt' ],
        events: [ 'change' ]
      };
    }
}

Major Changes

class SimplaImg extends SimplaElement(HTMLElement) {
    static get simplaConfig() {
      return {
        type: 'Image',
        dataProperties: [ 'src', 'alt' ],
        events: [ 'change' ]
      };
    }

    updateSimplaBuffer() {
      if (this.src === DEFAULT_SRC) {
        return null;
      }

      return super.updateSimplaBuffer();
    }
}

May need to change the public names it adds - current choices were just from the private names implemented in the old behavior

Also tweaks how readonly / editable interact with one another, essentally the same behaviour I believe, but a little bit more robust

bedeoverend commented 6 years ago

Also should add tests to this branch before this is included in a release, just in the process of converting the old tests, but that can come after this is merged in a new PR. Currently having some issues with using Skate's Jest environment package to enable using customElements in Node.

bedeoverend commented 6 years ago

Oh other note - should we just have all mixins accessible at simpla/mixins? e.g. import { Element } from 'simpla/mixins'

EDIT: Actually probably not, because we're compiling as a UMD (accessible at window.SimplaElement), so it's useful for people to be able to import individual mixins if they're not tree shaking.

madeleineostoja commented 6 years ago

To the last point: yes, once they (and elements) are JS. Then there won't be any reason for them to be UMDs either. But for now yeah separate files and used as globals is the only way.

madeleineostoja commented 6 years ago

Wait sorry just saw this is a JS file now - it should be an HTML import (for deduping), and consumed as a global, so that components themselves don't require build steps just to function.

Again, once everything is JS then bundlers / ES modules take care of it. Until then it's not worth requiring a bundler buildstep on components just for this.

madeleineostoja commented 6 years ago

And yes, we should definitely change the names of those hooks. I still vote for just set and get, or add a suffix if we want to be more verbose

bedeoverend commented 6 years ago

@seaneking would you be able to setup the build for that? Been awhile since I've setup a gulpfile, particularly not with the new version. We'll need that to pipe it into HTML I believe. Unless we just use rollup and literally concat inside a <script>...</script> tag - probably could do that? Means wouldn't need to add in gulp which'd be nice

madeleineostoja commented 6 years ago

Yeah don't see why we'd need gulp just to put it in a HTML file, just bundle it and manually write to a HTML file

madeleineostoja commented 6 years ago

Another thing to consider - if we ship UMD definitions of elements (for simpla-component-loader idea we talked about) as well as ES6 exports, should this still be a global (window.Simpla.Element or something) so that code isn't duped? would really rather not need a buildstep, but then again Simpla itself doesn't ship a proper ES6 module. Maybe this could be part of #74, make a umd dir for current simpla.min.js as well as UMDified adapters, mixins, etc, and make the stuff in the root (and mixins, adapters dirs) proper module exports for bundlers.

bedeoverend commented 6 years ago

So not quite sure I fully understand, as deduping won't be affected by putting into global namespace. But

make a umd dir for current simpla.min.js as well as UMDified adapters, mixins, etc, and make the stuff in the root (and mixins, adapters dirs) proper module exports for bundlers.

I think we should do this. Standard pattern for ES / UMD exports for all entry points we have. For UMDs that also means following a standard naming convention. Will make a note on #74 as more relevant there than here.

madeleineostoja commented 6 years ago

deduping won't be affected by putting into global namespace

Wires crossed, I didn't mean deduping resources in the network sense, I meant that you wouldn't have to pull and rebundle the mixin for every compiled UMD element definition.

UMDs as a general pattern for Simpla core sounds good though 👍 Right now the dist files we have are in a bit of a limbo between the two