Find an Optional+Computed design

[paddycarver]

There's a months-old design problem we've been skirting, because we haven't been able to do anything about it, but as we think about 3.0.0, we should come up with a solution.

The problem, in brief, is fields with Optional and Computed set.

Optional means that a user may or may not specify a value.

Computed means that if a value is not set by the user, then whatever is set in state or whatever is returned from the API/provider should be used.

When these are combined, it leads to a weird edge case: the user enters a field, and can no longer remove it. Once the field is removed, it is considered to be unset, and defaults to what is set in state, which can't be overridden. So there's no way to remove a value once set.

Ideally, our solution would make the following four user intents distinguishable:

• Set to a value I specify
• Set specifically to an empty value (0, false, "", etc.)
• Set to whatever the API value is/whatever is in state
• Set to whatever the default API value is

Core has indicated that their recommended solution is to have an Optional field that tracks the user input, and a separate Computed field that tracks what the value is actually set to. This would lead to an explosion of fields and I think is not a workable solution in our case, but it was a design direction proposed so I wanted to surface it.

[rileykarson]

I'd like to add that we should consider the case where we add fields to the provider that users previously managed out of band.

Today, we can mark them O+C meaning we lose drift detection / unsetting values, and users sometimes encounter unexpected behaviour when adding a single element to a list suddenly manages the entire list. Or we can mark them Optional only, causing diffs for users who managed the field out of band.

Today, I'm in preference of the 2nd in the general case but that's largely because marking fields as O+C isn't great. If we can build a stronger strategy for adding new fields, I'd be really happy.

This also ties in heavily to #4327, sub-blocks are the main type of field that I'm concerned about.

[paddycarver]

Agreed, sub-blocks exacerbate this problem a lot, because scalar types (strings, numbers, etc.) can be unset by explicitly setting them to their zero value.

Blocks have no zero value, so they can't be unset. Currently we're getting around that by using a gross hack that lets us continue to use block = [], but that's not going to stick around forever, so we need to find a new solution that is more inline with the type system.

[paddycarver]

We're going to hold on off on this one until we see a new SDK, as mentioned in #4327, because so much of it depends on what the SDK allows us to do.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!