Interface with several generic types

Question

Interface with several generic types

In an attempt to create a parser that can parse data fields and convert them into a complete form for display purposes, the fields property plays a crucial role. This property will define each field in a JSON data array that the client receives from the url property within the IForm.

An example of the form interface is outlined below:

export interface IForm {
    name: string;
    url: string;
    fields: IField<any>[] // <-- What should be the appropriate type for this?
}

// Additional interfaces defined...

The fields property within IForm can encompass multiple types like IField<string>, IField<number>, etc., depending on the value of the type property in each case, all derived from IField. As a result, it's uncertain whether using <any> is the best approach due to the various data types within the array. How should this be properly defined? Or is it better to avoid generics entirely and resort to using any?

A hypothetical set of data could resemble the following:

let meta: IForm = {
    name: 'employee',
    url: '/api/employee',
    fields: [
        // Sample fields defined..
    ]
}

In relation to this, an employee interface might look like:

export interface IEmployee {
    id: number;
    name: string;
    gender: string;
    active: boolean;
    department: number;
}

How should the interface for IForm be designed to accommodate this structure efficiently?

Thank you

typescript

Answer 1

Answer №1

In light of the aforementioned information, I recommend implementing something along these lines:

type PossibleDataTypes = string | number | boolean; // or any other types you desire

type PossibleFields =
  | IInput<PossibleDataTypes>
  | IOptions<PossibleDataTypes>
  | ICheckbox;

export interface IForm {
  name: string;
  url: string;
  fields: Array<PossibleFields>;
}

This approach specifically defines the array of fields to encompass only the expected field types. You have the flexibility to expand this list as needed.

Additionally, a modification was made as follows:

// Updated from IField<IOptionsList<T>> to simply IOptionsList<T>
export interface IOptions<T> extends IField<T> {
  type: "options";
  options?:
    | IOptionsUrl
    | ReadonlyArray<IOptionsList<T>>
    | ReadonlyArray<string>;
  multiple?: boolean;
}

This change was made due to an inconsistency in your meta variable without it. Moreover, there seems to be a small error in using 'data' instead of 'url' within meta. Whilst defining meta as an IForm is acceptable, widening a variable to IForm may overlook specifics (such as the specific field types being utilized). In case you solely wish to validate that meta aligns with IForm sans broadening it to IForm, employing a helper function like the following is suggested:

const asIForm = <F extends IForm>(f: F) => f;

This can then be employed as shown below:

const meta = asIForm({
  name: "employee",
  url: "/api/employee",
  fields: [
    {
      type: "input",
      name: "id",
      label: "Employee ID",
      default: 0,
      mandatory: true
    },
    {
      type: "options",
      name: "gender",
      label: "Male/Female",
      default: "male",
      options: ["Male", "Female"]
    },
    {
      type: "checkbox",
      name: "active",
      label: "Active",
      default: true
    },
    {
      type: "options",
      name: "department",
      label: "Department",
      default: 0,
      options: {
        url: "/api/departments",
        idField: "id",
        labelField: "name"
      }
    }
  ]
});

With PossibleFields representing a tangible discriminated union, the compiler can subsequently narrow each entry in the field via a type guard, exemplified as follows:

function processForm(form: IForm) {
  for (let field of form.fields) {
    switch (field.type) {
      case "input": {
        // action for input
        break;
      }
      case "checkbox": {
        // action for checkbox
        break;
      }
      case "options": {
        // action for options
        field.options // <-- no error, known to exist
        break;
      }
      default:
        ((x: never) => console.log("WHAT IS" + x))(field); // ensure exhaustive
        // If an error appears here -------------> ~~~~~
        // then you missed a case in the switch statement
    }
  }
}

Wishing you success and hoping this information proves beneficial!

Link to code

Answer 2

In light of the aforementioned information, I recommend implementing something along these lines:

type PossibleDataTypes = string | number | boolean; // or any other types you desire

type PossibleFields =
  | IInput<PossibleDataTypes>
  | IOptions<PossibleDataTypes>
  | ICheckbox;

export interface IForm {
  name: string;
  url: string;
  fields: Array<PossibleFields>;
}

This approach specifically defines the array of fields to encompass only the expected field types. You have the flexibility to expand this list as needed.

Additionally, a modification was made as follows:

