Mixing
Typescript: how to merge the representation (in tooltip) of this intersection?
2
I have a function with an overload:
interface FunctionWithOverload {
(): {
a: 1
b: 1
}
<T>(arg: T): {
a: 1
b: 1
} & (T extends number ? { c: 1 } : {})
}
const fwo: FunctionWithOverload = () => {return {} as any}
const result = fwo() // result has a nice type: {a: 1, b: 1}
const result1 = fwo(1) // result1 does not: {a: 1, b: 1} & {c: 1}
Playground
If you hover over result, you can see it has a nice type {a:1,b:1} in the tooltip, however result1 has an ugly type {a:1, b:1} & {c:1}.
The question is: how do I somehow merge {a:1, b:1} & {c:1} to {a:1, b:1, c:1} in my case?
Requirements
The function overloads must be as they are, i.e. I am not allowed to add a mutual optional property c to the return type.
Any type alias names shouldn't be added to the output in the tooltip (unless it's the only solution to this problem).
The prettiness matters because it's in the requirements of my task.
typescript typescript-typings
asked Jan 1 at 7:20
Nurbol AlpysbayevNurbol Alpysbayev
4,6511432
add a comment |
2
I have a function with an overload:
interface FunctionWithOverload {
(): {
a: 1
b: 1
}
<T>(arg: T): {
a: 1
b: 1
} & (T extends number ? { c: 1 } : {})
}
const fwo: FunctionWithOverload = () => {return {} as any}
const result = fwo() // result has a nice type: {a: 1, b: 1}
const result1 = fwo(1) // result1 does not: {a: 1, b: 1} & {c: 1}
Playground
If you hover over result, you can see it has a nice type {a:1,b:1} in the tooltip, however result1 has an ugly type {a:1, b:1} & {c:1}.
The question is: how do I somehow merge {a:1, b:1} & {c:1} to {a:1, b:1, c:1} in my case?
Requirements
The function overloads must be as they are, i.e. I am not allowed to add a mutual optional property c to the return type.
Any type alias names shouldn't be added to the output in the tooltip (unless it's the only solution to this problem).
The prettiness matters because it's in the requirements of my task.
typescript typescript-typings
asked Jan 1 at 7:20
Nurbol AlpysbayevNurbol Alpysbayev
4,6511432
1
You can try anIdmapped typetype Id<T>={ [P in keyof T] :T[P]}but the compiler sometimes expands mapped types sometimes it does not..
– Titian Cernicova-Dragomir
Jan 1 at 7:49
@TitianCernicova-Dragomir Hi Titian, Happy New Year! The funny thing is that it doesn't even help, I tried it, produces:Id<{a:1,b:1} & {c:1}>. It maybe that I put it wrongly like this:<T>(arg: T): Id<{... Oh wait, I got it, you meant exactly this by sometimes expands sometimes not
– Nurbol Alpysbayev
Jan 1 at 8:24
Happy new year to you too :). Yup, that's exactly what I meant, it's hard to get the compiler to do what you want in this case...I've been meaning to loo at compiler code to see how it decides what to expand and what not but have not gotten a chance
– Titian Cernicova-Dragomir
Jan 1 at 8:30
@TitianCernicova-Dragomir I have good news! You know how I managed to expand mapped type (if expand means removing type alias name and showing as a plain object literal type)? This:type Id<T>={} & { [P in keyof T] :T[P]}! Weird! Any ideas why that happens? :D
– Nurbol Alpysbayev
Jan 1 at 8:31
add a comment |
2
2
2
I have a function with an overload:
interface FunctionWithOverload {
(): {
a: 1
b: 1
}
<T>(arg: T): {
a: 1
b: 1
} & (T extends number ? { c: 1 } : {})
}
const fwo: FunctionWithOverload = () => {return {} as any}
const result = fwo() // result has a nice type: {a: 1, b: 1}
const result1 = fwo(1) // result1 does not: {a: 1, b: 1} & {c: 1}
Playground
If you hover over result, you can see it has a nice type {a:1,b:1} in the tooltip, however result1 has an ugly type {a:1, b:1} & {c:1}.
The question is: how do I somehow merge {a:1, b:1} & {c:1} to {a:1, b:1, c:1} in my case?
Requirements
The function overloads must be as they are, i.e. I am not allowed to add a mutual optional property c to the return type.
Any type alias names shouldn't be added to the output in the tooltip (unless it's the only solution to this problem).
The prettiness matters because it's in the requirements of my task.
typescript typescript-typings
asked Jan 1 at 7:20
Nurbol AlpysbayevNurbol Alpysbayev
4,6511432
I have a function with an overload:
interface FunctionWithOverload {
(): {
a: 1
b: 1
}
<T>(arg: T): {
a: 1
b: 1
} & (T extends number ? { c: 1 } : {})
}
const fwo: FunctionWithOverload = () => {return {} as any}
const result = fwo() // result has a nice type: {a: 1, b: 1}
const result1 = fwo(1) // result1 does not: {a: 1, b: 1} & {c: 1}
Playground
If you hover over result, you can see it has a nice type {a:1,b:1} in the tooltip, however result1 has an ugly type {a:1, b:1} & {c:1}.
The question is: how do I somehow merge {a:1, b:1} & {c:1} to {a:1, b:1, c:1} in my case?
Requirements
The function overloads must be as they are, i.e. I am not allowed to add a mutual optional property c to the return type.
Any type alias names shouldn't be added to the output in the tooltip (unless it's the only solution to this problem).
The prettiness matters because it's in the requirements of my task.
typescript typescript-typings
typescript typescript-typings
asked Jan 1 at 7:20
Nurbol AlpysbayevNurbol Alpysbayev
4,6511432
asked Jan 1 at 7:20
Nurbol AlpysbayevNurbol Alpysbayev
4,6511432
edited Jan 1 at 8:55
Nurbol Alpysbayev
asked Jan 1 at 7:20
Nurbol AlpysbayevNurbol Alpysbayev
4,6511432
asked Jan 1 at 7:20
Nurbol AlpysbayevNurbol Alpysbayev
4,6511432
asked Jan 1 at 7:20
Nurbol AlpysbayevNurbol Alpysbayev
4,6511432
4,6511432
1
You can try anIdmapped typetype Id<T>={ [P in keyof T] :T[P]}but the compiler sometimes expands mapped types sometimes it does not..
– Titian Cernicova-Dragomir
Jan 1 at 7:49
@TitianCernicova-Dragomir Hi Titian, Happy New Year! The funny thing is that it doesn't even help, I tried it, produces:Id<{a:1,b:1} & {c:1}>. It maybe that I put it wrongly like this:<T>(arg: T): Id<{... Oh wait, I got it, you meant exactly this by sometimes expands sometimes not
– Nurbol Alpysbayev
Jan 1 at 8:24
Happy new year to you too :). Yup, that's exactly what I meant, it's hard to get the compiler to do what you want in this case...I've been meaning to loo at compiler code to see how it decides what to expand and what not but have not gotten a chance
– Titian Cernicova-Dragomir
Jan 1 at 8:30
@TitianCernicova-Dragomir I have good news! You know how I managed to expand mapped type (if expand means removing type alias name and showing as a plain object literal type)? This:type Id<T>={} & { [P in keyof T] :T[P]}! Weird! Any ideas why that happens? :D
– Nurbol Alpysbayev
Jan 1 at 8:31
add a comment |
1
You can try anIdmapped typetype Id<T>={ [P in keyof T] :T[P]}but the compiler sometimes expands mapped types sometimes it does not..
– Titian Cernicova-Dragomir
Jan 1 at 7:49
@TitianCernicova-Dragomir Hi Titian, Happy New Year! The funny thing is that it doesn't even help, I tried it, produces:Id<{a:1,b:1} & {c:1}>. It maybe that I put it wrongly like this:<T>(arg: T): Id<{... Oh wait, I got it, you meant exactly this by sometimes expands sometimes not
– Nurbol Alpysbayev
Jan 1 at 8:24
Happy new year to you too :). Yup, that's exactly what I meant, it's hard to get the compiler to do what you want in this case...I've been meaning to loo at compiler code to see how it decides what to expand and what not but have not gotten a chance
– Titian Cernicova-Dragomir
Jan 1 at 8:30
@TitianCernicova-Dragomir I have good news! You know how I managed to expand mapped type (if expand means removing type alias name and showing as a plain object literal type)? This:type Id<T>={} & { [P in keyof T] :T[P]}! Weird! Any ideas why that happens? :D
– Nurbol Alpysbayev
Jan 1 at 8:31
1
1
You can try an
Id mapped type type Id<T>={ [P in keyof T] :T[P]} but the compiler sometimes expands mapped types sometimes it does not..– Titian Cernicova-Dragomir
Jan 1 at 7:49
You can try an
Id mapped type type Id<T>={ [P in keyof T] :T[P]} but the compiler sometimes expands mapped types sometimes it does not..– Titian Cernicova-Dragomir
Jan 1 at 7:49
@TitianCernicova-Dragomir Hi Titian, Happy New Year! The funny thing is that it doesn't even help, I tried it, produces:
Id<{a:1,b:1} & {c:1}>. It maybe that I put it wrongly like this: <T>(arg: T): Id<{... Oh wait, I got it, you meant exactly this by sometimes expands sometimes not– Nurbol Alpysbayev
Jan 1 at 8:24
@TitianCernicova-Dragomir Hi Titian, Happy New Year! The funny thing is that it doesn't even help, I tried it, produces:
Id<{a:1,b:1} & {c:1}>. It maybe that I put it wrongly like this: <T>(arg: T): Id<{... Oh wait, I got it, you meant exactly this by sometimes expands sometimes not– Nurbol Alpysbayev
Jan 1 at 8:24
Happy new year to you too :). Yup, that's exactly what I meant, it's hard to get the compiler to do what you want in this case...I've been meaning to loo at compiler code to see how it decides what to expand and what not but have not gotten a chance
– Titian Cernicova-Dragomir
Jan 1 at 8:30
Happy new year to you too :). Yup, that's exactly what I meant, it's hard to get the compiler to do what you want in this case...I've been meaning to loo at compiler code to see how it decides what to expand and what not but have not gotten a chance
– Titian Cernicova-Dragomir
Jan 1 at 8:30
@TitianCernicova-Dragomir I have good news! You know how I managed to expand mapped type (if expand means removing type alias name and showing as a plain object literal type)? This:
type Id<T>={} & { [P in keyof T] :T[P]} ! Weird! Any ideas why that happens? :D– Nurbol Alpysbayev
Jan 1 at 8:31
@TitianCernicova-Dragomir I have good news! You know how I managed to expand mapped type (if expand means removing type alias name and showing as a plain object literal type)? This:
type Id<T>={} & { [P in keyof T] :T[P]} ! Weird! Any ideas why that happens? :D– Nurbol Alpysbayev
Jan 1 at 8:31
add a comment |
1 Answer
1
active
oldest
votes
1
I've managed (with the help of TitianCernicova-Dragomir) to solve this! Like this:
interface FunctionWithOverload {
(): {
a: 1
b: 1
}
<T>(arg: T): Id<{
a: 1
b: 1
} & (T extends number ? { c: 1 } : {})>
}
type Id<T>={} & { [P in keyof T] :T[P]}
const fwo: FunctionWithOverload = () => {return {} as any}
const result = fwo() // result has a nice type: {a: 1, b: 1}
const result1 = fwo(1) // result1 DOES HAVE TOO!!! {a: 1, b: 1, c: 1}
Playground
I think the way it works probably is: the TS engine considers mapped types as worthy of being named types, like interfaces, while any unions, intersections (like in the solution above) or basic types like string literals are not.
answered Jan 1 at 8:34
Nurbol AlpysbayevNurbol Alpysbayev
4,6511432
LIke I said in the comments .. unpredictable ... I would not be surprised if this does not always work, but it's a good option to try :)
– Titian Cernicova-Dragomir
Jan 1 at 8:35
1
I just tried it on a complex example where I was also frustrated by the lack of expansion and it worked, soo looks like the intersection helps :)
– Titian Cernicova-Dragomir
Jan 1 at 8:38
@TitianCernicova-Dragomir I think the way it works probably is: the TS engine considers mapped types as worthy of being named types, like interfaces, while any unions, intersections or basic types like string literals are not!
– Nurbol Alpysbayev
Jan 1 at 8:38
Perhaps .. but I an sure I have seen mapped types expanded as well.
– Titian Cernicova-Dragomir
Jan 1 at 8:43
@TitianCernicova-Dragomir you mean mapped types assigned to a type alias? Hmm.. Well I hope this will not happen to my case. BTW if you find such example, please let me know! I am curious what can lead to this behavior.
– Nurbol Alpysbayev
Jan 1 at 8:47
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%2f53993725%2ftypescript-how-to-merge-the-representation-in-tooltip-of-this-intersection%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
1
I've managed (with the help of TitianCernicova-Dragomir) to solve this! Like this:
interface FunctionWithOverload {
(): {
a: 1
b: 1
}
<T>(arg: T): Id<{
a: 1
b: 1
} & (T extends number ? { c: 1 } : {})>
}
type Id<T>={} & { [P in keyof T] :T[P]}
const fwo: FunctionWithOverload = () => {return {} as any}
const result = fwo() // result has a nice type: {a: 1, b: 1}
const result1 = fwo(1) // result1 DOES HAVE TOO!!! {a: 1, b: 1, c: 1}
Playground
I think the way it works probably is: the TS engine considers mapped types as worthy of being named types, like interfaces, while any unions, intersections (like in the solution above) or basic types like string literals are not.
answered Jan 1 at 8:34
Nurbol AlpysbayevNurbol Alpysbayev
4,6511432
LIke I said in the comments .. unpredictable ... I would not be surprised if this does not always work, but it's a good option to try :)
– Titian Cernicova-Dragomir
Jan 1 at 8:35
1
I just tried it on a complex example where I was also frustrated by the lack of expansion and it worked, soo looks like the intersection helps :)
– Titian Cernicova-Dragomir
Jan 1 at 8:38
@TitianCernicova-Dragomir I think the way it works probably is: the TS engine considers mapped types as worthy of being named types, like interfaces, while any unions, intersections or basic types like string literals are not!
– Nurbol Alpysbayev
Jan 1 at 8:38
Perhaps .. but I an sure I have seen mapped types expanded as well.
– Titian Cernicova-Dragomir
Jan 1 at 8:43
@TitianCernicova-Dragomir you mean mapped types assigned to a type alias? Hmm.. Well I hope this will not happen to my case. BTW if you find such example, please let me know! I am curious what can lead to this behavior.
– Nurbol Alpysbayev
Jan 1 at 8:47
add a comment |
1
I've managed (with the help of TitianCernicova-Dragomir) to solve this! Like this:
interface FunctionWithOverload {
(): {
a: 1
b: 1
}
<T>(arg: T): Id<{
a: 1
b: 1
} & (T extends number ? { c: 1 } : {})>
}
type Id<T>={} & { [P in keyof T] :T[P]}
const fwo: FunctionWithOverload = () => {return {} as any}
const result = fwo() // result has a nice type: {a: 1, b: 1}
const result1 = fwo(1) // result1 DOES HAVE TOO!!! {a: 1, b: 1, c: 1}
Playground
I think the way it works probably is: the TS engine considers mapped types as worthy of being named types, like interfaces, while any unions, intersections (like in the solution above) or basic types like string literals are not.
answered Jan 1 at 8:34
Nurbol AlpysbayevNurbol Alpysbayev
4,6511432
LIke I said in the comments .. unpredictable ... I would not be surprised if this does not always work, but it's a good option to try :)
– Titian Cernicova-Dragomir
Jan 1 at 8:35
1
I just tried it on a complex example where I was also frustrated by the lack of expansion and it worked, soo looks like the intersection helps :)
– Titian Cernicova-Dragomir
Jan 1 at 8:38
@TitianCernicova-Dragomir I think the way it works probably is: the TS engine considers mapped types as worthy of being named types, like interfaces, while any unions, intersections or basic types like string literals are not!
– Nurbol Alpysbayev
Jan 1 at 8:38
Perhaps .. but I an sure I have seen mapped types expanded as well.
– Titian Cernicova-Dragomir
Jan 1 at 8:43
@TitianCernicova-Dragomir you mean mapped types assigned to a type alias? Hmm.. Well I hope this will not happen to my case. BTW if you find such example, please let me know! I am curious what can lead to this behavior.
– Nurbol Alpysbayev
Jan 1 at 8:47
add a comment |
1
1
1
I've managed (with the help of TitianCernicova-Dragomir) to solve this! Like this:
interface FunctionWithOverload {
(): {
a: 1
b: 1
}
<T>(arg: T): Id<{
a: 1
b: 1
} & (T extends number ? { c: 1 } : {})>
}
type Id<T>={} & { [P in keyof T] :T[P]}
const fwo: FunctionWithOverload = () => {return {} as any}
const result = fwo() // result has a nice type: {a: 1, b: 1}
const result1 = fwo(1) // result1 DOES HAVE TOO!!! {a: 1, b: 1, c: 1}
Playground
I think the way it works probably is: the TS engine considers mapped types as worthy of being named types, like interfaces, while any unions, intersections (like in the solution above) or basic types like string literals are not.
answered Jan 1 at 8:34
Nurbol AlpysbayevNurbol Alpysbayev
4,6511432
I've managed (with the help of TitianCernicova-Dragomir) to solve this! Like this:
interface FunctionWithOverload {
(): {
a: 1
b: 1
}
<T>(arg: T): Id<{
a: 1
b: 1
} & (T extends number ? { c: 1 } : {})>
}
type Id<T>={} & { [P in keyof T] :T[P]}
const fwo: FunctionWithOverload = () => {return {} as any}
const result = fwo() // result has a nice type: {a: 1, b: 1}
const result1 = fwo(1) // result1 DOES HAVE TOO!!! {a: 1, b: 1, c: 1}
Playground
I think the way it works probably is: the TS engine considers mapped types as worthy of being named types, like interfaces, while any unions, intersections (like in the solution above) or basic types like string literals are not.
answered Jan 1 at 8:34
Nurbol AlpysbayevNurbol Alpysbayev
4,6511432
edited Jan 1 at 8:58
answered Jan 1 at 8:34
Nurbol AlpysbayevNurbol Alpysbayev
4,6511432
answered Jan 1 at 8:34
Nurbol AlpysbayevNurbol Alpysbayev
4,6511432
answered Jan 1 at 8:34
Nurbol AlpysbayevNurbol Alpysbayev
4,6511432
4,6511432
LIke I said in the comments .. unpredictable ... I would not be surprised if this does not always work, but it's a good option to try :)
– Titian Cernicova-Dragomir
Jan 1 at 8:35
1
I just tried it on a complex example where I was also frustrated by the lack of expansion and it worked, soo looks like the intersection helps :)
– Titian Cernicova-Dragomir
Jan 1 at 8:38
@TitianCernicova-Dragomir I think the way it works probably is: the TS engine considers mapped types as worthy of being named types, like interfaces, while any unions, intersections or basic types like string literals are not!
– Nurbol Alpysbayev
Jan 1 at 8:38
Perhaps .. but I an sure I have seen mapped types expanded as well.
– Titian Cernicova-Dragomir
Jan 1 at 8:43
@TitianCernicova-Dragomir you mean mapped types assigned to a type alias? Hmm.. Well I hope this will not happen to my case. BTW if you find such example, please let me know! I am curious what can lead to this behavior.
– Nurbol Alpysbayev
Jan 1 at 8:47
add a comment |
LIke I said in the comments .. unpredictable ... I would not be surprised if this does not always work, but it's a good option to try :)
– Titian Cernicova-Dragomir
Jan 1 at 8:35
1
I just tried it on a complex example where I was also frustrated by the lack of expansion and it worked, soo looks like the intersection helps :)
– Titian Cernicova-Dragomir
Jan 1 at 8:38
@TitianCernicova-Dragomir I think the way it works probably is: the TS engine considers mapped types as worthy of being named types, like interfaces, while any unions, intersections or basic types like string literals are not!
– Nurbol Alpysbayev
Jan 1 at 8:38
Perhaps .. but I an sure I have seen mapped types expanded as well.
– Titian Cernicova-Dragomir
Jan 1 at 8:43
@TitianCernicova-Dragomir you mean mapped types assigned to a type alias? Hmm.. Well I hope this will not happen to my case. BTW if you find such example, please let me know! I am curious what can lead to this behavior.
– Nurbol Alpysbayev
Jan 1 at 8:47
LIke I said in the comments .. unpredictable ... I would not be surprised if this does not always work, but it's a good option to try :)
– Titian Cernicova-Dragomir
Jan 1 at 8:35
LIke I said in the comments .. unpredictable ... I would not be surprised if this does not always work, but it's a good option to try :)
– Titian Cernicova-Dragomir
Jan 1 at 8:35
1
1
I just tried it on a complex example where I was also frustrated by the lack of expansion and it worked, soo looks like the intersection helps :)
– Titian Cernicova-Dragomir
Jan 1 at 8:38
I just tried it on a complex example where I was also frustrated by the lack of expansion and it worked, soo looks like the intersection helps :)
– Titian Cernicova-Dragomir
Jan 1 at 8:38
@TitianCernicova-Dragomir I think the way it works probably is: the TS engine considers mapped types as worthy of being named types, like interfaces, while any unions, intersections or basic types like string literals are not!
– Nurbol Alpysbayev
Jan 1 at 8:38
@TitianCernicova-Dragomir I think the way it works probably is: the TS engine considers mapped types as worthy of being named types, like interfaces, while any unions, intersections or basic types like string literals are not!
– Nurbol Alpysbayev
Jan 1 at 8:38
Perhaps .. but I an sure I have seen mapped types expanded as well.
– Titian Cernicova-Dragomir
Jan 1 at 8:43
Perhaps .. but I an sure I have seen mapped types expanded as well.
– Titian Cernicova-Dragomir
Jan 1 at 8:43
@TitianCernicova-Dragomir you mean mapped types assigned to a type alias? Hmm.. Well I hope this will not happen to my case. BTW if you find such example, please let me know! I am curious what can lead to this behavior.
– Nurbol Alpysbayev
Jan 1 at 8:47
@TitianCernicova-Dragomir you mean mapped types assigned to a type alias? Hmm.. Well I hope this will not happen to my case. BTW if you find such example, please let me know! I am curious what can lead to this behavior.
– Nurbol Alpysbayev
Jan 1 at 8:47
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%2f53993725%2ftypescript-how-to-merge-the-representation-in-tooltip-of-this-intersection%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
1
You can try an
Idmapped typetype Id<T>={ [P in keyof T] :T[P]}but the compiler sometimes expands mapped types sometimes it does not..– Titian Cernicova-Dragomir
Jan 1 at 7:49
@TitianCernicova-Dragomir Hi Titian, Happy New Year! The funny thing is that it doesn't even help, I tried it, produces:
Id<{a:1,b:1} & {c:1}>. It maybe that I put it wrongly like this:<T>(arg: T): Id<{... Oh wait, I got it, you meant exactly this by sometimes expands sometimes not– Nurbol Alpysbayev
Jan 1 at 8:24
Happy new year to you too :). Yup, that's exactly what I meant, it's hard to get the compiler to do what you want in this case...I've been meaning to loo at compiler code to see how it decides what to expand and what not but have not gotten a chance
– Titian Cernicova-Dragomir
Jan 1 at 8:30
@TitianCernicova-Dragomir I have good news! You know how I managed to expand mapped type (if expand means removing type alias name and showing as a plain object literal type)? This:
type Id<T>={} & { [P in keyof T] :T[P]}! Weird! Any ideas why that happens? :D– Nurbol Alpysbayev
Jan 1 at 8:31