Domain functions that take no input erroring when receiving input

[jakewtaylor]

Hey folks, I love this package so much, but I'm running into a little bit of a hurdle - which may just be me thinking about things the wrong way, but would like to open a discussion on it.

Basically, I seem to frequently have a problem with a DF that isn't expecting any input erroring because it's receiving something.

Take this (contrived) example;

const checkSomething = mdf()(() => someBool());

const getSomething = mdf()(() => getSomethingFromTheDatabase());

const getSomethingElse = mdf()(() => getSomethingElse());

const tryGetSomethingOrSomethingElse = branch(
  checkSomething,
  (canDoIt) => canDoIt
    ? getSomething
    : getSomethingElse,
);

With this code, tryGetSomethingOrSomethingElse always fails, because the boolean response from checkSomething is passed into the next function, and it's expecting undefined! I understand why this is happening, and there's a couple of workarounds;

1. Firstly I tried just adding z.any()/z.unknown() as the schema to the 'get' functions. This works, but seems a little weird having to always specify a schema when the function just isn't expecting any input, it seems a little unergonomic to me.

2. To avoid doing that, what I'm mostly doing is using another DF in the chain to strip out the return, i.e.

   const stripInput = mdf(z.unknown())(async () => undefined);

   and then having my branch do something like this:

   const tryGetSomethingOrSomethingElse = branch(
     checkSomething,
     (canDoIt) => pipe(
       stripInput,
       canDoIt
         ? getSomething
         : getSomethingElse
     ),
   );

   which is working for me, but again, it seems a little unnecessary having to do this.

So my question is kind of twofold;

• Is there a reason that DF's that have no schema can't just accept anything, but ignore it and not pass it into the body? I assume there's good reason for not doing this!
• Is there simply a better way of structuring all of this to avoid the problem entirely?

Thanks again for this package!

[gustavoguichard]

Hi @jakewtaylor thank you for the well written discussion!
I sincerely don't remember out of top of my mind why we've chosen z.undefined as default for input.
I remember there was a reason, but the possibility of not defining an input was added more recently and my code usually already uses z.any oir z.unknown out of the legacy when we had to give some schema to the input regardless. Maybe @diogob knows how to answer it better.

For the second question, in your case I'd probably leverage the currying by applying an unknown input to create my other DFs like so:

const df = mdf(z.unknown())

const getSomething = df(async () => {
  // do something
})

const getSomethingElse = df(async () => {
  // do something else
})

const tryGetSomethingOrSomethingElse = branch(
  checkSomething,
  (canDoIt) => canDoIt ? getSomething : getSomethingElse
);

I hope this helps!

[jakewtaylor]

Ah, I didn't consider making a helper with mdf itself! That's a nice solution, but I think I'm leaning towards @diogob's solution instead as it means I can leave the actual DF's "vanilla", and only need to handle this case when it's a problem.

Thanks!

[diogob]

@jakewtaylor the reason why the default is undefined is because the resulting code is simpler and easier to reason about. Perhaps we could ignore the input but I like to avoid adding conditionals as much as possible. Honestly the solution with stripInput does not look bad to me, it makes the behaviour very explicit to the reader that I enjoy.

On another tangential topic, the original design of the branch combinator was to ensure data flows from left to right just like in a pipe (with a T connection if I may extend the metaphor). So the conditional logic is usually contained in the resolver function. In the example you wrote the conditional is in the initial DF and the result of that logic comes in the pipe.

I see a few other possible approaches:

1. Write the conditional inside a DF using fromSuccess. The code would look like:

const tryGetSomethingOrSomethingElse = 
  mdf()(
    () => fromSuccess(checkSomething)() ? fromSuccess(getSomething)() : fromSuccess(getSomethingElse)() 
  );

2. Create a combinator that calls the branch and applies stripInput for you (in case you need to reuse this pattern). Peusdo-code below:

const branchWithoutPiping = (df: DomainFunction<boolean>, dfFalse: DomainFunction, dfTrue: DomainFunction) =>
branch(
  checkSomething,
  (canDoIt) => pipe(
    stripInput,
    canDoIt
      ? dfTrue
      : dfFalse
  ),
);

[jakewtaylor]

the reason why the default is undefined is because the resulting code is simpler and easier to reason about

Is there somewhere in the code that actually sets the default schema to z.undefined()? If so, would it be an option to tweak it to z.preprocess(() => undefined, z.undefined()) instead, so anything becomes undefined in that case...? I imagine that might have some knock on effects I'm not seeing 😅

I don't really like the look of fromSuccess, I'm not sure why but I'd rather keep everything using the composition. The custom branch method is a good shout, I may go with that - but I agree the stripInput function is pretty clear!

[diogob]

I tried using a default parser that just ignores the input and always resolves to undefined. It only breaks one test where we test precisely for the behaviour we would change.

I also cannot think of a scenario where I want that function to fail since we know beforehand that the input will be discarded.

Moreover the example you have brought us is a useful composition that would become possible. The fact that we are relaxing constraints also makes the change backwards compatible and, therefore, more tempting.

I'll play a bit more with the code and open a new PR unless I find some problematic composition that would become possible.

[diogob]

Also, the code is actually simpler. We are not using zod as the default parser anymore, so we remove a conditional 🎉

[jakewtaylor]

Okay, sounds good! I'll stick my stripInput helper for now, with the hopes of removing it if it gets changed! Thanks @diogob!

[gustavoguichard]

Hey @jakewtaylor , just to ping you here: The new version of this lib - which is now called composable-functions - should work as you expect: if you don't declare schemas for input and environment, parameters will be forwarded into the functions but they will be of type unknown and the functions won't throw a schema error ;)