feat(relation-widget): Allow the relation widget to target file collections

[d4rekanguok]

Summary

Hello everyone! This PR is a WIP and is meant to facilitate discussion, no hurt feeling if it's rejected.

A few challenges when targeting a file collection:

• Beside the collection name, the widget will also need the file name, and the name of a field in that file (which is very likely a list widget.)
• The widget needs to know if it's dealing with a file collection, a folder collection, or its own entry.
• The widget have to be able to handle a simple array of string and potentially an array of object with different shape (in case of an array produced by a typed list widget).

For the first two, I think we could use dot notation in collection name:

# folder collection
- label: Featured Posts
  name: featuredPosts
  widget: relation
  collection: posts

# file collection
- label: Categories
  name: categories
  widget: relation
  # [collection].[fileName].[fieldName]
  collection: "settings.post.categories"

If collection contains dots, use query as usual; otherwise use loadEntry. Later on, when a user want to target a list widget in the same entry as the relation widget, I think it should be smart and use the new entry props.

Also, I found that query's results are stored in queryHits. I wonder if loadEntry results should be stored in a similar manner?

Please let me know if this is a valid approach!

Test plan

I've written 2 basic tests that covers a simple list & a list of items with the same object shape. Will need a few more.

closes #800

[d4rekanguok]

I fleshed this out a bit more today, adding support for targeting list being nested inside an object! I'm rather fond of overloading collection field, since it allows us to easily differ between file & folder collections. Later on if we decide to allow user to target fields within the same entry, perhaps user can specify some thing like this: collection: "self.fieldName".

I also added a category field to the demo site to test this out visually, and found an issue where loaded options are not being persisted. I think it may have to do with the fact that in a folder-targeting relation widget, the options loaded via query are persisted in the redux store as queryHits[forID], but there's no such thing for loadEntry.

In my custom widget, I persist loaded options in the widget's local state, but it doesn't seem to work here. It's also likely something to do with my code, will look more into it.

[d4rekanguok]

Hhhm I'm a bit stuck here. Intuitively I think it's best to replicate the same structure from folder relation, but even if I want to do so, the function loadEntry passed to widget is no longer a redux action and thus can't send the payload to the global store the same way query can (unless we change that back.)

Another approach I can think of, is to do loadEntry/query upfront in componentDidMount and doesn't rely on value stored in queryHits for the first render.

[erezrokah]

Hi @d4rekanguok, was meaning to comment on this soon (haven't had the time to test my thoughts yet), but I think you can dump loadEntry and use

if (field.has('file')) {
    hits = hits.filter(hit => hit.slug === field.get('file'));
}

Disadvantage it that the CMS will still retrieve all files in the referenced collection, but I think it is a minor issue considering the alternative.

I would actually not overload the collection field since it introduces a new concept. Having an additional file field might be easier to grasp, and using the current valueField to reference the file field might work. Haven't thought of a good way to reference lists yet (maybe categories.*.name).

[d4rekanguok]

Thanks @erezrokah, that makes sense! I'll explore the approach you mentioned.

[erezrokah]

Replaced by #3754