Schema: optional without {exact: true} about effect HOT 9 CLOSED

@decoursin I agree with your design decision regarding prop?: value over prop?: value | undefined, typescript made a mistake in its initial implementation. But adding utils should be done thoughtfully. Effect already has a massive, MASSIVE api surface, which is much more of a factor for possible newcomers from what we see, the effort is in consolidating and reducing.

If you'll go to the original @effect/schema repo (thats archived) you might find somewhere in its history an api similar to what you're describing. It proved itself to be more confusing with very low ergonomic benefit. Not to me, but I am not the sole consumer of effect.

Theres an assumption in this discussion that exact: true is always the desired behavior despite being not the default in ts. The more you use schema and start to describe .transformations you'll see this can become quite painful unless your api is fully compatible all throughout. Whats more, the decision that this option is cooler than the others is also not based on anything concrete. If anything I would argue that as: "Option" is the coolest one deserving of its own operator (which it had ( which was consolidated)). This is super subjective..

We can go into more depth about the design and why some things work and look like they are if you really wish, though it would be better done in the discord (you're invited ofc <3)

I gave you a more in-depth answer because I feel that you have the impression that you're not being taken seriously or that we are apathetic to your issue so I wanted to explain that even if very few words are spoken here, theres a lot of history you're not privvy to 😅 . I hope this removes a bit of the bitter taste.. 🙏🏻

This is not to say effect will never have a util that will fulfill your use-case, just that currently theres not enough justification why this needs to be in effect and not in userland

from effect.

No I would definitely say the oppositite that you're giving me way more time on this manner than I deserve 😅. Thanks for your elaboration <3. I wasn't aware that there is some a connection to an original design flaw with ts. I still not sure if that would be make it the right decision but it really doesn't matter what I think, and I clearly don't have a comprehensive understanding of the matter 😅. Thanks so much :)

from effect.

and what about the other options of optional? are they not cool enough to have their own schema constructor? 🤔
.optionalAsOption, .optionalNullable, optionalWithDefault, and then all their intersections... .optionalNullableWithDefault etc haha

You can probably just make a userland util for this

const optionalExact = <
  A,
  I,
  R,
  const Options extends {
    readonly default?: never;
    readonly as?: never;
    readonly nullable?: true;
  } | {
    readonly default: () => A;
    readonly as?: never;
    readonly exact?: true;
    readonly nullable?: true;
  } | {
    readonly as: "Option";
    readonly default?: never;
    readonly nullable?: true;
  } | undefined,
>(schema: Schema.Schema<A, I, R>, options?: Options) => Schema.optional(schema, { ...options, exact: true });

from effect.

alternatively, maybe something could be done on the Struct level like how Partial and Required and Mutable work?

from effect.

Haha I really don't think they are cool enough to have their own constructor. I think option with {exact: true} is important and will be used a lot, but the others aren't. But that's just my opinion.

from effect.

Personally, I would have said that {exact: true} should be the default. Because I don't know many APIs sending undefined, most would send null instead. But since you already have optional how it is now, simply adding a new function would be most appropriate IMO.

from effect.

Personally, I would have said that {exact: true} should be the default

You're totally right @decoursin , but we decided that instead of educating everyone to use strict optional we'll be compatible with the common understanding :/
Effect doesn't do global configuration and thats very good, but in this case where you have control over the model all throughout I agree it would be nice.

That said, a Strict constructor may be just as useful? Strict(Struct({...})) or as options on Struct itself? idk, this i hairy, I'm sure gcanti would have a great answer to this

from effect.

A userland util seems to be the simplest and most appropriate solution, moreover defining one's own concept of "optionality" that depends on one's own domain (strict? non strict? including null?) seems advisable in any case.

from effect.

You guys are free to do whatever you want with your library. However, I don't understand why, if you think I'm right, that you wouldn't change it, or add a second function. I think it's important to lower the boundary as much as possible for newcomers by making the original stuff work as expected. But this is just my opinion. I'm not complaining, I'm thankful for your project.

from effect.