Repository navigation
Partial<T, Keys> make only some properties (Keys) optional #53452
Description
Suggestion
Extend https://www.typescriptlang.org/docs/handbook/utility-types.html#partialtype from Partial<T> to Partial<T, Keys>. If Keys is not specified, it defaults to all keys.
🔍 Search Terms
partial
I already found an old, automatically closed issue, here #25760. But I feel like it is warranted to create a new issue as this should be possible to implement without a backwards-incompatible change.
✅ Viability Checklist
My suggestion meets these guidelines:
- This wouldn't be a breaking change in existing TypeScript/JavaScript code
- This wouldn't change the runtime behavior of existing JavaScript code
- This could be implemented without emitting different JS based on the types of the expressions
- This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- This feature would agree with the rest of TypeScript's Design Goals.
⭐ Suggestion
See above.
📃 Motivating Example
interface Todo {
title: string;
description: string;
}
function updateTodo(todo: Todo, fieldsToUpdate: Partial<Todo, 'title'>) {
return { ...todo, ...fieldsToUpdate };
}
const todo1 = {
title: "organize desk",
description: "clear clutter",
};
const todo2 = updateTodo(todo1, {
description: "throw out trash",
});
// fails: 'description' is required to be updated
const todo3 = updateTodo(todo1, {
title: "groceries",
});💻 Use Cases
I often have types where I want all properties to be non-optional, but e.g. when reading them for the first time in an API call, or reading a file, some are optional and then I immediately set them to something if they were not included.
Activity
MartinJohns commentedon Mar 23, 2023
Just pointing out,
Partial<T>is a straight forward simple mapped type.Partial<T, K>is a vastly more complex conditional type for a rare use case.thernstig commentedon Mar 23, 2023
How do you know it is rare? Juding from #25760 and how upvotes usually work, I'd say it is fairly much upvoted and in effect, not rare. And it is included in https://github.com/sindresorhus/type-fest#utilities as
SetOptional.fatcerberus commentedon Mar 23, 2023
18 upvotes on a nearly 6-year-old feature request (and no dupes other than this one) in a repo as heavily trafficked as TS isn't really that much.
thernstig commentedon Mar 23, 2023
+75 upvotes, #25760 (comment) in addition to the issue being closed Jul 30, 2018 (meaning many possibly miss it or do not care upvoting), I do not necessarily agree this is in the lows. VS Code, an arguably even higher trafficked repo, automatically moves 20+ upvote issues into their backlog.
But if there is a real reason why this is a an unwanted feature, maybe due to other ways to achieve this, I can see is not necessary.
RyanCavanaugh commentedon Mar 23, 2023
We don't add utility types to the lib. Twitter thread on why
fatcerberus commentedon Mar 23, 2023
tbf, this is a request to enhance an existing utility type. But I figured it would fall under that rationale regardless.
RyanCavanaugh commentedon Mar 23, 2023
It wouldn't be possible to change Partial like that; it's homomorphic but the keys-based version by definition isn't.
thernstig commentedon Mar 24, 2023
Got it. Though "utility types" are already present (https://www.typescriptlang.org/docs/handbook/utility-types.html):
But I am assuming the definition here is that you do not add utility types, that can be constructed from built-in utility types?
MartinJohns commentedon Mar 24, 2023
They don't add utility types unless they're required for emit purposes. Most of the utility types present were added before they made this decision, and removing them would be a big unnecessary breaking change.