A function that creates a new object with identical keys as the original input object

Question

A function that creates a new object with identical keys as the original input object

I am working on creating a function fn() that has the following specifications:

It takes a single argument x which is an object with optional keys "a" and "b" (each field may be numeric for simplicity)
The function should return a new object with the same keys as the input object, but each field should be a specific class (a->A, b->B). The expected behavior is:

Calling fn({a: 1, b: 1}) should return {a: A, b: B}
Calling fn({b:1}) should return {b: B}
Calling fn({}) should return {}

You can use the numeric values in the input object as initialization values for the classes in the output object. Additionally, new fields "c", "d", "e", and so on may be added to this function later.

I am having trouble implementing this on the type level as well as in JavaScript code. The code I have written so far is causing Typescript errors:

Type 'string' is not assignable to type 'keyof OutputObject'.ts(2344)
Type 'Partial' is not assignable to type 'Pick'.ts(2322)

class A {}
class B {} 

interface InputObject {
a: number,
b: number
}

interface OutputObject {
a: A,
b: B
}

// My failed attempt at writing fn()

const fn = <
    TObj extends Partial<InputObject>,
    K extends keyof TObj
>(x: TObj): Pick<OutputObject, K> => {

    let returnValue: Partial<OutputObject> = {}

    if (x.a) {
        returnValue.a = new A()
    }

    if (x.b) {
        returnValue.b = new B()
    }

    return returnValue
}

javascript typescript

Answer 1

Answer №1

TypeScript faces challenges in comprehending the inner workings of the fn() implementation to ensure it aligns with the generic mapped type relationship of Picking identical keys from the OutputObject and InputObject types. To proceed, you'll need to employ type assertions to relax the type checking. This necessitates caution in ensuring your code behaves as intended since the compiler cannot fully verify it.

Here's a potential strategy:

const fn = <K extends keyof InputObject = never>(
    x: Pick<InputObject, K> & Partial<InputObject>
): Pick<OutputObject, K> => {    
    let returnValue = {} as
        Pick<OutputObject, K> & Partial<OutputObject>;
    if (x.a) { returnValue.a = new A() }    
    if (x.b) { returnValue.b = new B() }    
    return returnValue;
}

Key aspects to note include:

The function is generic only in K, the keys existing in the x input type. This simplifies the compiler's inference of K, particularly since we aim to avoid any surplus keys that could arise if x were a subtype of Pick<InputObject, K>.
When passing in {}, the compiler struggles to accurately infer
```
K</code, often reverting to <code>keyof InputObject
```
, contrary to our intentions. We seek the never type, indicating the absence of any keys. Therefore, a default type argument of never is established.
The input type intersects with Partial<InputObject> within the function to confirm that if a property with key a or b exists, it aligns with the InputObject value type. This precaution is necessary because TS object types are not sealed. For instance, the value {a: 1, b: "hello"} technically qualifies as type
```
Pick<InputObject, "a">
```
, enabling the creation of
```
interface Foo extends Pick<InputObject, "a"> {b: string}
```
and utilizing a Foo. We aim to prevent such scenarios.
The type assertion for returnValue is initially inaccurate, given that {} is unlikely to match type Pick<OutputObject, K>. However, the assumption is that this will rectify itself by the function's conclusion.

The asserted type is also combined with

Partial<OutputObject></code for the same reason as the preceding intersection, assuring the compiler that indexing into <code>returnValue

using a and b is acceptable.

Testing time:

const v = fn({ a: 1 });
// const v: Pick<OutputObject, "a">
const w = fn({});
// const w: Pick<OutputObject, never>
const x = fn({ b: 2 });
// const x: Pick<OutputObject, "b">
const y = fn({ a: 1, b: 2 })
// const y: Pick<OutputObject, "a" | "b">

Results align with expectations. The output types match the anticipated values.

Playground link to code

Answer 2

TypeScript faces challenges in comprehending the inner workings of the fn() implementation to ensure it aligns with the generic mapped type relationship of Picking identical keys from the OutputObject and InputObject types. To proceed, you'll need to employ type assertions to relax the type checking. This necessitates caution in ensuring your code behaves as intended since the compiler cannot fully verify it.

Here's a potential strategy:

const fn = <K extends keyof InputObject = never>(
    x: Pick<InputObject, K> & Partial<InputObject>
): Pick<OutputObject, K> => {    
    let returnValue = {} as
        Pick<OutputObject, K> & Partial<OutputObject>;
    if (x.a) { returnValue.a = new A() }    
    if (x.b) { returnValue.b = new B() }    
    return returnValue;
}

Key aspects to note include:

The function is generic only in K, the keys existing in the x input type. This simplifies the compiler's inference of K, particularly since we aim to avoid any surplus keys that could arise if x were a subtype of Pick<InputObject, K>.
When passing in {}, the compiler struggles to accurately infer
```
K</code, often reverting to <code>keyof InputObject
```
, contrary to our intentions. We seek the never type, indicating the absence of any keys. Therefore, a default type argument of never is established.
The input type intersects with Partial<InputObject> within the function to confirm that if a property with key a or b exists, it aligns with the InputObject value type. This precaution is necessary because TS object types are not sealed. For instance, the value {a: 1, b: "hello"} technically qualifies as type
```
Pick<InputObject, "a">
```
, enabling the creation of
```
interface Foo extends Pick<InputObject, "a"> {b: string}
```
and utilizing a Foo. We aim to prevent such scenarios.
The type assertion for returnValue is initially inaccurate, given that {} is unlikely to match type Pick<OutputObject, K>. However, the assumption is that this will rectify itself by the function's conclusion.

The asserted type is also combined with

Partial<OutputObject></code for the same reason as the preceding intersection, assuring the compiler that indexing into <code>returnValue

using a and b is acceptable.

Testing time:

const v = fn({ a: 1 });
// const v: Pick<OutputObject, "a">
const w = fn({});
// const w: Pick<OutputObject, never>
const x = fn({ b: 2 });
// const x: Pick<OutputObject, "b">
const y = fn({ a: 1, b: 2 })
// const y: Pick<OutputObject, "a" | "b">

Results align with expectations. The output types match the anticipated values.

Playground link to code

A function that creates a new object with identical keys as the original input object

Answer №1

Similar questions

Utilizing JodaTime with JavaScript (AngularJS): A Comprehensive Guide

Obtain the height and width of the original images from the href and assign them to your attributes using jQuery

Typescript: Omitting mandatory fields from a type

What is causing my controller action to create two new records instead of just one?

Ways to select the element based on a specific CSS property value in the inline style

Adjust parent div size based on image size increase

Leveraging Inversify for implementing a Multiinject functionality for a class with both constant and injected parameters

Generate a .py file through an HTML button click and save it to your device

Encountering a "TypeError: Cannot access the 'state' property of undefined" error while using React's "Map" function

Converting JSON data from one structure to a different format

Inconsistency with Angular 4 instance variables causes ambiguity within a function

When utilizing custom modules in Node.js, is it more effective to require the module from within a function or at the top of the script?

Expecting expression and a syntax error occurred: JSX nextjs token was unexpected

In React, the edit mode fails to display class attributes

How can we avoid page flickering and stuttering while scrolling using the ScrollTo script?

Adjusting the dimensions of a rectangle using jQuery: A step-by-step guide

What is the best method for excluding past dates in the Ui calendar?

Ways to retrieve the innerHTML content in Mozilla Firefox

How can we dynamically reference past elements in an array without using indices like "i-1", "i-2", and so on?

How can I use regular expressions to validate one-letter domain names?