Add dynamic type support documentation and considerations (feature PR) #954
Conversation
There was a problem hiding this comment.
I was not sure if we should include some example scenarios on when you should use a dynamic type? Does anyone have a list of those exact scenarios that couldn't be covered by one or more static types?
There was a problem hiding this comment.
There are some Discuss threads in which the suggested solution has been, to this point, to use terraform-plugin-go with muxing in a provider to obtain dynamic type support:
However, I'm not sure if these are cases that we should highlight as being scenarios in which we encourage the usage of dynamic types and values. Interested to hear other opinions on this.
There was a problem hiding this comment.
Open question: Should I update the benefits page in terraform-docs-common for this feature? Do we want to advertise it? 😆
There was a problem hiding this comment.
I'm in favour of adding this feature as a benefit, perhaps with a caveat relating to the extra care that needs to be taken when using dynamic types. Maybe a link through to a page that contains a more complete list of the cases where using dynamic types are warranted and the gotchas that need to be considered when doing so?
There was a problem hiding this comment.
I'm in favour of adding this feature as a benefit, perhaps with a caveat relating to the extra care that needs to be taken when using dynamic types. Maybe a link through to a page that contains a more complete list of the cases where using dynamic types are warranted and the gotchas that need to be considered when doing so?
| In this example, a known dynamic value is created, where the underlying value is a known object value: | ||
|
|
||
| ```go | ||
| elementTypes := map[string]attr.Type{ |
There was a problem hiding this comment.
Is it worth either adding some verbiage here around why a provider developer might want to do this, or linking to another page that provides information around when it makes sense to utilise dynamic types and values?
There was a problem hiding this comment.
There are some Discuss threads in which the suggested solution has been, to this point, to use terraform-plugin-go with muxing in a provider to obtain dynamic type support:
However, I'm not sure if these are cases that we should highlight as being scenarios in which we encourage the usage of dynamic types and values. Interested to hear other opinions on this.
|
|
||
| Practitioner configuration editor integrations, like the Terraform VSCode extension and language server, cannot provide any static information when using dynamic data in configurations. This can result in practitioners using dynamic data in expressions (like [`for`](/terraform/language/expressions/for)) incorrectly that will only error at runtime. | ||
|
|
||
| Given this example, a resource schema defines a top level computed [dynamic attribute](/terraform/plugin/framework/handling-data/attributes/dynamic) named `example_attribute`: |
There was a problem hiding this comment.
Is a separate heading here warranted? Although this is using the example of the usage of for that appears under "Downstream Tooling", perhaps this should appear in a sub-section of examples?
| } | ||
| ``` | ||
|
|
||
| When writing test configurations and debugging provider issues, developers will also want to understand how Terraform represents [complex type literals](/terraform/language/expressions/type-constraints#complex-type-literals). For example, Terraform does not provide any way to directly represent lists, maps, or sets. |
There was a problem hiding this comment.
The linked page provides an excellent level of detail, I'm just wondering whether it might be worth saying something about the relationship between framework types, and the Terraform representation of complex type literals, as the former will likely be familiar to provider developers, but the latter may not be.
| } | ||
| ``` | ||
|
|
||
| Then the exact type must be planned and stored in state during `apply` as a [list](/terraform/plugin/framework/handling-data/types/list) of strings. |
There was a problem hiding this comment.
Perhaps expand this section to say a little more, or provide examples, about the handling/behaviour of Terraform list/tuple, map/object, and framework list, map, object and set types in this regard?
Co-authored-by: Brian Flad <bflad417@gmail.com>
….mdx Co-authored-by: Brian Flad <bflad417@gmail.com>
Co-authored-by: Brian Flad <bflad417@gmail.com>
Co-authored-by: Brian Flad <bflad417@gmail.com>
Co-authored-by: Brian Flad <bflad417@gmail.com>
Co-authored-by: Brian Flad <bflad417@gmail.com>
Co-authored-by: Brian Flad <bflad417@gmail.com>
|
We're going to merge this as an MVP for the docs. Potential benefits and use-cases/recommendations can be added in a follow-up PR |
|
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
This PR is targeting #931 for ease of review/comments