Is there a more efficient approach to creating a Typescript XML parser that does not rely on PropTypes?

Question

Is there a more efficient approach to creating a Typescript XML parser that does not rely on PropTypes?

I'm currently designing the architecture for a web application that will require the consumption of SOAP APIs in hundreds, if not thousands, of instances. These implementations will be developed by 200-300 different developers over a span of several years. Understanding the scope of this project and the number of individuals involved, my aim is to streamline the interaction with this SOAP API through Typescript to minimize complexity.

My goal is to avoid requiring each developer to manually convert strings into their respective types every time a request is made to the API. To achieve this, I am working on handling the conversion process for them. However, due to Typescript's limitations in reflection capability, this task has proven to be somewhat challenging. I have resorted to using a PropTypes approach.

Unfortunately, this approach involves duplicating the structure definition, as it needs to be available in both the TS type (compile-time/type space) and the PropTypes package (run-time/value space). While omitting some implementation details for brevity, I have devised a solution utilizing the prop-types package as seen below:

/* code snippet */

Despite my efforts, I am concerned about the potential for divergence between the two definitions of the User type. As a newcomer to Typescript, I am curious if there are more conventional or intuitive ways within Typescript to tackle this challenge that I might have overlooked?

typescript types

Answer 1

Answer №1

Perhaps this solution could be beneficial for you:

type RenameProp<
  T extends string, 
  S extends string
> = T extends `${S}${infer Substring}` ? Substring : never

type TransformToType<T, S extends string> = { 
  [K in keyof T as K extends string ? RenameProp<K, S> : never]: T[K] 
}

type User = TransformToType<typeof propTypes, 'User.'>

/*
    type User = {
        'UserId': number
        'UserName': string
        'UserType': number
    }
*/

We can utilize the object propTypes to generate another type named User. For T, we utilize the typeof propTypes and for S, a substring that needs to be removed from the beginning of the property names, in this case 'User.'.

The issue might arise from the prop-types package. It may not be clear whether typeof PropTypes.number will resolve to number.

Update:

I just noticed that PropTypes are nested within Requireable. We can handle that as well:

type RenameProp<
  T extends string, 
  S extends string
> = T extends `${S}${infer Substring}` ? Substring : never

type ExtractRequireable<T> = T extends Requireable<infer S> ? S : never

type TransformToType<T, S extends string> = { 
  [K in keyof T as K extends string ? RenameProp<K, S> : never]: ExtractRequireable<T[K]> 
}

type User = TransformToType<typeof propTypes, 'User.'>

Now, the type of User aligns exactly with the specifications mentioned in your initial query.

Sandbox

Answer 2

Perhaps this solution could be beneficial for you:

type RenameProp<
  T extends string, 
  S extends string
> = T extends `${S}${infer Substring}` ? Substring : never

type TransformToType<T, S extends string> = { 
  [K in keyof T as K extends string ? RenameProp<K, S> : never]: T[K] 
}

type User = TransformToType<typeof propTypes, 'User.'>

/*
    type User = {
        'UserId': number
        'UserName': string
        'UserType': number
    }
*/

We can utilize the object propTypes to generate another type named User. For T, we utilize the typeof propTypes and for S, a substring that needs to be removed from the beginning of the property names, in this case 'User.'.

The issue might arise from the prop-types package. It may not be clear whether typeof PropTypes.number will resolve to number.

Update:

I just noticed that PropTypes are nested within Requireable. We can handle that as well:

type RenameProp<
  T extends string, 
  S extends string
> = T extends `${S}${infer Substring}` ? Substring : never

type ExtractRequireable<T> = T extends Requireable<infer S> ? S : never

type TransformToType<T, S extends string> = { 
  [K in keyof T as K extends string ? RenameProp<K, S> : never]: ExtractRequireable<T[K]> 
}

type User = TransformToType<typeof propTypes, 'User.'>

Now, the type of User aligns exactly with the specifications mentioned in your initial query.

Sandbox

Is there a more efficient approach to creating a Typescript XML parser that does not rely on PropTypes?

Answer №1

Similar questions

Angular virtual scrolling not populating the list with data

Controlling the Output in Typescript without Restricting the Input

What exactly is the purpose of the colon in JavaScript's import statement?

Nextjs 14 experiences full page loading due to the presence of multiple root layouts

Accepting undefined in rest parameter of typescript

Can you explain the functionality of the statement a:bc = 9 in JavaScript?

Access data inside nested objects with specified data type

Working with Vue class-based components in TypeScript and setting props

"Exploring the New Feature of Angular 17: Named Router Outlets Implemented

How to handle form-data in NestJS Guards?

Using private members to create getter and setter in TypeScript

Exploring Angular: Looping through an Array of Objects

Is Drizzle ORM able to handle decimal values in MySQL as strings?

Leverage Webpack to bundle ES Modules with TypeScript module aliases

Angular button press

ngx-datatable detail row failing to expand properly

Issue with the declaration of custom types in Typescript

What is the best way to determine the type of a key within an array of objects

Subscriber fails to receive updates from Behavior subject after calling .next(value)

Utilize the gsap ScrollTrigger in conjunction with React's useRef() and Typescript, encountering issues with type mism