Array with a single, unnamed field

[oranoran]

Say we want to define a field which is a simple array of numbers. Simply [1, 2].

Today, we can try to do this through declaring an array field. But the fields attribute of array requires us to define named fields for the array's object type. So we end up with an array def that looks like this fields: [{name: 'num', type: 'number'}].

We therefore end up with something different than what we wanted, since now:

1. The admin will show the inner field name "num" for each of the elements, which is redundant
2. The resulting document now has [{num: 1}, {num: 2}], instead of just [1,2]

What if as an alternative to the fields property we could define a field property, containing a field definition, but without name or label properties. The definition for the array we want would now be field: {type: 'number'}.

Under this new definition:

1. The admin will not show a field name/label next to each of the element.
2. The resulting document will contain just the single field's value for each of the array elements, so [1, 2] as intended.

Note: The actual problem described here can also be addressed by adding a hasMany property to the number field, and probably also to text. This may actually be a good idea regardless of this discussion. But the proposed solution works also for complex types, which is cool!

[DanRibbens]

This is smart, I can immediatly see the use case here.

I'm in support of implementing an added configuration options for field on the array field type. It makes sense and would be better than the hasMany alternative.

One cautionary note about using this proposed configuration, is that once documents are made using the single field property on an array, it would be difficult to migrate up to an object within fields as compared to using fields from the start. This isn't a deal breaker, in my mind, users should plan their apps for ever expanding requirements (more fields), not less.

Thanks for this @oranoran, we can see how it fits in with other work and if anyone is feeling inspired to submit a PR that would be hugely appreciated!

[jmikrut]

I'm actually going to be the contrarian here and suggest that I prefer the already-established pattern of adding a hasMany option to the Number, Text, Email, etc. fields vs. extending the built-in array field. The array field has a lot of complex logic already to handle nested and repeatable "subdocuments" and modifying its subdocument schema generation would add a lot of spaghetti to the code I think.

Not to mention that being consistent with our hasMany pattern will help developers that have experience with how the select and relationship fields operate as of now. In the simplest terms, what we're suggesting here is identical to how the select field already operates - store multiple values in an array. That pattern is hasMany, so I'd vote to keep it the same for a text field.

Thoughts?

[wherewego-nina]

I am also in need of an ability to add simple arrays that are not select fields. My particular use case is a dynamic select input. I want to allow for multiple selections but since the fields options are fetched dynamically, I will always get an error on submission. Is thehasMany for a text field on the roadmap?

[Stupidism]

What's the status of this topic now?