Including a loading substate seems to break isActive

[chrism]

Hi, thank you for writing this addon.

It seems great and exactly what I need to be able to do conditional classnames like this example which is really handy for functional CSS, like tailwind.

I've encountered what seems like a bug to me, though, when I include a loading substate.

Assuming I have a simple nested route like this...

// routes
stations.js
stations
│   station.js

// templates
stations.hbs
stations
 │   station.hbs

And in my stations.hbs template I set an active link like this:

<Link @route="stations.station" @model={{station.id}} as |l|>
  <a
    href={{l.href}}
    class="{{if l.isActive "active-class"}}"
    {{on "click" l.transitionTo}}
  >
    {{station.name}}
  </a>
</Link>

Then the active-class is displayed as expected.

But, if I introduce a loading substate like this...

// routes
stations.js
stations
│   station.js

// templates
stations.hbs
stations
 │   loading.hbs
 │   station.hbs

Then the active-class is not displayed once the station route has resolved.

Worth noting that this is, I think, due to Ember Data Storefront as I've noticed that if I use findAll and findRecord methods in the models of the routes, instead of Ember Data Storefront's loadRecords and loadRecord, then it does still work.

But on the other hand using the <LinkTo> component still works as expected whichever approach for loading the model data is used.

<LinkTo @route="stations.station" @model={{station.id}} class="">
  {{station.name}}
</LinkTo>

For the moment I'm going to stick with and some non-functional CSS but if this is something you consider a bug then I'd be happy to try to help resolve it.

Thanks.

[buschtoens]

Yes, I definitely think that this is a bug. Thanks for reporting it!

Worth noting that this is, I think, due to Ember Data Storefront as I've noticed that if I use findAll and findRecord methods in the models of the routes, instead of Ember Data Storefront's loadRecords and loadRecord, then it does still work.

I think this might be because findRecord and findAll potentially resolve immediately, if the records are already in the client's store, whereas the Storefront equivalents always return a Promise, methinks.

Anyhow, I'll try to write a failing test and fix it :)

[buschtoens]

Sorry, that it took me over a year... 😅

But 1.2.0 is out and thanks to @Turbo87 it should fix it! 🚀

[chrism]

no worries @buschtoens just in time to try out on another project!

thanks for letting me know 😄