You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, there are a lot of different ways to implement name fields. The two main approaches are:
As an output-only field, with a separate immutable URL param field that gets sent on create
As a read/write field that uses a combination of expanders/flatteners/diff suppression/ignore_read to prevent diffs
Some resources also (incorrectly in some cases? but maybe correctly in others?) mark the field as default_from_api.
We should document what the best practices are.
Based on the results, we may also want to open follow-up tickets to:
Standardize the behavior / configuration of existing resources, to make it more clear to contributors what the best practices are and to make things more likely to behave as users expect
Create a Name field type that behaves in a more standard way
What kind of contribution is this issue about?
MMv1-based resource
Details
Currently, there are a lot of different ways to implement name fields. The two main approaches are:
Some resources also (incorrectly in some cases? but maybe correctly in others?) mark the field as
default_from_api
.We should document what the best practices are.
Based on the results, we may also want to open follow-up tickets to:
References
yaqs/3175428063924060160
Potentially related: #20109
The text was updated successfully, but these errors were encountered: