link-to assertion fail: property modified twice in a single render

[HenryVonfire]

ember-source: from 3.10.0 to 3.10.2 (I haven't tried with other versions)
ember-engines: from 0.7.2 to 0.8.2

Linking a property from a component or a controller to the @route of a <LinkTo> tag throws an assertion failed:

Assertion Failed: You modified "url" twice on [object Object] in a single render. It was rendered in "component:link-to" and modified in "component:link-to". This was unreliable and slow in Ember 1.x and is no longer supported. See emberjs/ember.js#13948 for more details.

This wasn't an issue in prior versions of ember-engines.

Way to reproduce the error:

• create a new project
• add ember-engines 0.7.2
• create an in-repo-engine
• create an application controller inside the engine
• create a string property with value index (for example test)
• add a link-to component to the application.hbs (angle brackets or not)
• add this.test as route for the link-to component
• run the application

When visiting the application route of the engine, it will throw the exception. I don't know if it can be relevant, but logging the property passed to the link-to component in the devtools, I saw that instead of being just the string index, link-to transforms it into a getter/setter.

[HenryVonfire]

I've tried to research a bit more about this issue and the problem seems to be that, in didReceiveAttrs of link-to-component component, the property route is set twice, one in this component and another one in the parent link-to component.

Since the link-to component of ember-engines extends from the one provided by ember, when calling this._super inside didReceiveAttrs the route property is set twice.

Anyone has an idea of how to fix this? I tried to use scheduleOnce but that doesn't add the engine name in time for the route 😞

Another easy way to test this assertion error is by using the dummy app. Setting a property in the post controller of the ember-blog engine with the name of one of the routes used in the post template (and replacing the hardcode route string with the property) will break almost all the tests for the link-to component.

[buschtoens]

Can you try submitting a PR with a failing test case?

[HenryVonfire]

Done, you can find it here #668

[thec0keman]

Does this need to be bumped up to the main ember repo? Doing multiple sets of a property in didReceiveAttrs shouldn't throw an error like this, so it seems likely there is an undesirable coupling or side-effect here?

[thec0keman]

Looking into ember-router-helpers as a possible workaround... comes with a couple of caveats though:

1. That addon does not seem to support engines, so you have to use fully formed paths (and they generate full-app page loads)

2. Our engines have a lot of link-to's.... so this will be tedious.

The interesting thing is I think this is mostly tied to passing a bound attribute into the path property. So for example, when using the unbound helper to wrap the value:

= link-to (unbound myObject.path)

Then everything works. So it seems like the major issue here is when you pass bound objects into link-to, and ember-engines tries to prefix the engine name.

[mydea]

Just noting this here, we also ran into this and were able to workaround this by passing the argument as readonly:

<LinkTo @route={{readonly this.dynamicRouteName}}>

It's not ideal, but at least it works!

[HenryVonfire]

readonly seems a better alternative in my opinion, since unbound is considered a legacy API and could be deprecated sooner or later.

[elwayman02]

I believe this is fixed now with #735 @rwjblue @HenryVonfire