Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better type declaration for prop function #241

Closed
mass2527 opened this issue Jan 20, 2024 · 3 comments
Closed

Better type declaration for prop function #241

mass2527 opened this issue Jan 20, 2024 · 3 comments

Comments

@mass2527
Copy link

mass2527 commented Jan 20, 2024

Suggestion

⭐ Suggestion

Better type for key parameter

Currently, invalid keys can be passed without any error.

const person = {
    name: "jane",
    age: 20,
  };
  
prop("invalid-key", person)

To enhance this, I aim to allow only valid keys, such as "name" or "age" in this context.

Better type for obj parameter

Additionally, any value can currently be passed to obj as an argument.

prop("key", () => {})
prop("key", 123)

My goal is to improve this by enforcing that only valid objects can be passed.

💻 Use Cases

@Phryxia
Copy link
Contributor

Phryxia commented Jan 21, 2024

@mass2527 cc @ppeeou

Currently, invalid keys can be passed without any error.

I think first case is intended behavior. As #doc says, it can receive non-key property of given obj. Maybe this is becasue prop can be used in pipe to replace verbose map like following

pipe([
    { x: 0 },
    { x: 1 },
    { y: 2 },
  ],
  map(
    obj => obj.x
  )
)

And it has fairly nice return type also! #source If you're facing some problem because of unconstrained parameter type, can you tell me so that I can help for another approach?

If you want just to restrict key property via function, I recommend this implementation. (Although I'm not sure what you want through this)

function getProperty<T, K extends keyof T>(key: K, obj: T): T[K] {
    return obj[key]
}

Additionally, any value can currently be passed to obj as an argument.

Since function is also just an object, therefore there is no reason to prohibit it. Even they have some their own properties.

const f = () => {}
console.log(Object.getOwnPropertyNames(f)) // ['length', 'name']

After value being initiated from number or boolean literal, they're also being object. they can also have properties.

For example:

const x = 1 // definetly number literal
x.toPrecision(2) // this is valid
x.foo = 'bar' // this also valid (at least for js)

Maybe #this might helps your understanding.

@ppeeou
Copy link
Member

ppeeou commented Jan 21, 2024

@mass2527 @Phryxia
That's right, this is the intended behavior.

Since ramdajs also returns the same type, we judged it to be more familiar to users.
https://ramdajs.com/docs/#prop

@mass2527
Copy link
Author

@Phryxia @ppeeou
I really appreciate the great explanation!

I initially believed that the prop function was only used with pure JavaScript objects, not object values. Now I understand the reason why type definitions were written the way they are currently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants