Something stateful is happening with hooks
Closed this issue · 7 comments
If a unit test runs in isolation, the hooks will not work.
Which version are you on?
0.0.4
— Chris G.
On Fri, Nov 6, 2015 at 5:50 PM, Timothy Baron notifications@github.com
wrote:
Which version are you on?
Reply to this email directly or view it on GitHub:
#7 (comment)
This should work on 0.0.4. Just pushed a test to master demonstrating it. Let's compare notes on Monday.
We've discussed this a few times, and it's happening because this initializer doesn't run unless there's an acceptance test. I've been exploring hacky ways to get this to work, but there's a more elegant solution. Make the ember-hook behavior opt-in. Have the developer include an HookMixin in their component. Thoughts, @pzuraq?
{{input hook="foo"}} still wouldn't work, though. . . .
Here's a wild idea. What if instead of using data-test, we use class/classNames?
If I were to guess, your immediate response would be something to the effect of: "That goes against the whole point of ember-hook, which is to not hook into class names for tests."
Though from another perspective, what ember-hook is trying to provide is non-volatile hooks. It shouldn't matter where they're located, so long as they don't change. We can get that behavior in class names. The hook helper could simply provide a namespace, something like .ember-hook__<my-hook-name>.
The benefit of this approach is that Ember has baked-in support for class name bindings, so we won't need to rely on an initializer. Neither will we have to use a mixin, which as discussed earlier presents challenges around the {{input}} and {{textarea}} helpers. Mixins, as I've just discovered, also don't work well with addon components, unless they independently support ember-hook.
One of the main issues with this approach is readability. We still need to look in a potentially very long list of classNames that may contain the test hook. It can also be in arbitrary order, making thinns even more difficult.
I think we should go the other way. Move back to initializers and figure out a way to inject it into the test environment on every test. It shouldn't be too difficult.