Second `source.populate` library call in taxonomy handler overrides previous content

Bug report

• I’ve searched for existing issues
• I’ve checked documentation: https://docs.frontity.org
• I’ve checked community forum: https://community.frontity.org

Describe the expected behavior

The second call to source.populate should add the new data without removing the previous one.

Describe the observed behavior

When the taxonomy handler is used, two calls are made. The first one tries to get the category id from the slug: https://github.com/frontity/frontity/blob/514b9fa393154c797dd70c7db1a373b61b06ba88/packages/wp-source/src/libraries/handlers/taxonomy.ts#L23-L24 Here is how it looks state.source.category[8] after those lines:

{
  id: 8,
  count: 10791,
  description: 'Category description',
  link: '/category-link/',
  name: 'Category name',
  slug: 'category-slug',
  taxonomy: 'category',
  parent: 0,
  meta: [],
  _links: {
    self: [ [Object] ],
    collection: [ [Object] ],
    about: [ [Object] ],
    'wp:post_type': [ [Object] ],
    curies: [ [Object] ]
  }
}

Later another call is made to request the posts of that category: https://github.com/frontity/frontity/blob/514b9fa393154c797dd70c7db1a373b61b06ba88/packages/wp-source/src/libraries/handlers/taxonomy.ts#L33-L46

After those lines state.source.category[8] looks like this:

{
  id: 8,
  link: '/noticias-motor/',
  name: 'Noticias motor',
  slug: 'noticias-motor',
  taxonomy: 'category',
  _links: {
    self: [ [Object] ],
    collection: [ [Object] ],
    about: [ [Object] ],
    'wp:post_type': [ [Object] ],
    curies: [ [Object] ]
  }
}

As you can see some fields have been removed, like description or parent. Therefore I’m forced to call categories/?include=8 again in order to access the description property.

Describe the steps involved to reproduce the problem

1. Insert console logs after each source.populate call in the taxonomy handler to see the output difference.
2. Visit an archive url for the taxonomy handler to be used.

[luisherranz]

Maybe we can use the blocked label here:

• If you move an issue to the blocked column, you also add the blocked label.
• Once someone has “fixed” the block, he/she can remove the blocked label.
• The assignee can move back the issue to in progress once he/she is ready to continue the work.

That way we can look at the blocked column and see the issues that still need something.

[luisherranz]

If we want to avoid re-renders it cannot be a simple merge, it has to be a deep-merge. That means we would need to traverse the object and it will have a performance hit. For that reason, I prefer to do it on-demand with the force: true option.

In terms of UX, users don’t usually want to refresh the content when they navigate to other parts of the site. When users want to see new content, they do so by clicking on a refresh button or swiping down. Those actions are the ones that can have the force: true and the overwrite.

To avoid bugs in the future, I wouldn’t do a deep-merge, I would just overwrite the whole object. We don’t know how people are going to structure their REST API responses. Maybe someone adds or removes fields when certain things happen on their site. If we merge the content, the entity data won’t have the guarantee of being a faithful representation of the latest REST API response.