-
-
Notifications
You must be signed in to change notification settings - Fork 604
Get
: Optimize performance
#1031
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
Conversation
Even with this change it will remain configurable by passing in Paths generic with a higher maxRecursionDepth, right? I need a higher maxRecursionDepth than 2. :) |
This also should be done in v5. And if we decide to do it, it must be possible to increase it. I'm just wondering whether the performance increase is worth the inconvenience of potentially not having all things work directly with |
This is not a breaking change like #1029 since it just affects the autocomplete. The second type argument continues to accept any Current behaviour: type Test = Get<{a: {b: {c: {d: string}}}}, 'a.b.d.e.f.g.h.i.j'>; // Valid ![]() Updated behaviour: type Test = Get<{a: {b: {c: {d: string}}}}, 'a.b.d.e.f.g.h.i.j'>; // Still Valid |
@sindresorhus I think there's some confusion, everything will still continue to work, right? The second type argument still effectively accepts any
Not sure, if we really need an option to control the autocomplete behaviour. The way it's used in the JSDoc example (which I feel is how this would mostly be used), the autocomplete is anyways not dependent on our code but on user's code. // `Path` here decides the autocomplete behaviour
const get = <BaseType, Path extends string | readonly string[]>(object: BaseType, path: Path): Get<BaseType, Path> =>
lodash.get(object, path); |
Ah, I didn't realize this is only about auto-complete. Then it's totally fine. |
sure |
Limit suggestions to 'a.b.c' to optimize performance. That is enough for most cases.