component events don't fire

[optikalefx]

Currently using fastclick with no issues. When I switched to ember-gestures, any components that have an event defined, as in:

export default Component.extend({
   click() { /.../ }
});

don't fire. Double checking with a CSS outline shows I definitely have area to tap on. I tried click and touchend both don't fire. The rest of buttons and a tags do fire.

This is tested on iOS 9, iPhone 6 mobile safari, debugged using desktop safari on mac. Confirmed on 2 different components.

[runspired]

@optikalefx I need to expand the docs apparently :P

This section specifically, if you have a moment: https://github.com/runspired/ember-gestures#using-touch-action-as-a-fastclick

Your component need to bind the style attribute listed there to the string used in the example.

import Ember from 'ember';

const {
  Component
} = Ember;

const {
  SafeString
} = Ember.Handlebars;

export default Component.extend({
   click() { /.../ },

   attributeBindings: ['style', 'disabled', 'type'],
   style: new SafeString('touch-action: manipulation; -ms-touch-action: manipulation;')

});

[runspired]

Added to docs: ad69970

[optikalefx]

That's super lame isn't it? At a minimum I think you should ship a mixin that can be used in a component. I mean every single component in a mobile app that has an event will need this?

[runspired]

@optikalefx ime / imo using click on a component is an antipattern. I considered reopening component to add this automatically if click is present (you can still do that), but tbh just using an AST Walker on a Glimmer component is probably the cleanest path forward, we just have to wait for glimmer components to land. Automatically adding things to attributeBindings is prone to conflicts.

If you want to reopen, do this.

Ember.Component.reopenClass({
  attributeBindings: ['touchActionStyle:style'],
  touchActionStyle: computed(function() {
    return new Ember.Handlebars.SafeString( this.click ? 'touch-action: manipulation; -ms-touch-action: manipulation;' : '' );
  })
});

[optikalefx]

I'm curious to hear what a better pattern for this setup is. The premise is that this component is a back button. inside of a header component. There are 5 header components that are different, and they all use this back button component.

That back button component handles figuring out what page to go back to, IMO a great place to handle back functionality.

If the click is not inside the component, this work would have to be an action on all 5 inclusions of the component and passed the action from something higher up. A much more convoluted setup I think.

[runspired]

@optikalefx that's a complex question with a complicated answer.

Some of the answer is the complexity of jQuery eventing: https://ember-twiddle.com/847601d7383bc60052b4

Some of the answer is the performance hit that you take when you use jQuery eventing, and the second hit you take when you use Ember's event delegation on top of that.

There is currently no good answer to this question, so for now, sticking with click is the way to go. Now that ember-gestures is almost to 0.1 and Hammer 2.0.5 is out, I can focus back on finishing https://github.com/runspired/ember-capture-eventing, which contains one (possibly good, depends on how well the implementation turns out) answer to this question.

[runspired]

@optikalefx the RFC for which the ember-capture-eventing addon is an experimental playground: emberjs/rfcs#86

[runspired]

@optikalefx after thinking about this a little bit more, I think I'm going to do the reopen in 0.0.9, I'll push it up tomorrow morning.

[optikalefx]

Alright, I think at least for now, it's the most expected. Maybe most people don't have components that act on themselves like this, but I think it's useful when it comes up

[optikalefx]

let's keep this open until 0.0.9 is out with that update

[runspired]

0.0.9 is staged and ready, but I'm also locking it to Hammer 2.0.6 which is coming shortly.