Propagate active property to tail

[TimvdLippe]

This pull request passes the same tests as added in #77, but with almost no breaking changes to existing tests. The only breaking change is actually intentional. Whenever wants to update its data, it checks if the parent is active. If so, it can update the data and become active.

Fixes #110
Closes #77

[kbenjamin]

This is working for me when merged with PolymerElements/app-route:master and it resolves the problem with tail routes I had encountered.

[zinkkrysty]

👍 Any chance of getting this merged soon? 🙏 I simply cannot get routes and subroutes to work properly with observers in my project.

[TimvdLippe]

Given the amount of issues generated each week regarding this issue, will this pull request land any time soon @rictic?

[abdonrd]

Opinions by @rictic? :)

[cdata]

@TimvdLippe In general I think we like this change. I have tried to use this branch in an app, and noticed at least one condition where active is not being updated as expected. I will make a repro.

[cdata]

@TimvdLippe Please consider the following repro case based on this PR: http://output.jsbin.com/paxake

[cdata]

@TimvdLippe After testing this out a little, I think I may disagree with the following design axiom:

Whenever wants to update its data, it checks if the parent is active. If so, it can update the data and become active.

I don't think that a child route should have the ability to activate itself by poking its own data. Could you describe a use case that justifies such behavior?

[TimvdLippe]

@cdata Really glad there is finally a positive response from the team! I will be taking a look at the repro soonTM (when I have time this weekend).

Could you describe a use case that justifies such behavior?

An example usecase is this store page: https://github.com/TimvdLippe/polymer-lazy-application/blob/master/app/store/store-page.html

In this page, we try to update a route using databinding. Whenever you select a category in the paper-dropdown-menu, I expect the url to reflect this property. E.g:

1. Visit localhost:8080/store/Amsterdam
2. Select category clothing
3. Observe that the url changed to localhost:8080/store/Amsterdam/clothing

Without this change, the above workflow does not work. However, an existing workflow does work (and therefore makes it very inconsistent):

1. Visit localhost:8080/store/Amsterdam/
2. Select category clothing
3. Observe that the url changed to localhost:8080/store/Amsterdam/clothing

Note the only difference is the trailing slash after Amsterdam. This is exactly the confusion described in #37. I forgot to link to that issue, so I added it in the description.

[cdata]

I guess the use case sounds fine, but nothing about it seems to require that an inactive route can activate itself via changes to its data. There are other ways to do this, no?

[TimvdLippe]

@cdata Well, whenever the databindings change the route needs to be somehow updated. However, if you do not check for the active property it could suddenly produce incorrect active states on its own.

#77 contains a different solution by considering both foo and foo/ to be the same. Now as @rictic mentioned in #77 (comment) it's a bit more magic and rewrites urls.

This pullrequest solves the same problem as #77, but in a different manner and in my eyes a lot more intuitive. I have tried to come up with a better solution, but was not able to in all the months since #77 was originally opened.

Given the amount of users validating the behavior and the problems it solves, I personally don't think the current design is any magic or counter intuitive.

[cdata]

It's not about magic, but I do think intuitiveness is important. If a route is not active, then the UI that is bound to the data of that route should transitively be not active. So, a user should never need to cause a route to become active by manipulating the route's data.

[cdata]

Just to remind us where we are in the discussion: I think we agree that the active value should propagate down route branches in a different way. My repro case above shows that there is a bug in the current PR in this regard.

Separately, I think we disagree with the design detail that a child route should be able to self-activate via manipulation of its own data. If there is a valid use case here, a working, simplified example would help to push the discussion forward.

[runia1]

@cdata, @rictic, I have a use case that is pretty simple. The documentation for app-route, as well as several write ups, leads developers to believe we can use app-route to delegate out routing of certain parts of the app to their respective owners.

An example would be this:

in app entry point:

<app-route route="{{route}}" pattern="/:page" data="{{routeData}}" tail="{{subroute}}"></app-route>

<neon-animated-pages selected="{{routeData.page}}" attr-for-selected="name" entry-animation="slide-from-left-animation" exit-animation="slide-right-animation">
  <axs-dash name="dash" route="{{subroute}}"></axs-dash>
  <axs-trxns name="trxns" route="{{subroute}}"></axs-trxns>
</neon-animated-pages>

in <axs-trxns>:

<app-route route="{{route}}" pattern="/:id" data="{{routeData}}"></app-route>

    <paper-menu selected="{{routeData.id}}" attr-for-selected="name" style="width: 25%; float: left;">
      <template is="dom-repeat" items="{{trxns}}">
        <paper-item name="{{item.id}}">{{item.item}}</paper-item>
      </template>
    </paper-menu>

    <neon-animated-pages selected="{{routeData.id}}" attr-for-selected="name" entry-animation="slide-from-top-animation" exit-animation="slide-down-animation" style="width: 74%; height: 210px; background-color: white; float: right;">
      <template is="dom-repeat" items="{{trxns}}">
        <div name="{{item.id}}">
          <span>id: {{item.id}} - Item: {{item.item}}</span>
        </div>
      </template>
    </neon-animated-pages>

This should produce the following available urls:

/dash
/trxns (master-detail page with no trxn selected)
/trxns/1 (master-detail with trxn 1 selected and displayed)
/trxns/2
/trxns/3
...

When on the /trxns page, selecting a trxn should set the url to something like /trxns/1. It should be able to activate itself.

Right now this does not work (it doesn't change the url) and is misleading, especially when <app-route> is pitched as a way to delegate routing. How can we delegate routing if sub <app-route>s can't actually change the route?

[TimvdLippe]

@cdata The issue with reactivating should now be fixed. I also reverted the change with activating the route based on data changes as per our Slack discussion.

We discussed the usecase I described and also was pointed out by @runia1 . This usecase will be fixed in a separate PR to not prolonge this PR anymore 😄

[abdonrd]

@e111077 @cdata friendly ping :)

[mercmobily]

I am the guy from #158 ... please have a look at my use case if you have any doubts about the usefulness of this PR!

[christophe-g]

Can we - please - have this PR (submitted on 5th of July) merged into master ?

[vinerz]

Just having a real struggle without this PR. Any news about the merge guys?

[e111077]

Perhaps rename to __deactivate?

If we do end up going to this PR, perhaps we should provide a public resetProperties or clearProperties helper function that clears data and tail. This function not called by __deactivate, so the user can choose the functionality. By changing the path and tail, that should eventually do the same as this other proposed solution.

Thoughts @cdata?

[TimvdLippe]

@e111077 In previous discussions with @rictic we concluded that resetting tail would significantly impact performance of children. Since you reset the tail data, this means that all children will recalculate based on the data. In big applications this results in a waterfall of databinding updates, sometimes resulting in very long frames. This is the exact reason that right now tail is not altered when resetting a route.

I am okay for adding a property to enable/disable this behavior.

[e111077]

Heya, Tim, spoke with Chris on the issue in person about this. I thought that it was a specific use case he was gunning for, but I was mistaken. There is no need to implement that part of my suggestion.

Although, I still believe that __resetPeoperties should be renamed to __deactivate because that seems to be it's main purpose now rather than resetting data, tail, and __matched as it did in it's first implementation.

Thoughts?

[TimvdLippe]

Just having a real struggle without this PR. Any news about the merge guys?

Please note everyone that if you want to, you can use my version for the time being. To do so execute

bower install --save TimvdLippe/app-route#parent-active-propagation

[TimvdLippe]

As this PR was from my fork prior to renaming from carbon-route to app-route, I was unable to push this branch. The same PR is up at #176 with your feedback incoporated.