This message was deleted.

In typescript,

Input<T>

is defined as

type Input<T> = T | Promise<T> | Output<T>

Also, if you just want to access a property, then you can let Pulumi lift it for you. For an object

x

of type

{ id: string }

, Pulumi will interpret

x.id

as

x.apply((o) => o.id)

, so you can omit using

apply()

.

@boundless-petabyte-41580 it's just feels odd that you gotta map the input to an output to access the underlying values, but maybe that's just me complaining and it's intended that way?

@most-napkin-55076 the

pulumi.output

is mostly for accessing nested structures. It also coerces every

Input

into

Output

so you have a predictable interface to work with. Theoretically, to stay in input land you could implement something like

function apply<T, T1>(input: Input<T>, f: (t: T) => Input<T1>): Input<T1>

but you'd need path-dependent types, since you don't know if the

input

you're working with has the same monad as

f

Re: it's just feels odd that you gotta map the input to an output to access the underlying values : You don't have to. That's a convenience because the alternative (to access them via Input<>) is harder! So generally, we do. Having a consistent interface like Output can really tidy up code; I'm been known to wrap hardcoded strings (or Promises) in

pulumi.output()

just to force consistency in the code.

I see, I think I start to understand the design choices. The reason is just that we have the

ComponentResource

, that wraps other resources, such as the

Bucket

, as Output, and for me it would just be preferred to not having to unwrap all of the properties of each "child" resource, for then in turn having to pass multiple primitive values around to, potentially, a single resource, as is the case for me, because I have to use multiple properties of a

Bucket

in a separate component. So it's not as much as I can't get it to work, it's more that the way that works, really feels to overcomplicate something that, from the outside at least, is pretty simple., But maybe the way to go is just to map Inputs to Outputs whenever they're reference objects and call it a day?

The ComponentResource can have a Bucket property, it doesn't need to be an Output<Bucket>.

Oh I see. It's because we're using the

initialize()

and

.getData()

to initialize the components, which returns a promise, but I guess that's really not mandatory then? (note, I didn't initially make this, I've just been expanding on it, so a lot of learning still)

I don't know what those are. If you're constructing resources in the normal way, you don't get a Promise.

Those two methods are some implementation for async initialization on resources. It's apperently optional, so not exactly sure when it's actually needed. Line 1029 and 1037 https://github.com/pulumi/pulumi/blob/035a502d86403d815059615a9c047ccccc2cbdd5/sdk/nodejs/resource.ts#L1029C12-L1029C12

Those are specifically for asynchronous data. Resources aren't data, so you won't be initializing them in there. It would be for things like the boot logs of a compute instance (which wouldn't be available until after the resource has been allocated and booted, potentially many minutes after the resource was created).