This message was deleted.
# typescript
s
This message was deleted.
w
Yeah - I think in general there are roughly three steps: 1. Break up into multiple file and just import 2. Move things into functions with arguments for simple abstraction and re-use 3. Turn into components for cleaner inheritance of parent options (providers, aliases, transformations, etc) and for nicer visualization
c
From my experience, I find myself going with #3 usually. 🙂
r
After noticing that I’ll need several inputs (k8sProvider, namespace name, identifiers, urls …) and require some specific order I now went with a ComponentResource which worked pretty straightforward. My approach was passing the (kubernetes) provider in the
args
and constructing some
ComponentResourceOptions
with the said provider in the
provider
field and
parent:this
down to the components for clarity. So I’m also pretty happy with approach #3. Thanks 👍
At first, some simple functions that are imported and executed once looked like the way to go. But when it comes to shared config, passing several basic things (e.g. the provider, the namespace name) in every function and additionally leaking the information in which order things must be run to the caller soon got cumbersome. So for anybody running over this question: I’d go with a ComponentResource as soon as there is some first item I would otherwise have to provide in every function call.