#TypeScript SDK Container Field
eternal cobalt
I understand the semantic difference that @func() is creating a getter/setter for that field, and that calling that getter in the constructor is different than calling it on the end of a pipeline. Is the this.daml.container example creating some sort of circular dependency or lazy-init issue that I'm just not seeing?
night raft
I think if you want to use this.daml then you should ignore the generated getter/setters since its not going through the Dagger API. You likely want this.daml.container.withFile() (instead of .container())
eternal cobalt
this.daml.container.withFile() blows up with the withFile is not a function error.
runic beacon
It's because you cannot take as constructor/argument an object of your own module that is exposed to the API
I think the DAG created is missbehaving
Can you add a bunch of debug print to see the content of each objects?
eternal cobalt
I added debug statements in the build function. daml.container is serialized.
I'm assuming that the entire thing is serialized, but the rest of the attributes are effectively strings so it "works".
this.container is an actual Container object.
eternal cobalt
I think this still works, I just have to be careful about field serialization. In this case, the Daml module has context that is useful in other objects (like using a consistent SDK container, the SDK version, other metadata).
eternal cobalt
I can't figure out how this works. Maybe it's a difference between the Go and TypeScript SDKs?
runic beacon
I'm assuming that the entire thing is serialized, but the rest of the attributes...
The field shouldn’t be serialized normally inside your function. Can you share a complete repro so I can identify what’s happening exactly.
Mostly where are you constructing and returning this Archive object