Make FieldString handle array of strings

[abovedave]

A field which can have multiple rows of content added

[-] Row 1  
[-] Row 2

[+] Add new row

[abovedave]

Possibly related (ordering): #288

Also #325

[danwdart]

Like multiple reference but for Text then, so implemented presumably as an ["array","of","strings","or","whatever","the","appropriate","data","type","is"]

[danwdart]

What kind of data is within scope here?
[1,2,3], ["a","b","c"],[{"_id":1},{"_id":2},{"_id":3}], {"subdoc":"foo"}, {"subdoc":[1,2,3]}

[danwdart]

Looks like one easy option would be using multiple without options here, rendering an array of textboxes / others https://github.com/dadi/publish/blob/develop/docs/publish-specific-fields.md

I think that that warrants a plus/minus, or maybe a "you pressed enter so we made a new one" / "you pressed backspace so we deleted that option" like in tickbox-based apps

[eduardoboucas]

I've added the blocked label. We're discussing Reference fields in depth tomorrow, will update the ticket with our conclusions.

[eduardoboucas]

In API, a field of type String also accepts an array of strings as a value. Publish can take advantage of this to render a multi-row field as described in the original comment, allowing people to add and remove rows and to change their order, which simply manipulating the array of strings.

In terms of deciding when to render this view over the normal text field, it's easy for existing documents, as we can look at the value and render the multi-row field if the value is an array, and the normal text field if the value is a string.

But what do we do when we're starting a new document? I see a couple of options:

1. We have a property in the publish block that says this field should be rendered as multi-row. We already have similar properties in the publish block that could generate confusion, like multiline. How do we manage these? And what happens if a field is marked for multi-row view but actually contains a string value (instead of array of strings)?

2. We only support this mode when multiline is disabled, which means the field will render a text input and not a textarea. When the user presses Enter, we go into multi-row mode and start adding values to the array.

3. The text field has some UI element to toggle between normal mode and multi-row mode.

Any thoughts?

[eduardoboucas]

(Pinging @abovedave)

[danwdart]

I think that this is a choice made by the schema creator, and shouldn't normally be allowed to be swapped between multiple/single in a tab like 3, because it could necessarily mess up the schema.

2 is probably a new publish block option as I can see wanting both 1 and 2, so maybe:

{"multiple": false, "multiline": false} would render a "single textbox"

{"multiple": false, "multiline": true} would render a "single textarea"

{"multiple": true, "multiline": false} would render a ["textbox 1","textbox 2"]

{"multiple": true, "multiline": true} would render a ["textarea 1","textarea 2"]

[abovedave]

Could it be a whole new field vs modifying the String field? E.g., List?

[eduardoboucas]

Could it be a whole new field vs modifying the String field? E.g., List?

API is not ready for custom fields yet, so it would still need to be {"type": String}, but we could have {"subType": "List"}, or something (see subType).

I have removed the blocked label, as there's nothing stopping development work.

[danwdart]

Would you prefer subtype list to multiple boolean @eduardoboucas ?

[eduardoboucas]

I'm not sure, to be honest. The subType property is used to make the field rendered by a completely different component – i.e. FieldString would not be used at all, and something like FieldStringList would kick in. Doing it as another property inside the publish block, like multiple, means adding the new logic to the existing FieldString component.

I guess the answer is in how much of this logic is shared with the existing component. If it is a lot (and I suspect it might be), it probably makes more sense to not use subType, as long as FieldString doesn't become unmanageable in terms of complexity and all its variations are properly documented.

[anaumovets]

@abovedave , could you please clarify what [+] and [-] should look like exactly. Should these be new UI elements, or do we have them somewhere already (I haven't found anything)? And how should reordering work - drag&drop?
More generally, for this issue and for some others, it'd be great to have a user perspective. An actual scenario when someone is using this components with more or less realistic values.

[abovedave]

FIlters are probably the closest match, if you want to set up the repeatable, ordering etc side I can come in after and tweak the ui? See the 'drag handle' example here

As for a usecase, a list of features is a good place to start e.g., our product pages https://dadi.cloud/en/api/

I'm wondering if it should respect if it's a textarea or input too, for longer sections of copy?

[eduardoboucas]

I'd like to get this moving again. I propose a publish.list property, which indicates to the interface that a field should be rendered as a list.

As for the interface, I imagine something like this, where each line is represented by an input field that can moved around within the list with drag-and-drop.

@ohmoses you can let me and @joverbye know if you need any direction in terms of UI elements.