Computed Lists and Maps

[skorfmann]

With the current implementation of computed Lists and Maps we can access single elements (see #31 / #12). What we can't do right now:

• Iterate programatically
• Pass a computed List / Map as input to another Resource / Module

[LumaKernel]

Maybe related: #796

We can't use the technique described in above PR

const awsRoute53RecordExample = new aws.Route53Record(this, "example", {
  allowOverwrite: true,
  name: "${each.value.name}",
  records: ["${each.value.record}"],
  ttl: 60,
  type: "${each.value.type}",
  zoneId: dataAwsRoute53Zone.example.zoneId,
});
awsRoute53RecordAwsRoute53RecordExample.addOverride(
  "for_each",
  `\${{
    for dvo in ${awsAcmCertificateExample.domainValidationOptions} : dvo.domain_name => {
      name   = dvo.resource_record_name
      record = dvo.resource_record_value
      type   = dvo.resource_record_type
    }
  }}`
);

bacause domainValidationOptions is now function. (Finding workaround 😢)
And we don't have any way to know the keys of domainValidationOptions.

To achieve getting the proper interface, we should take care about unawareness of number of items by cdk side (cdk is just a static HCL generator).

That's why we can't use array/map/object for this. Thus I want to suggest iterable like signature.
Writing following to produce the HCL code that we wanted.

awsAcmCertificateExample.domainValidationOptions.entries().map((([_key, value]) => {
  return [value.domainName, {name: value.resourceRecordName, /* ... */}];
})).fromEntries()

Maybe at least what we want are .entries, .map, .fromEntries, and we may have .filter, .flatMap, .concat, ....

In some cases, for example VPC illustrated in #994, we can know the number of items because they may be the identical number of input. We should consider whether to specialize this case, but I think it is not necessary. I think .map is enough for most cases.

Making it dynamic is charming, but it looks hard. I think iterator like interface is good compromise for now.

I believe it's possible solution. If you like this and nobody will implement, I want to tackle implementing this next months.

[LumaKernel]

We can consider special mapper like .mapResource for top-level (non expression).

[jsteinich]

See also #1089 and #1130.

I want to tackle implementing this next months.

That's great. We can certainly work with you to come up with a workable design.
One of the challenges comes from needing to work within the constraints of jsii so that functionality will be available in other languages.

[DanielMSchmidt]

• Replace ComplexComputedList with native array with a single ComplexComputedObject #993 Tracks our move from ComplexComputedLists to Arrays
• Design support for dynamic blocks, iterators, count #1089 Tracks iterating on lists
• feat(lib): Add support for for expressions #1130 is a PR for for expressions
• We implemented Maps already, since everything in this issue seems to be tracked somewhere else I am going to close this one for now. If I am too eager here, please let me know 👍

[github-actions]

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've found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.