-
Notifications
You must be signed in to change notification settings - Fork 30.3k
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
Update react-i18next types for 8.0.7 #29807
Conversation
|
||
export interface ReactI18NextOptions { | ||
wait?: boolean; | ||
withRef?: boolean; | ||
bindI18n?: string; | ||
bindStore?: string; | ||
/** | ||
* @deprecated This option is now ignored and the function name is always `t` | ||
*/ | ||
translateFuncName?: string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could change its type to 't'
or just remove it altogether. I only kept it because it still technically exists in the return from getDefaults()
.
|
||
export type ContextInferableComponentEnhancerWithProps = | ||
<P extends { [key: string]: any }>(component: React.ComponentClass<P> | React.StatelessComponent<P>) => | ||
React.ComponentClass<Omit<P, keyof ReactI18nContext> & React.ClassAttributes<never>>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been adding React.ClassAttributes<never>
to the HOC to help avoid accidentally saving a ref
to the HOC instead of the actually wrapped component. The getWrappedInstance()
API is gone from react-i18next.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also tried using React.ClassAttributes<React.ComponentClass>
but that was not causing an expected type error on tests.
|
||
type ComponentPropsWithInnerRef<T extends React.ComponentType<any>> = | ||
(T extends React.ComponentClass<infer P> | ||
? P & { innerRef?: React.Ref<InstanceType<T>> } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This only works with withNamespaces
for now.
: T extends React.SFC<infer P> | ||
? P | ||
: {} | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
type ComponentProps<T extends React.ComponentType<any>> =
T extends React.ComponentType<infer P> ? P : {}
sounds like something that could be useful in react.d.ts
itself, at least until infer
is allowed in places other than conditional type conditions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The any
is required by the way; the type argument is not contravariant so it would not allow a component to receive more props than are enumerated.
Should I fix the lints on the Also, what should be done about the helper types that are not exported (and were not exported to begin with); use I also kinda ended up abusing CI, but running
Which specific package errors varies. |
@Kovensky Thank you for submitting this PR! Because this is a new definition, a DefinitelyTyped maintainer will be reviewing this PR in the next few days once the Travis CI build passes. In the meantime, if the build fails or a merge conflict occurs, I'll let you know. Have a nice day! |
@Kovensky The Travis CI build failed! Please review the logs for more information. Once you've pushed the fixes, the build will automatically re-run. Thanks! |
|
||
export interface WithNamespaces { | ||
<TNamespace extends string> | ||
(namespaces: TNamespace | TNamespace[] | undefined, options?: Omit<TranslateOptions, "translateFuncName">): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When testing this typing on a local project, Typescript was telling me that withNamespaces was expecting 1 or 2 arguments. Considering withNamespaces loads the defaultNS defined in i18next if nothing is passed through it, would it be better to make namespaces optional here instead of defining undefined?
I intentionally made the first argument required because the intended API
if you don't need any namespaces is `withI18n`.
…On Wed, Oct 17, 2018 at 20:19 Tyler Pepper ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In types/react-i18next/src/withNamespaces.d.ts
<#29807 (comment)>
:
> +
+export type WrapperComponentClass<T extends React.ComponentType<any>> =
+ React.ComponentClass<
+ Omit<ComponentPropsWithInnerRef<T>, keyof InjectedProps> &
+ React.ClassAttributes<never> &
+ TranslateHocProps
+ >;
+
+// Injects props and removes them from the prop requirements.
+// Adds the new properties t (or whatever the translation function is called) and i18n if needed.
+export type InferableComponentEnhancerWithProps =
+ <T extends React.ComponentType<any>>(component: T) => WrapperComponentClass<T>;
+
+export interface WithNamespaces {
+ <TNamespace extends string>
+ (namespaces: TNamespace | TNamespace[] | undefined, options?: Omit<TranslateOptions, "translateFuncName">):
When testing this typing on a local project, Typescript was telling me
that withNamespaces was expecting 1 or 2 arguments. Considering
withNamespaces loads the defaultNS defined in i18next if nothing is passed
through it, would it be better to make namespaces optional here instead of
defining undefined?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#29807 (review)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEdfZcDFrMvurkQBsHdLXUwPq1NjhbWks5ulxJQgaJpZM4Xjhm->
.
|
These have been released upstream as of react-i18next 8.1.0. See i18next/react-i18next#557. Closes DefinitelyTyped#29408 Closes DefinitelyTyped#29480 Closes DefinitelyTyped#29685 Closes DefinitelyTyped#29807
The upstream library now ships it's own as of react-i18next 8.1.0. See i18next/react-i18next#557. Closes DefinitelyTyped#29408 Closes DefinitelyTyped#29480 Closes DefinitelyTyped#29685 Closes DefinitelyTyped#29807
This PR is probably obsolete, as typings have now been included upstream: i18next/react-i18next#557 and released in 8.1.0. |
Unfortunately the upstream typings are quite lacking compared to the typings here... Guess it'll need some patching. |
Right - I think in that case we should just try to get these into upstream using PRs there. The maintainer there has shown interest in accepting changes fast and I'm already seeing a bunch of PRs on that repo. |
@Kovensky I haven't seen anything from you in a while and this PR currently has problems that prevent it from being merged. The PR will be closed tomorrow if there aren't new commits to fix the issues. |
@Kovensky To keep things tidy, we have to close PRs that aren't mergeable but don't have activity from their author. No worries, though - please open a new PR if you'd like to continue with this change. Thank you! |
npm test
.)npm test
is failing on an unrelated package, somepackage.json
lint?npm run lint package-name
(ortsc
if notslint.json
is present).Select one of these and delete the others:
If changing an existing definition:
tslint.json
containing{ "extends": "dtslint/dt.json" }
.Fixes #29480.