Getting errors after updating to Ember 2.8

[RobbieTheWagner]

TypeError: Cannot read property 'currentHandlerInfos' of undefined
    at getRoutes (http://localhost:7357/assets/vendor.js:200596:36)
    at getRouteWithAction (http://localhost:7357/assets/vendor.js:200601:30)
    at Class.compute (http://localhost:7357/assets/vendor.js:200626:33)
    at Object.compute (http://localhost:7357/assets/vendor.js:31074:26)
    at Object.value (http://localhost:7357/assets/vendor.js:31404:27)
    at Object.read (http://localhost:7357/assets/vendor.js:31797:21)
    at Object.getCellOrValue [as default] (http://localhost:7357/assets/vendor.js:26779:39)
    at snapshotAndUpdateTarget (http://localhost:7357/assets/vendor.js:30179:60)
    at createComponent (http://localhost:7357/assets/vendor.js:30138:5)
    at Function.ComponentNodeManager_create [as create] (http://localhost:7357/assets/vendor.js:30027:17)

Not sure exactly what the cause may be.

[RobbieTheWagner]

@poteto @martndemus I think the issue may be related to this router.router.currentHandlerInfos. Perhaps looking up the router is no longer reliable in Ember 2.8?

[ghost]

I'm unable to reproduce this, could you add steps to reproduce?

[RobbieTheWagner]

@martndemus I don't think we are doing anything strange, so could be any number of things making this issue crop up. I'll have to try to throw together a test app.

[blimmer]

This issue was introduced for me in the upgrade to ember-route-action-helper on ember 2.4 LTS. It happens in integration tests where the router is not present.

@martndemus Here is a twiddle that repros the problem.

[RobbieTheWagner]

Thanks @blimmer!

[blimmer]

no problem @rwwagner90 - my workaround is to lock to 1.0.0 for now.

[ghost]

In that case: duplicate of #39.

[RobbieTheWagner]

@blimmer @martndemus why can't we support this?

[ilucin]

@rwwagner90 in theory, components should never be "route dependant" and that's why this shouldn't be supported by the plugin. In practice, we all have components that are specific to the routes because, well, it makes our life easier - controllers are kinda weird.

Although it makes us to do more boilerplate work (manual action bubbling) I agree with @martndemus because it enforces better design and separation of concerns. I guess routable components will help us with this, if they ever land.. :)

[poteto]

For those with this issue, I recommend reverting to version 1.0.0. I bumped #37 to 2.0.0 since I considered it a breaking change.

[RobbieTheWagner]

@ilucin the components are not specific to routes in our use cases. Think of components used across many routes and you have an action on all their parent routes myComponentChanged. You could fire this directly and have each route do different things, still with a generic component, not specific to the route.

[ilucin]

@rwwagner90 I see what you mean, it's a valid use case.

But the thing is, components should never depend on their parent scope/environment. They should receive all dependencies (input) through attrs and fire actions (output) to communicate to outside world - that's how they are decoupled from their parent context. For the same reason, having service injections in components can also be considered a bad practice.

On the other hand, this approach can be harsh and maybe we should make our lives easier and break some of the "rules".

[blimmer]

@ilucin I totally understand where you're coming from, but I think I show a somewhat reasonable use-case here:

#39 (comment)

We often use components to help separate logic from the main route template (or "routeable component") to make each piece easier to work with. For instance, on the comment I linked above, it's a navigation element that's only used on one set of routes whose parent always has the route-action we are firing. It is so, so nice to get rid of all the boilerplate to simply keep handing the action up to escape the component nesting.

[RobbieTheWagner]

I would love to see an option to enable this again or something. With a warning that it goes against the traditional DDAU principles somewhat.

[vasilakisfil]

@blimmer @ilucin can we bring that back ? I don't get it why we need to "enforce" that rule destroying creativity?
Is the alternative to inject all my component's actions all the way down from parent to children components until my component is used? Doesn't that kill the whole point of this extension ?

[erichaus]

Just ran into this while writing integration tests for component with route-action and I agree with @vasilakisfil if we are to pass actions down into the component (the ember way), then it also seems to to make this helper pointless... Personally I find route-action's to serve a purpose in certain cases and make life easier...

thoughts?

[erichaus]

@ilucin

For the same reason, having service injections in components can also be considered a bad practice.

while true, in practice I don't believe most people pass services down into components but rather inject as needed... interesting to consider though