gustavoguichard / string-ts

Strongly typed string functions
MIT License
1.19k stars 17 forks source link

Suggestion: Support for native functions #170

Open Ceedrich opened 9 months ago

Ceedrich commented 9 months ago

Suggestion: Support for native functions

I love, how your library enhances the typescript experience when working with literal types. However, it is kind of exhausting to always use the library's functions instead of the native javascript ones. Would you consider (maybe as an option) mapping the string-ts types onto the native javascript functions (see example below)?


Example:

Before:

import { join } form "string-ts"

const joinedString = join(["some", "literal", "string"], " ")
//    ^? "some literal array"

After:

const joinedString = ["some", "literal", "string"].join(" ")
//    ^? "some literal array"

I am looking forward to your evaluation

gustavoguichard commented 8 months ago

Hey @Ceedrich , thanks for contributing. Sorry for the late reply I somehow lost your notification in my inbox.

Even though it is not in our roadmap and I think it could be too much to add it onto the native functions I'm open to the idea and would love to hear some suggestion about it.

joneshf commented 4 days ago

Saw this in passing. If you're looking for how to actually implement it, I think you could do something like extending the global namespace:

declare global {
  interface ReadonlyArray<T> {
    join<const T extends readonly string[], D extends string = ''>(this: T, separator?: D): Join<T, D>;
  }
}

I'm just lifting the type signature from https://github.com/gustavoguichard/string-ts/blob/6196f56718f3404d8ebd15250139c3e8dd836301/src/native/join.ts#L33-L36

It's possible there's a different signature you can use that would work better.

Playground link.

joneshf commented 4 days ago

I'm not sure how much it matters, but you also wouldn't have to worry about tree shaking this native stuff. It's all at the type level, so it wouldn't end up in the bundle anyway.

The things that aren't on the native objects (like capitalize) would still require it, though.

gustavoguichard commented 2 days ago

Hey @joneshf ! The implementation seems trivial indeed. I never really cared much about it because I think it is too much to make a project-wide commitment. But I'm getting interested on doing it given there's quite a few people that would like to have such possibility.

I just need to think of a good API for that. Do you have any suggestion on what would be a good DX to partially/totally setup string-ts types on native functions?

gustavoguichard commented 2 days ago

@Ceedrich also might want to suggest something

Do you have any suggestion on what would be a good DX to partially/totally setup string-ts types on native functions?

Ceedrich commented 2 days ago

Do you have any suggestion on what would be a good DX to partially/totally setup string-ts types on native functions?

I think the best developer experience as a consumer would be to just be able to have the stricter typings of string-ts without having to worry about importing and getting used to new function signatures.

This should be possible just by declaring the types of the native functions in a global .d.ts file.

The user would still be able to use the additional functions the library provides and use the native ones with better typing.

Another thought on that: are there any scenarios where you would prefer the native typings to the ones string-ts provides?

Personally however, I would eventually deprecate the wrapper functions around the native ones as they are generally more unintuitive. About this last part, I am not actually sure and looking forward to hearing your thoughts.