Schema: default class field constructors about effect HOT 5 OPEN

@gcanti what's your thought about this? we mentioned a few times the possibility of adding a generic to Schema to represent the type from construction, this can be useful in many other cases such as for example branded types & refinements, being able to have a validating constructor kind of completes the idea of defining types (data models) through schema.

In the very old schema I had one and I have to say it was working kind of fine, given that we are stuffing Schema with params for context it might be the time to evaluate as a more general solution to this specific issue

from effect.

@mikearnaldi Schema classes already carry a constructor generic which is controlled by the property descriptors of the struct schema;

As to validating constructors for branded types & refinements; you already carry the From and To, that is exactly the type of constructor I generally need:

export const addConstructor = <Self extends S.Schema<never, any, any>>(s: Self) => {
  return Object.assign(S.decodeSync(s) as SchemaConstructor<Self>, s)
}
export type SchemaConstructor<Self extends S.Schema<any, any>> = (
  i: S.Schema.From<Self>,
  options?: AST.ParseOptions
) => S.Schema.To<Self>

So I would personally not bother with an I on schemas.

from effect.

@patroza another alternative to consider:

Option 1:

class Person extends Schema.Class<Person>()({
  name: Schema.string,
  createdAt: Schema.Date,
  posts: Schema.array(Schema.string),
}) {
  constructor(data: { name: Person["name"] }) {
    super({ ...data, createdAt: new Date(), posts: [] });
  }
}

const person = new Person({
  name: "Stefan",
});

Option 2:

class Person extends Schema.Class<Person>()({
  name: Schema.string,
  createdAt: Schema.Date,
  posts: Schema.array(Schema.string),
}) {
  static make(data: { name: Person["name"] }) {
    return new Person({
      ...data,
      createdAt: new Date(), //default value
      posts: [], //default value
    });
  }
}

const person = Person.make({
  name: "Stefan",
});

from effect.

@steffanek option 1 breaks the constructor which is used by schema implementation on decode, Arbitrary creation etc, it will always create new date and posts array.

option 2 doesn’t break it but prevents you from supply alternative values. Then agai, it is also nice to have two constructors; the class constructor used for schema purposes and the make constructor for brand new instances.

My suggestions however tick both boxes; you can new up with defaults, or to restore or for copy and change.

from effect.

linked (in top post) naive implementation code updated with some fixes

from effect.