is it possible to do this with functional stacks? ...
# help
t
is it possible to do this with functional stacks? I have a stack that’s in an npm package because it’s meant to be reusable in different apps, and it exports a stack class that takes an
sst.Api
as a prop. it seems like with functional stacks any stack with a dependency needs to be aware of the stack that exports the resource it needs instead of just the type of the resource itself
t
You can define a function that returns a function!
but this specifically is an interesting use-case let me think about it a bit
Are you sure your package needs to be a whole stack? Can it just be a function that does operations on a given API?
t
it’s creating some other resources so it needs to be a stack
t
it doesn't necessarily need to be a stack
Copy code
function MyHelper(stack, api) {
   
}

function MyStack(ctx) {
  const api = new Api(...)
  MyHelper(ctx.stack, api)
}
that is one option, if you do feel like it needs to be a standalone stack you can define a function that returns a function
t
so the outer function would take an
ApiStack
function as an argument and return a stack function that uses that as its dependency?
that could work, but it feels like sort of a hacky workaround
t
one option:
Copy code
app
    .stack(ApiStack)
    .stack(MyHelperStack(use(ApiStack).api))

function MyHelperStack(api) {
  return function MyHelperStack(ctx) {
    api
  }
}
another option if you always return api the same way
Copy code
app.
    .stack(ApiStack)
    .stack(MyHelperStack(ApiStack))

function MyHelperStack(stack) {
  return function MyHelperStack(ctx) {
    const { api } = use(stack)
    api
  }
}
but generally I would suggest making sharable things either constructs or pure functions and not stacks
if you made it a construct you could use it like anything else
Copy code
new MyHelperConstruct(stack, "helper", { api })
t
that was mainly for organization so these things wouldn’t be part of the api stack
I don’t think there’s necessarily any reason stacks should be harder to reuse than constructs
t
there's just a trade-off for us, for most use-cases we've seen the functional stack API cover 100% of it + is the simplest design we could come up with. it makes certain more advanced things harder
if you could come up with an API that would support what you're trying to do better than using closures we're definitely eager to consider it