Composite Runtime field UX flow

[mdefazio]

Overview

Composite runtime fields provide the ability to emit child fields from a parent object field. The unique piece from a UX standpoint for this type of field is that the value of the child fields is defined in the script of the parent. While the child fields will appear like any other field from Discover, Lens, etc., modifying the value (and adding/ removing them) will need to be done from the parent script.

Github issues for additional context:
#126247
#99462

Proposals

We have two possible flows for these fields, each with their own pros and cons, that we are currently exploring. This discussion should focus on our desired UX for creating a composite field, modifying the type of a generated field, applying formatting to that field, and then coming back to edit a child field directly.

Option 1: Child fields have their own flyout

For users who just want to modify the formatting of a child field they are working with, this would likely be the expected flow since it's the same as other fields.

Figma.-.Prototype.-.Runtime.Fields_.Composite.Fields.-.24.February.2022.mp4

Option 2: Child field remains within the parent field

For someone who would be modifying the script of the parent field, it might be easier/quicker to keep all related fields quickly accessible from a single place.

Figma.-.Prototype.-.Runtime.Fields_.Composite.Fields.-.24.February.2022.1.mp4

Questions

1. How common would it be to go back to the parent field once my desired child fields are generated?
2. Do we think the relationship between child and parent fields will be known or understood? I would imagine so for someone who wrote the script, but how much so for someone simply referencing the field?

cc/ @ryankeairns @sixstringcode @mattkime

[ryankeairns]

In watching the two videos, I was leaning toward Option 2 as felt easier to understand the relationship. However, wanting to know more about the format options, I tried the existing UI out and came away feeling differently. Why? The existing UIs under the Format section are rather involved and having multiple of those in the same flyout seems untenable.

Personally, I am in favor of Option 1 as it allows us to re-use much of the existing UI while the callout referencing the parent was intuitive, for me. That message could describe why certain fields are disabled (i.e. you need to go to the parent to change the type). This way, all the existing UI for labels and formatting remains the same and is simply reused / we're not adding a bunch more redundant UI to do multiple of these within that nested Set Value section.