Decorators/hooks

[Rich-Harris]

A feature request that's come up once or twice — the ability to decorate elements with additional functionality, such as lazy loading images. Since 'using decorators' has come to mean 'smothering your code in @ symbols' it's probably no longer a great name. @TehShrike suggested 'hooks' which is pretty good, but this is open to bikeshedding.

Essentially, the idea is that you add a directive to an element and define a hook that gets invoked at runtime:

<div class='tall-element'>...</div>
<img hook:lazyload data-src='giant-photo.jpg'/>

<script>
  import 'intersection-observer'; // polyfill

  // this code is probably wrong, never used IntersectionObserver
  // but you get the gist
  var observer = new IntersectionObserver( entries => {
    entries.forEach( entry => {
      if ( entry.intersectionRatio ) {
        const img = entry.target;
        observer.unobserve( img );
        img.src = img.getAttribute( 'data-src' );
        img.onload = () => img.style.opacity = 1;
      }
    });
  });

  export default {
    hooks: {
      lazyload ( img ) {
        img.style.opacity = 0;
        img.style.transition = 'opacity 0.5s';
        observer.observe( img );

        return {
          destroy () {
            observer.unobserve( img );
          };
        };
      }
    }
  };
</script>

Or, passing data in:

<div hook:tooltip='hello!'>hover on me</div>

<script>
  import Tooltip from 'tooltip';

  export default {
    hooks: {
      tooltip ( node, data ) {
        function handleMouseover () {
          const tooltip = new Tooltip( node, data );

          function handleMouseout () {
            tooltip.remove();
            node.removeEventListener( 'mouseout', handleMouseout );
          }

          node.addEventListener( 'mouseout', handleMouseout );
        }

        node.addEventListener( 'mouseover', handleMouseover );

        return {
          destroy () {
            node.removeEventListener( 'mouseover', handleMouseover );
          };
        };
      }
    }
  };
</script>

Finally, updating data:

<span hook:sparkline='lastTenValues'></span>

<script>
  import Sparkline from 'render-sparkline';

  export default {
    hooks: {
      sparkline ( node, data ) {
        const sparkline = new Sparkline( node, data );

        return {
          update ( data ) {
            sparkline.update( data );
          },
          destroy () {
            sparkline.remove();
          };
        };
      }
    }
  };
</script>

Arguably the last one should be a component instead, but you get the idea.

One design challenge, which the last two examples gloss over: it doesn't feel like it makes sense to force the use of {{delimiters}} here (i.e. hook:sparkline='{{lastTenValues}}'), particularly because you might want to pass in an object and then you have a situation {{{ like: this }}} which just looks awful. But if we stipulate that in the context of this directive, the quotes are the delimiters, then if you want to use text then the second example doesn't really work — it would have to be this instead:

<div hook:tooltip='"hello!"'>hover on me</div>

Not sure if there's a clean way to resolve that.

I don't plan to work on this immediately, I think there are more pressing issues. Just wanted to have a place to discuss this.

[PaulBGD]

Well in the case of

<div hook:tooltip='"hello!"'>hover on me</div>

You do want to pass a string, so it makes sense that you have to declare it. As well if it supports passing multiple parameters, then doing something like

<div hook:tooltop='"hello!", 10'>hover on me</div>

would require you to declare strings.

[evs-chris]

As all bike sheds are meant to be green, I'd say hooks sounds a bit like there's a few predefined entry points that you can inject your own logic. Decorator is a pretty fitting name, but if you want to avoid confusion with proposed ES features, I like traits.

Construct name aside, I quite like <img as:lazyload data-src="giant-photo.jpg" /> and <div as:scrollspy="'myScrollSpyID'">...</div>. Side note: supporting template strings in unquoted expression-y attributes can help reduce quote pileup, since backticks don't quote attributes e.g. <div as:kajigger=string arg>...</div>. Some people with more exotic keyboard layouts have trouble with backticks, but ES has adopted it, so 🤷‍♂️.

It might also be handy to provide a few more lifecycle hooks to decorators. Perhaps a way to adjust the node before it's attached to the DOM. I suppose if the function was called before the node was attached, then a render or attach function would be more appropriate.

[Rich-Harris]

