Multiple fields vs One field of each type.

[thisanimus]

Craft 5 supports reusing fields within an entry type, and customizing handles.

In the past I would do this (we'll call this the old pattern):

• Create a text field youtubeUrl
• Create a text field vimeoUrl
• Add both to an entry type.

Now I could potentially (we'll call this the new pattern):

• Create a text field: shortText
• Add one instance of shortText to the entry type and customize the handle to youtubeUrl
• Add another instance of shortText to the entry type and customize the handle to vimeoUrl
  Presumably for large parts of my content model, I could just have one of each type of field; reusing them as needed.

Questions:

1. Is the new pattern good/advisable?
2. Are there some cases when I should favor one pattern over the other?
3. Are there performance gains with either pattern?

[thupsi]

Hi @thisanimus,

IMO the new pattern is very useful since it can help avoid redundancy and keep your field library from getting unnecessarily large. The main thing that you should be wary of is possible future deviations in field requirements.

For example if you later decide that an instance of your shortText field needs a character limit you will have to:

• Define a new field, identical to the old, but with the character limit.
• Add the new field to your layout.
• Copy the value of the old field to the new field, manualy, or via CLI.
• Delete the old field from your layout.

So, it's doable, but not so trivial that you don't think about it, and maybe a bit more complicated for matrix fields and the like. There's been a relevant FR though, that, if/when implemented, should make this a non-issue.

My recommendation for now is to use the new pattern, but be a little conservative when you suspect that there may be changes to instances down the road.

As for performance gains, I don't think there should be a significant difference, but I don't have evidence or the knowledge to offer real advise on this.

[wsydney76]

Revisiting a couple of projects I helped to migrate to Craft 5 long ago, some lessons learned:

Not all query params support field instances, instead they only take the global field id into account: .search('myTextFieldInstance:foo') (#14733) or .relatedTo({element: 4711, field: 'myRelationsFieldInstance'}) will not work as expected and give false positives or no results. See docs

Unfortunately Craft does not support overwriting translation methods/use as search keywords, which in real live leads to global fields like multiLineText_byLanguage_notsearchable. You may or may not find that useful.

If you start with a single site project, and add more languages later, you will have to check all field instances and assign new global fields if different field instances are to receive different translation methods.

Be aware of glitches like described in #15799.

Working on quite complex and constantly evolving projects, we experienced that there is a high probability that field type specific settings will become more individualized in favor of better author experience, leading to more specific global fields. So many things can change: default values, lenghts, min/max values, plain text line count, placeholder texts, size conditions for images, default upload folders, on/off labels, view modes, button labels, sources etc. etc.

My recommendation for now is to use the new pattern, but be a little conservative when you suspect that there may be changes to instances down the road.

In my words: be very conservative, at least until there will be better support for field instances.

PS.
Field values are always stored under their field instance uid in the content column, so I don't see any reason why there should be a difference regarding performance.