Typescript infer Generic types from Implementation
3
So I am working on a react-native project.
I was hoping if one could infer Generic types from implementation.
type itemType<T> = { item: T };
const someItem = {
item: 'Some String'
};
type someItemType = typeof someItem;
// So Here someItemType will be {item: string}, i want it to be itemType<string> and
// in this example i have implemented itemType but in real use case i want to infer
//it from the actual implementation
typescript typescript-typings
asked Nov 22 '18 at 8:31
Amol GuptaAmol Gupta
648
add a comment |
3
So I am working on a react-native project.
I was hoping if one could infer Generic types from implementation.
type itemType<T> = { item: T };
const someItem = {
item: 'Some String'
};
type someItemType = typeof someItem;
// So Here someItemType will be {item: string}, i want it to be itemType<string> and
// in this example i have implemented itemType but in real use case i want to infer
//it from the actual implementation
typescript typescript-typings
asked Nov 22 '18 at 8:31
Amol GuptaAmol Gupta
648
add a comment |
3
3
3
So I am working on a react-native project.
I was hoping if one could infer Generic types from implementation.
type itemType<T> = { item: T };
const someItem = {
item: 'Some String'
};
type someItemType = typeof someItem;
// So Here someItemType will be {item: string}, i want it to be itemType<string> and
// in this example i have implemented itemType but in real use case i want to infer
//it from the actual implementation
typescript typescript-typings
asked Nov 22 '18 at 8:31
Amol GuptaAmol Gupta
648
So I am working on a react-native project.
I was hoping if one could infer Generic types from implementation.
type itemType<T> = { item: T };
const someItem = {
item: 'Some String'
};
type someItemType = typeof someItem;
// So Here someItemType will be {item: string}, i want it to be itemType<string> and
// in this example i have implemented itemType but in real use case i want to infer
//it from the actual implementation
typescript typescript-typings
typescript typescript-typings
asked Nov 22 '18 at 8:31
Amol GuptaAmol Gupta
648
asked Nov 22 '18 at 8:31
Amol GuptaAmol Gupta
648
asked Nov 22 '18 at 8:31
Amol GuptaAmol Gupta
648
asked Nov 22 '18 at 8:31
Amol GuptaAmol Gupta
648
asked Nov 22 '18 at 8:31
Amol GuptaAmol Gupta
648
648
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
2
Partial inference on variables is not supported at present in typescript. Your only option is to use the inference behavior of function:
type itemType<T> = { item: T };
const createItemType = <T>(o: itemType<T>) => o;
const someItem = createItemType({ //someItem is typed as itemType<string>
item: 'Some String'
})
Just one note, it might not matter that in your original example someItem is typed as {item: string}, it will still be assignable to itemType<string> because typescript uses structural compatibility to determine assignability. So if the structure is compatible all is ok:
type itemType<T> = { item: T };
const someItem ={
item: 'Some String'
}
const someOtherItem: itemType<string> = someItem // ok
answered Nov 22 '18 at 8:43
Titian Cernicova-DragomirTitian Cernicova-Dragomir
59.3k33553
In this case, I wouldn't write extra runtime code as there is no benefit to making the names match outside of a nominal type system.
– Fenton
Nov 22 '18 at 8:44
@Fenton agreed, that is why I pointed out it does not much matter what the actual type ifsomeItemis, al least with regard to future assignability toitemType<string>. There might be benefit in ensuring the object conforms to theitemType<T>interface at declaration site, rather than on future usage, I'd expect the perf impact of the identity function used to not be too high in most scenarios.
– Titian Cernicova-Dragomir
Nov 22 '18 at 8:46
I famously don't worry about performance impact - I worry about having to go back and change the program in six months :)
– Fenton
Nov 22 '18 at 8:48
@Fenton I must admit, while I do worry about that I have used such functions to help with inference all in one lineconst someItem = (<T>(o: itemType<T>) => o)({ item: 'Some String' })I will understand then in 6 months.. not sure anybody else understands them right now :)
– Titian Cernicova-Dragomir
Nov 22 '18 at 8:51
I have some code that looks a bit like this in C#. I think if you flash it up for half a second and ask people to guess what they saw, and they answer "A Regular Expression" it's time to refactor.
– Fenton
Nov 22 '18 at 8:54
|
show 3 more comments
2
It doesn't matter whether the type is defined as { item: string } or itemType<string> as TypeScript uses structural typing. That means the two are the same, because they have identical structures.
For example, you can assign values of either type to each other type:
type itemType<T> = { item: T };
const someItem = {
item: 'Some String'
};
type someItemType = typeof someItem;
const a: itemType<string> = { item: 'exmaple a' };
const b: someItemType = { item: 'exmaple b' };
let c: itemType<string>;
c = a;
c = b;
let d: someItemType;
d = a;
d = b;
answered Nov 22 '18 at 8:43
FentonFenton
152k42287311
So the thing is i do not want to write type itemType<T> = { item: T }; i want to infer it from the implementation.
– Amol Gupta
Nov 22 '18 at 8:52
That way if i update the original object my types are automatically updated.
– Amol Gupta
Nov 22 '18 at 8:53
If you update the original object, it may no longer be anitemType<T>.
– Fenton
Nov 22 '18 at 9:08
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53426728%2ftypescript-infer-generic-types-from-implementation%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
2
Partial inference on variables is not supported at present in typescript. Your only option is to use the inference behavior of function:
type itemType<T> = { item: T };
const createItemType = <T>(o: itemType<T>) => o;
const someItem = createItemType({ //someItem is typed as itemType<string>
item: 'Some String'
})
Just one note, it might not matter that in your original example someItem is typed as {item: string}, it will still be assignable to itemType<string> because typescript uses structural compatibility to determine assignability. So if the structure is compatible all is ok:
type itemType<T> = { item: T };
const someItem ={
item: 'Some String'
}
const someOtherItem: itemType<string> = someItem // ok
answered Nov 22 '18 at 8:43
Titian Cernicova-DragomirTitian Cernicova-Dragomir
59.3k33553
In this case, I wouldn't write extra runtime code as there is no benefit to making the names match outside of a nominal type system.
– Fenton
Nov 22 '18 at 8:44
@Fenton agreed, that is why I pointed out it does not much matter what the actual type ifsomeItemis, al least with regard to future assignability toitemType<string>. There might be benefit in ensuring the object conforms to theitemType<T>interface at declaration site, rather than on future usage, I'd expect the perf impact of the identity function used to not be too high in most scenarios.
– Titian Cernicova-Dragomir
Nov 22 '18 at 8:46
I famously don't worry about performance impact - I worry about having to go back and change the program in six months :)
– Fenton
Nov 22 '18 at 8:48
@Fenton I must admit, while I do worry about that I have used such functions to help with inference all in one lineconst someItem = (<T>(o: itemType<T>) => o)({ item: 'Some String' })I will understand then in 6 months.. not sure anybody else understands them right now :)
– Titian Cernicova-Dragomir
Nov 22 '18 at 8:51
I have some code that looks a bit like this in C#. I think if you flash it up for half a second and ask people to guess what they saw, and they answer "A Regular Expression" it's time to refactor.
– Fenton
Nov 22 '18 at 8:54
|
show 3 more comments
2
Partial inference on variables is not supported at present in typescript. Your only option is to use the inference behavior of function:
type itemType<T> = { item: T };
const createItemType = <T>(o: itemType<T>) => o;
const someItem = createItemType({ //someItem is typed as itemType<string>
item: 'Some String'
})
Just one note, it might not matter that in your original example someItem is typed as {item: string}, it will still be assignable to itemType<string> because typescript uses structural compatibility to determine assignability. So if the structure is compatible all is ok:
type itemType<T> = { item: T };
const someItem ={
item: 'Some String'
}
const someOtherItem: itemType<string> = someItem // ok
answered Nov 22 '18 at 8:43
Titian Cernicova-DragomirTitian Cernicova-Dragomir
59.3k33553
In this case, I wouldn't write extra runtime code as there is no benefit to making the names match outside of a nominal type system.
– Fenton
Nov 22 '18 at 8:44
@Fenton agreed, that is why I pointed out it does not much matter what the actual type ifsomeItemis, al least with regard to future assignability toitemType<string>. There might be benefit in ensuring the object conforms to theitemType<T>interface at declaration site, rather than on future usage, I'd expect the perf impact of the identity function used to not be too high in most scenarios.
– Titian Cernicova-Dragomir
Nov 22 '18 at 8:46
I famously don't worry about performance impact - I worry about having to go back and change the program in six months :)
– Fenton
Nov 22 '18 at 8:48
@Fenton I must admit, while I do worry about that I have used such functions to help with inference all in one lineconst someItem = (<T>(o: itemType<T>) => o)({ item: 'Some String' })I will understand then in 6 months.. not sure anybody else understands them right now :)
– Titian Cernicova-Dragomir
Nov 22 '18 at 8:51
I have some code that looks a bit like this in C#. I think if you flash it up for half a second and ask people to guess what they saw, and they answer "A Regular Expression" it's time to refactor.
– Fenton
Nov 22 '18 at 8:54
|
show 3 more comments
2
2
2
Partial inference on variables is not supported at present in typescript. Your only option is to use the inference behavior of function:
type itemType<T> = { item: T };
const createItemType = <T>(o: itemType<T>) => o;
const someItem = createItemType({ //someItem is typed as itemType<string>
item: 'Some String'
})
Just one note, it might not matter that in your original example someItem is typed as {item: string}, it will still be assignable to itemType<string> because typescript uses structural compatibility to determine assignability. So if the structure is compatible all is ok:
type itemType<T> = { item: T };
const someItem ={
item: 'Some String'
}
const someOtherItem: itemType<string> = someItem // ok
answered Nov 22 '18 at 8:43
Titian Cernicova-DragomirTitian Cernicova-Dragomir
59.3k33553
Partial inference on variables is not supported at present in typescript. Your only option is to use the inference behavior of function:
type itemType<T> = { item: T };
const createItemType = <T>(o: itemType<T>) => o;
const someItem = createItemType({ //someItem is typed as itemType<string>
item: 'Some String'
})
Just one note, it might not matter that in your original example someItem is typed as {item: string}, it will still be assignable to itemType<string> because typescript uses structural compatibility to determine assignability. So if the structure is compatible all is ok:
type itemType<T> = { item: T };
const someItem ={
item: 'Some String'
}
const someOtherItem: itemType<string> = someItem // ok
answered Nov 22 '18 at 8:43
Titian Cernicova-DragomirTitian Cernicova-Dragomir
59.3k33553
edited Nov 22 '18 at 8:47
answered Nov 22 '18 at 8:43
Titian Cernicova-DragomirTitian Cernicova-Dragomir
59.3k33553
answered Nov 22 '18 at 8:43
Titian Cernicova-DragomirTitian Cernicova-Dragomir
59.3k33553
answered Nov 22 '18 at 8:43
Titian Cernicova-DragomirTitian Cernicova-Dragomir
59.3k33553
59.3k33553
In this case, I wouldn't write extra runtime code as there is no benefit to making the names match outside of a nominal type system.
– Fenton
Nov 22 '18 at 8:44
@Fenton agreed, that is why I pointed out it does not much matter what the actual type ifsomeItemis, al least with regard to future assignability toitemType<string>. There might be benefit in ensuring the object conforms to theitemType<T>interface at declaration site, rather than on future usage, I'd expect the perf impact of the identity function used to not be too high in most scenarios.
– Titian Cernicova-Dragomir
Nov 22 '18 at 8:46
I famously don't worry about performance impact - I worry about having to go back and change the program in six months :)
– Fenton
Nov 22 '18 at 8:48
@Fenton I must admit, while I do worry about that I have used such functions to help with inference all in one lineconst someItem = (<T>(o: itemType<T>) => o)({ item: 'Some String' })I will understand then in 6 months.. not sure anybody else understands them right now :)
– Titian Cernicova-Dragomir
Nov 22 '18 at 8:51
I have some code that looks a bit like this in C#. I think if you flash it up for half a second and ask people to guess what they saw, and they answer "A Regular Expression" it's time to refactor.
– Fenton
Nov 22 '18 at 8:54
|
show 3 more comments
In this case, I wouldn't write extra runtime code as there is no benefit to making the names match outside of a nominal type system.
– Fenton
Nov 22 '18 at 8:44
@Fenton agreed, that is why I pointed out it does not much matter what the actual type ifsomeItemis, al least with regard to future assignability toitemType<string>. There might be benefit in ensuring the object conforms to theitemType<T>interface at declaration site, rather than on future usage, I'd expect the perf impact of the identity function used to not be too high in most scenarios.
– Titian Cernicova-Dragomir
Nov 22 '18 at 8:46
I famously don't worry about performance impact - I worry about having to go back and change the program in six months :)
– Fenton
Nov 22 '18 at 8:48
@Fenton I must admit, while I do worry about that I have used such functions to help with inference all in one lineconst someItem = (<T>(o: itemType<T>) => o)({ item: 'Some String' })I will understand then in 6 months.. not sure anybody else understands them right now :)
– Titian Cernicova-Dragomir
Nov 22 '18 at 8:51
I have some code that looks a bit like this in C#. I think if you flash it up for half a second and ask people to guess what they saw, and they answer "A Regular Expression" it's time to refactor.
– Fenton
Nov 22 '18 at 8:54
In this case, I wouldn't write extra runtime code as there is no benefit to making the names match outside of a nominal type system.
– Fenton
Nov 22 '18 at 8:44
In this case, I wouldn't write extra runtime code as there is no benefit to making the names match outside of a nominal type system.
– Fenton
Nov 22 '18 at 8:44
@Fenton agreed, that is why I pointed out it does not much matter what the actual type if
someItem is, al least with regard to future assignability to itemType<string>. There might be benefit in ensuring the object conforms to the itemType<T> interface at declaration site, rather than on future usage, I'd expect the perf impact of the identity function used to not be too high in most scenarios.– Titian Cernicova-Dragomir
Nov 22 '18 at 8:46
@Fenton agreed, that is why I pointed out it does not much matter what the actual type if
someItem is, al least with regard to future assignability to itemType<string>. There might be benefit in ensuring the object conforms to the itemType<T> interface at declaration site, rather than on future usage, I'd expect the perf impact of the identity function used to not be too high in most scenarios.– Titian Cernicova-Dragomir
Nov 22 '18 at 8:46
I famously don't worry about performance impact - I worry about having to go back and change the program in six months :)
– Fenton
Nov 22 '18 at 8:48
I famously don't worry about performance impact - I worry about having to go back and change the program in six months :)
– Fenton
Nov 22 '18 at 8:48
@Fenton I must admit, while I do worry about that I have used such functions to help with inference all in one line
const someItem = (<T>(o: itemType<T>) => o)({ item: 'Some String' }) I will understand then in 6 months.. not sure anybody else understands them right now :)– Titian Cernicova-Dragomir
Nov 22 '18 at 8:51
@Fenton I must admit, while I do worry about that I have used such functions to help with inference all in one line
const someItem = (<T>(o: itemType<T>) => o)({ item: 'Some String' }) I will understand then in 6 months.. not sure anybody else understands them right now :)– Titian Cernicova-Dragomir
Nov 22 '18 at 8:51
I have some code that looks a bit like this in C#. I think if you flash it up for half a second and ask people to guess what they saw, and they answer "A Regular Expression" it's time to refactor.
– Fenton
Nov 22 '18 at 8:54
I have some code that looks a bit like this in C#. I think if you flash it up for half a second and ask people to guess what they saw, and they answer "A Regular Expression" it's time to refactor.
– Fenton
Nov 22 '18 at 8:54
|
show 3 more comments
2
It doesn't matter whether the type is defined as { item: string } or itemType<string> as TypeScript uses structural typing. That means the two are the same, because they have identical structures.
For example, you can assign values of either type to each other type:
type itemType<T> = { item: T };
const someItem = {
item: 'Some String'
};
type someItemType = typeof someItem;
const a: itemType<string> = { item: 'exmaple a' };
const b: someItemType = { item: 'exmaple b' };
let c: itemType<string>;
c = a;
c = b;
let d: someItemType;
d = a;
d = b;
answered Nov 22 '18 at 8:43
FentonFenton
152k42287311
So the thing is i do not want to write type itemType<T> = { item: T }; i want to infer it from the implementation.
– Amol Gupta
Nov 22 '18 at 8:52
That way if i update the original object my types are automatically updated.
– Amol Gupta
Nov 22 '18 at 8:53
If you update the original object, it may no longer be anitemType<T>.
– Fenton
Nov 22 '18 at 9:08
add a comment |
2
It doesn't matter whether the type is defined as { item: string } or itemType<string> as TypeScript uses structural typing. That means the two are the same, because they have identical structures.
For example, you can assign values of either type to each other type:
type itemType<T> = { item: T };
const someItem = {
item: 'Some String'
};
type someItemType = typeof someItem;
const a: itemType<string> = { item: 'exmaple a' };
const b: someItemType = { item: 'exmaple b' };
let c: itemType<string>;
c = a;
c = b;
let d: someItemType;
d = a;
d = b;
answered Nov 22 '18 at 8:43
FentonFenton
152k42287311
So the thing is i do not want to write type itemType<T> = { item: T }; i want to infer it from the implementation.
– Amol Gupta
Nov 22 '18 at 8:52
That way if i update the original object my types are automatically updated.
– Amol Gupta
Nov 22 '18 at 8:53
If you update the original object, it may no longer be anitemType<T>.
– Fenton
Nov 22 '18 at 9:08
add a comment |
2
2
2
It doesn't matter whether the type is defined as { item: string } or itemType<string> as TypeScript uses structural typing. That means the two are the same, because they have identical structures.
For example, you can assign values of either type to each other type:
type itemType<T> = { item: T };
const someItem = {
item: 'Some String'
};
type someItemType = typeof someItem;
const a: itemType<string> = { item: 'exmaple a' };
const b: someItemType = { item: 'exmaple b' };
let c: itemType<string>;
c = a;
c = b;
let d: someItemType;
d = a;
d = b;
answered Nov 22 '18 at 8:43
FentonFenton
152k42287311
It doesn't matter whether the type is defined as { item: string } or itemType<string> as TypeScript uses structural typing. That means the two are the same, because they have identical structures.
For example, you can assign values of either type to each other type:
type itemType<T> = { item: T };
const someItem = {
item: 'Some String'
};
type someItemType = typeof someItem;
const a: itemType<string> = { item: 'exmaple a' };
const b: someItemType = { item: 'exmaple b' };
let c: itemType<string>;
c = a;
c = b;
let d: someItemType;
d = a;
d = b;
answered Nov 22 '18 at 8:43
FentonFenton
152k42287311
answered Nov 22 '18 at 8:43
FentonFenton
152k42287311
answered Nov 22 '18 at 8:43
FentonFenton
152k42287311
answered Nov 22 '18 at 8:43
FentonFenton
152k42287311
152k42287311
So the thing is i do not want to write type itemType<T> = { item: T }; i want to infer it from the implementation.
– Amol Gupta
Nov 22 '18 at 8:52
That way if i update the original object my types are automatically updated.
– Amol Gupta
Nov 22 '18 at 8:53
If you update the original object, it may no longer be anitemType<T>.
– Fenton
Nov 22 '18 at 9:08
add a comment |
So the thing is i do not want to write type itemType<T> = { item: T }; i want to infer it from the implementation.
– Amol Gupta
Nov 22 '18 at 8:52
That way if i update the original object my types are automatically updated.
– Amol Gupta
Nov 22 '18 at 8:53
If you update the original object, it may no longer be anitemType<T>.
– Fenton
Nov 22 '18 at 9:08
So the thing is i do not want to write type itemType<T> = { item: T }; i want to infer it from the implementation.
– Amol Gupta
Nov 22 '18 at 8:52
So the thing is i do not want to write type itemType<T> = { item: T }; i want to infer it from the implementation.
– Amol Gupta
Nov 22 '18 at 8:52
That way if i update the original object my types are automatically updated.
– Amol Gupta
Nov 22 '18 at 8:53
That way if i update the original object my types are automatically updated.
– Amol Gupta
Nov 22 '18 at 8:53
If you update the original object, it may no longer be an
itemType<T>.– Fenton
Nov 22 '18 at 9:08
If you update the original object, it may no longer be an
itemType<T>.– Fenton
Nov 22 '18 at 9:08
add a comment |
draft saved
draft discarded
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53426728%2ftypescript-infer-generic-types-from-implementation%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
