Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Examples of handling default values #257

Open
mjeffryes opened this issue Jul 31, 2024 · 0 comments
Open

Examples of handling default values #257

mjeffryes opened this issue Jul 31, 2024 · 0 comments
Labels
kind/documentation Improvements or additions to documentation kind/enhancement Improvements or new features

Comments

@mjeffryes
Copy link
Member

Hello!

  • Vote on this issue by adding a 👍 reaction
  • If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

Handling resources that have default values set on the service as a provider author can take some thought. A naive implementation can result in persistent diffs or refresh errors (ie due to the service read returning the explicit defaults which were not present in the inputs). I'm aware of 3 ways to handle defaults:

  1. If the provider itself is supplying the defaults, or knows the values the service will supply, the provider can substitute in the defaults during Check

  2. If the provider has to defer to the service to apply defaults, the provider can suppress diffs (and updates) when the user has left the property unset. This requires the user to explicitly set the value to "go back" to the defaults or set an explicit empty value to clear the field. This can be a confusing UX, but is often used as a way to handle settings that might be controlled by multiple resources. This makes the unset value semantically mean "leave this setting alone".

  3. If don't want unset to mean "leave this setting alone", but you also don't know the value the server will set, you have to resort to hacks. The protocol does not let you see both the old inputs and old state at the same time to be able to distinguish whether a value in the outputs was set by the service or the client previously. It's possible, but risky to work around this limitation either by sneaking side channel information into the checked inputs or relying on the in memory state of the provider being persisted between Check and Diff in order to stash information about the old inputs. (Both of these techniques work to give the Diff access to enough information about old inputs to decide whether the unset field in the new inputs should be sent in an update.)

Because this can be tricky, we should write a small example provider that demonstrates the different options

Affected area/feature

@mjeffryes mjeffryes added documentation kind/documentation Improvements or additions to documentation kind/enhancement Improvements or new features labels Jul 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/documentation Improvements or additions to documentation kind/enhancement Improvements or new features
Projects
None yet
Development

No branches or pull requests

2 participants