I do like as, yeah. It makes sense. Might pinch that from Ractive! Initially I thought it should align with the property on the exported object literal, and as: {...} looks weird, but then on: matches with events, and if we do transitions then it'll probably be in:fade, out:fade etc, so I'm not sure what I was thinking. 👍 to as. traits: {...} could work too, though possibly also burdened with existing connotations — was wondering about enhancers: {...}.

Backticks are a little tricky for strings with spaces, since syntax highlighters don't know what to make of them:

<div as:kajigger=`string arg`>...</div>

Doesn't look so bad with GitHub's colour scheme but is a bit nuts in my editor. I think @PaulBGD is right, we'd just have to quote strings (and maybe provide a useful error message for invalid expressions, saying 'did you mean to quote that?').

Quite like the simplicity of only having create, (optional) update and destroy. Since it all happens in the same tick, calling the function after the node is mounted to the DOM shouldn't result in any weirdness. But you raise a good point that is fundamental to the design, because if we get this wrong now it would be a difficult thing to undo — should the function be called before the node is mounted, or afterwards? What kind of setup work might need to happen before the node is mounted?

[evs-chris]

enhancers seems to fit nicely. 👍

I think I may have been overthinking the need for a before and after attachment hook. Like you say, as long as whatever changes happen in the same tick as the attachment, you can prevent things like loading a giant image that's supposed to be lazy if you wanted the lazy enhancer to use src rather than data-src. I think the only exception would be script tags, which seem to evaluate immediately when attached, but that's probably far enough off in corner-case land not to matter.

[TehShrike]

Does it seem reasonable to allow decorators to be passed in to the component constructor, instead of always requiring to be imported in the component?

[emirotin]

Was about to suggest enhancers too

As for delimiters how about not having them at all? (Is Ember doing this?)

attr=42
attr='a string'
attr={ an: 'object' }

Is any major case missing? Variables interpolation?

[TehShrike]

I'm a lot softer on this feature now - I'm starting to believe that every single use case that you would use a hook for, you could/should use a component for.

<div class='tall-element'>...</div>
<LazyLoad>
    <img data-src='giant-photo.jpg'/>
</LazyLoad>

<script>
  import LazyLoad from 'lazy-load-component'
  export default {
     components: {
       LazyLoad
    }
  };
</script>

<!-- LazyLoad.html -->
<slot ref:img data-visible="{{visible}}" />

<script>
  import fireWhenReady from 'intersection-observer'
  export default {
    data: {
      visible: false
    }
    oncreate() {
      const img = this.refs.img
      const unsubscribe = fireWhenReady(refs.img, () => {
        img.src = img.getAttribute( 'data-src' )
        this.set({ visible: true })
      })

      this.on('destroy', unsubscribe)
    }
  }
</script>

This depends on #687.

[TehShrike]

The other possible route would depend on #640 (dynamic components), plus the ability to pass around element names as strings in place of components, plus #195 (spread).

<div class='tall-element'>...</div>
<LazyLoad component="img" data-src="giant-photo.jpg" class="my-cool-image" />

<script>
  import LazyLoad from 'lazy-load-component'
  export default {
     components: {
       LazyLoad
    }
  };
</script>

<!-- LazyLoad.html -->
<[component] ref:img data-visible="{{visible}}" {{...this.data}} />

<script>
  import fireWhenReady from 'intersection-observer'
  export default {
    data: {
      visible: false
    }
    oncreate() {
      const img = this.refs.img
      const unsubscribe = fireWhenReady(refs.img, () => {
        img.src = this.get('data-src')
        this.set({ visible: true })
      })

      this.on('destroy', unsubscribe)
    }
  }
</script>

[emilos]

The concept above seems to be really similar to behaviors from backbone.marionette that I've used in the past. The few use cases that I used them for and that they seemed ok for are:

• tooltips (potentially component)
• alerts (potentially component)
• slide (potentially a method)

Benefits:

• small reusable chunks of code (like mixins, decorators, shared code?)

Downsides:

• it's harder to reason about the code (is this handled by a view or a behavior?),
• yet another thing to learn,
• weird use cases arise (e.g. how to hide the tooltip if the user scrolls and where to place that logic)

Imo components are flexible enough for all of the use cases above but maybe someone has better examples