this.store.findFiltered returning unexpected results in Theme Component

dev
1

I’m slightly foxed, but wonder if I’m using this in an unsafe context.

This code is meant to return and populate a property with a list of tagged topics, but it’s returning a much bigger, unfiltered list (ignoring the filter which is the path to a specific tag)

NB This does start to work within an intra-app transition but doesn’t work as expected on reload of the page.

NB #2 I’m fairly sure this is a regression and it’s only started to act oddly recently

Any insights appreciated …

2

So I’ve tried an alternative approach, e.g. from here:

So now my code looks like:

The outcome is the same, a page reload can result in strange results.

3

The Discourse Homepage Feature Component works fine under the same user actions, so I suspect it’s something to do with an uncertain state of the store during the router stage?

I’ll probably move my code out of the route and into a Component.

If that works it will get rid of a lot of unnecessarily complex route overriding in any case.

4

The first “topicList” to be fetched after an initial page load will automatically use the value which was “preloaded” by the server. So, if your theme is calling store.findFiltered before core does, things could get weird.

There were some changes here recently to fix some bugs where the preloaded value wasn’t being used properly, so that might explain the recent regression.

So, workaround is to make your findFiltered call happen after core’s. But… clearly this kind of racing is not by design - we could probably do with some refactoring in core to make this cleaner :eyes:

2 Likes
5

Trying to help in an area where I have perhaps never been helpful before… Would clearing the preload store do the trick? That solved a similar (in my naive view) issue for me recently.

2 Likes
6

I’m not sure of the secondary effects, in terms of performance, but that … is definitely a good workaround for now :rocket:

PreloadStore.reset();

thanks @pfaffman!

1 Like
7

Thanks @David

In that case I might hold off moving this to a Component.

It’s better to adjust the model in the route, no? So if there is a fix on the horizon, I’ll maintain the current code using @pfaffman’s workaround :+1:

3 Likes
8

Yeah that’ll work, but it’ll “undo” the preloading and cause an extra HTTP request. Probably fine, unless you’re dealing with a very high traffic site

2 Likes