Closed marcusround closed 3 years ago
pipe
is actually implemented like any other pipe from other functional libraries, and is supposed to function like the upcoming ES6 pipe operator |>
. functions are connected such that each function's output is "piped" to the next function's input. because functions can only have a single return value, i opted to have systems implicitly return world
, and so this is always what is piped to the next system.
however, i have recognized the useful nature of being able to have all initial arguments passed down the pipe. i could introduce another composition function, maybe call it sequence
or something, where all initial input parameters are passed to each function in the composition as you are expecting (instead piping each output to the next input).
however, there are alternative solutions which allow unique function signatures per system.
you can construct pipelines manually:
const pipeline = (...args) => {
systamA(...args)
systamB(...args)
}
const args = [world, dependencyA, dependencyB]
pipeline(...args)
or here is another strategy using pipe:
pipe(
world => systemA(world, ...args),
world => systemB(world, dependencyB),
)
lmk if you have any thoughts on this
I see, I wasn't familiar with pipe
as a concept and misunderstood the intent. I was treating a pipe as just a neat 'package' of systems that I could import at once. Your first code solution looks like it covers my intent and is easy to construct, not sure there's any need to add anything to the library itself.
cool! i'll close this then 🍻
Expected output:
Received output:
Not sure if this is the intended way to use pipes (I understand that to get around this I could add a property to
world
instead) but the fact that the parameter is passed through successfully to the first system, but not any thereafter, is confusing. This led to quite a tricky bug for me (I was passingdeltaTime
down a pipe and was bewildered when refactoring caused it to break)