A details page with descriptions is not always added to the item list page descriptions

[timofeysie]

the Baader-meinhoff Effect, which despite having a details page with descriptions, not of them get added to the item list page descriptions like some of the others that retain them. Also Social Perception, Time Preference, Hostile Media effect an possibly others.

[timofeysie]

Clicking on the Baader-meinhoff Effect in the cognitive bias category item list takes us to the detail page which has the title "frequency illusion" or the url: http://localhost:4200/categories/item-details/cognitive_bias/Q60769209

Previously, this feature worked, at least for a few items, so it remains to be seen if this is a regression, or there are certain items which cause the feature to fail.

The ItemDetailsStore.fetchWikimediaDescriptionFromEndpoint() function calls the next function fetchFirebaseItemAndUpdate(). Inside this function, a comment left starts to make sense as to why this was failing:

  fetchFirebaseItemAndUpdate(subCategory: string, itemLabel: string, description: string) {
    // TODO: would be better to get the sub-category without having the 'scrub' the underscores.
    const scrubbedCategory = subCategory.replace('_', ' ');
   ...

Now I remember this was a temporary hack because I wasn't sure how to match the item detail to the item in the list.

The sub-category is Frequency_illusion The item label is: cognitive_bias

That's a mistake. The label is actually the category. Also, the item in the list is called: Baader–Meinhof effect

At first there seemed to be no current way to reliably get the key in the list except create a new way to send it from the list. But we want the user to be able to share the url, so we really want the details component to be able to get everything it needs from the so-called q-code.

Luckily this might be what we are looking for:

Q60769209:
aliases: {nl: Array(1), en: Array(2), uk: Array(2), ru: Array(1), es: Array(1)}
claims: {P31: Array(3), P138: Array(1)}
descriptions: {ru: {…}, de: {…}}
id: "Q60769209"
labels:
   de: {language: "de", value: "Baader-Meinhof-Phänomen"}
   en: {language: "en", value: "Baader–Meinhof effect"}
...

This will work to fix the problem:

const itemDetails: ItemDetails = response[this.ENTITIES_KEY][_qcode];
const itemListLabelKey = itemDetails.labels[language]['value'];

However, there will be an error if the language does not exist in this result. I can't see at this point, for example with 'en' why that would then lead to a detail page that has no English detail, but it's possible. Wikidata seems pretty patchy, and I recall a situation like this. But now, time to test the other failed items.

Social Perception, Time Preference both work.

Attitude polarization does not. Déformation Professionnelle also does not. The latter shows a CORS error:

Access to XMLHttpRequest at 'https://radiant-springs-38893.herokuapp.com/api/details/en/D%C3%A9formation_professionnelle' from origin 'http://localhost:4200' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

But for now, a commit to mark where we are up to.

[timofeysie]

There are two types of description calls made for each item detail represented by these to functions in the item-details-store.ts file.

fetchDescriptionFromEndpoint() fetchWikimediaDescriptionFromEndpoint()

This one works: /api/detail/D%C3%A9formation_professionnelle/en/false

This one doesn't: /api/details/en/D%C3%A9formation_professionnelle

The second one is a straight description, but the first one is markup. We will need to use the first one as a backup in case the second one fails. Have a think about that.

[timofeysie]

By saving the list only if there are items that exist in the API results, but not the firebase results, we are getting some of the missing descriptions. But not all. Some are returning 404s due to a server related redirect issue.

The update list on firebase line was commented out because it was erasing the existing descriptions. The thing is we only want to save items if they exist from the api result but are not yet in firebase. Right now, since these are paginated views, that's not a problem until say, an item is added to a page at some point, and then possibly that whole page will be reset.

I'm not sure what the solution to this is at this point.