Deep analogue of MarkRequired with the skeleton of DeepModify

[xenoterracide]

I would like to be able to provide a structure to DeepRequired like DeepOmit, and I suspect this would be useful to all the Deep nested. The same structure as DeepOmit would work.

type TeacherSimple = DeepRequired<
  Teacher,
  {
    gender: never;
    students: {
      score: never;
    };
  }
>;

[Beraliv]

Hey @xenoterracide!

Thank you for the suggestion! Yeah, it's a good feature that can be implemented

[Beraliv]

I started working on it here – #329

It will take time, so it will be possibly available in the release after the next one

[Beraliv]

I think I will create a separate DeepMarkRequired to not change the simplicity of DeepRequired

[jrnail23]

I'd love this too -- I have this need right now :)

[Beraliv]

@jrnail23 hey! currently, it's a part of the next v10.1 release so it's unlikely to get merged today and be available. But I can have a look at the implementation now. I will come back to you when I have it.

[Beraliv]

After reflecting on the proposal, I've realised that the Filter object-like structure (similar to DeepOmit and DeepPick) would have an obvious disadvantage: it is unclear what properties have to be required: leaves only or all keys included in the filter?

A simple example would be:

// There is a teacher with all required properties
type Teacher = {
  name: string;
  gender: "M" | "F"; // etc
  address: {
    postcode: string;
    city: string;
    street: string;
    apt: string;
  };
};

// Developers have to validate the object from the backend, therefore all properties are marked as optional
type MaybeTeacher = DeepPartial<Teacher>;

// But some of the properties have to be required for business logic, e.g. a city where a teacher lives
type TeacherWithAddress = DeepMarkRequired<
  MaybeTeacher,
  {
    address: {
      city: never;
    };
  }
>;

What is expected to get in TeacherWithAddress?

// 1. Only city is a required property while address will be optional
// {
//   name?: string;
//   gender?: "M" | "F"; // etc
//   address?: { // address is NOT required 🔴
//     postcode?: string;
//     city: string; // city is required 🟢
//     street?: string;
//     apt?: string;
//   };
// }

// 2. Both address and city will be required
// {
//   name?: string;
//   gender?: "M" | "F"; // etc
//   address: { // address is required 🟢
//     postcode?: string;
//     city: string; // city is required 🟢
//     street?: string;
//     apt?: string;
//   };
// }

Because the syntax is ambiguous, it will definitely confuse engineers during development.

One possible workaround is to use true on objects that have to be required, e.g.

type TeacherWithAddress = DeepMarkRequired<
  MaybeTeacher,
  {
    address: true | {
      city: never;
    };
  }
>;

However, I agree that it's not the best syntax

I suggest an alternative syntax with union elements:

type TeacherSimple = DeepMarkRequired<
  MaybeTeacher,
  'address' | 'address.city'
>;

DeepMarkRequired, similarly to MarkRequired will have an autocomplete, meaning address and address.city will be automatically inferred.

@jrnail23 @xenoterracide @DustinJSilk What do you think?

[Beraliv]

Meanwhile, I've improved Paths performance in #409.

This will provide better DX if DeepMarkRequired's alternative syntax meets your requirements

[Beraliv]

@jrnail23 @xenoterracide @DustinJSilk my proposal is implemented in #408

If you'd like to test the solution, please have a look at the TypeScript Playground - https://tsplay.dev/w1qRGw. It's not production-ready yet but I'm happy to experiment with it. Any feedback is welcome!