// Updated from IField<IOptionsList<T>> to simply IOptionsList<T>
export interface IOptions<T> extends IField<T> {
  type: "options";
  options?:
    | IOptionsUrl
    | ReadonlyArray<IOptionsList<T>>
    | ReadonlyArray<string>;
  multiple?: boolean;
}

This change was made due to an inconsistency in your meta variable without it. Moreover, there seems to be a small error in using 'data' instead of 'url' within meta. Whilst defining meta as an IForm is acceptable, widening a variable to IForm may overlook specifics (such as the specific field types being utilized). In case you solely wish to validate that meta aligns with IForm sans broadening it to IForm, employing a helper function like the following is suggested:

const asIForm = <F extends IForm>(f: F) => f;

This can then be employed as shown below:

const meta = asIForm({
  name: "employee",
  url: "/api/employee",
  fields: [
    {
      type: "input",
      name: "id",
      label: "Employee ID",
      default: 0,
      mandatory: true
    },
    {
      type: "options",
      name: "gender",
      label: "Male/Female",
      default: "male",
      options: ["Male", "Female"]
    },
    {
      type: "checkbox",
      name: "active",
      label: "Active",
      default: true
    },
    {
      type: "options",
      name: "department",
      label: "Department",
      default: 0,
      options: {
        url: "/api/departments",
        idField: "id",
        labelField: "name"
      }
    }
  ]
});

With PossibleFields representing a tangible discriminated union, the compiler can subsequently narrow each entry in the field via a type guard, exemplified as follows:

function processForm(form: IForm) {
  for (let field of form.fields) {
    switch (field.type) {
      case "input": {
        // action for input
        break;
      }
      case "checkbox": {
        // action for checkbox
        break;
      }
      case "options": {
        // action for options
        field.options // <-- no error, known to exist
        break;
      }
      default:
        ((x: never) => console.log("WHAT IS" + x))(field); // ensure exhaustive
        // If an error appears here -------------> ~~~~~
        // then you missed a case in the switch statement
    }
  }
}

Wishing you success and hoping this information proves beneficial!

Link to code

Answer 3

Answer №2

To restrict the types allowed, you can employ a Type Union:

type formType = string | number | boolean | date;
export interface IForm {
  name: string;
  url: string;
  fields: IField<formType>[] // <-- What should be the correct type for this?
}



let form.default = "adsf";     //valid
let form.default = 1;          //valid
let form.default = true;       //valid
let form.default = new date(); //valid
let form.default = null;       //invalid
let form.default = undefined;  //invalid
let form.default = never;      //invalid

Answer 4

To restrict the types allowed, you can employ a Type Union:

type formType = string | number | boolean | date;
export interface IForm {
  name: string;
  url: string;
  fields: IField<formType>[] // <-- What should be the correct type for this?
}



let form.default = "adsf";     //valid
let form.default = 1;          //valid
let form.default = true;       //valid
let form.default = new date(); //valid
let form.default = null;       //invalid
let form.default = undefined;  //invalid
let form.default = never;      //invalid

Interface with several generic types

Answer №1

Answer №2

Similar questions

Ensuring that Vue3 Typescript app focuses on input element within Bootstrap modal upon opening

Accessing the currently operating WS server instance with NodeJS

TS - deduce the specific type of a key value without receiving a union type

Ways to receive one of two variations

Ways to utilize multiple tsconfig files within VS Code

Explaining the union type using a list of data types

Is it not possible to access the width and height of an element using ViewChild, unlike what is suggested in other responses

Organize nested tuples and maintain their sequence

Is searching for duplicate entries in an array using a specific key?

Challenges with variable scopes and passing variables in Ionic 2 (Typescript)

Error in vue3 with typescript: unable to assign a ComputeRef<number[]> argument to an iterable<number> in d3.js

Tips for Sending Specific Row Information to Server in Ionic 3

How to Send Data with NodeJS by Utilizing the Finish Event

Invoke the built-in matcher within a Playwright custom matcher

Is it considered appropriate to return null in a didReceiveResponse callback function?

A step-by-step guide on bundling a TypeScript Language Server Extensions LSP using WebPack

Cannot assign an array of Typescript type Never[] to an array of objects

Best practice for importing pipeable RxJs operators in Angular CLI/WebPack rollup

Place the setState function within the useEffect hook

Preventing going back to a previous step or disabling a step within the CDK Stepper functionality