Webiny-js: Headless CMS - File field

[doitadrian]

The last field to implement - the File field.

Before we continue, a note:

• CM => Content Model
• FM => File Manager

Had an additional discussion with @Pavel910 regarding this one, and here is the summary. Basically, in the end, we're not sure if the File field should work directly with FM, or over a File CM entry.

1. Working directly with FM

Basically, when you add a File field onto the CM, and then continue with creating a new CM entry, by clicking on the File field, the File Manager is opened, where you choose (or upload and choose) a file, and basically, in the database, you end up with a simple string - a unique file key (which is returned by the FM).

This is great because it's super simple, it will work. The only problem with it is the fact that if you, for example, had 10 CM entries, all linking to the same file, and if you wanted to change the file on all 10 CM entries, you would have to make the change one-by-one. Which is not the case with the next approach I'm about to explain.

2. Working with File CM entries, which work with the FM

In this approach, we have this additional layer between the CM entry and the FM, and that's the File CM entry.

So, every time you'd want to link an image to a CM entry, we'd show a UI which would, basically, list all File CM entries, where each File CM entry has the file key to which it points to. So, technically, you're not picking a file directly from the FM, but an existing File CM entry. And if you were to upload a new file, a new File CM entry would be created, and that would be selected and end up in the database, a simple ID that references the File CM entry.

This approach would solve the issue mentioned in 1. So, if you had 10 CM entries, and wanted to change an image for each, ASSUMING that they all link to the same File CM entry, you'd be able to open that specific File CM entry, change the image to which it points to, and you would have instant change on all 10 entries.

Which to choose?

Well, that is the question. Implementing the 1st solution would be super easy, and less complicated in terms of how the data would be structured in the database. But then, there's that issue with applying a file change to 10 CM entries, which in the Headless CMSes world maybe presents a significant issue.

If it's a MUST that this field is present in the beta version, that we should definitely go with the 1st solution. If it's not a MUST, then we can research the 10-entries-with-the-same-image issue a bit more, and decide which approach we want to take. As mentioned, if this might be a significant issue for our users, then I guess we won't have any other choice, but to go with the 2nd solution. Which is not a problem, but at the moment, we have other things to think about, and we probably won't be able to squeeze the 2nd solution into the release.

@webiny/webinydevteam @SvenAlHamad

[Pavel910]

@doitadrian Slept this one over and I think I have a simple and future-proof solution. So the idea is to go with 1) approach described in the issue, and let the 2) approach be handled in one of the following ways:

1) create an Asset CM during installation (as a default setup). That CM would have, for example, title, description and file field (which would open FM).

2) let the user create the CM for handling assets himself if he needs the flexibility of replacing 1 image in the CM entry and have it applied to all linked CM entries.

By default we only need to have a file field which renders a file picker (that's what we have everywhere in the system). If user needs more flexibility, he will create a new CM which would serve as an intermediary layer, and our job is to only support the Ref field to link 1 or many referenced entities.

[SvenAlHamad]

I would go for the first solution. The second one won’t have a good UX. In a way replacing 10 images is an edge case, not something that happens often.
Also if needed, can we add a “replace file” option into FM?

[Pavel910]

@SvenAlHamad we've already discussed file replacement back when we worked on FM, and unfortunately it is not an option.

As I mentioned in my comment, if somebody wants to be able to replace files, it's an edge-case, and he can create a separate Asset or whatever CM, and make it an intermediary.

So @doitadrian I guess we've agreed on 1).