[types] Simplify some of the conditional types#18128
Conversation
|
No bundle size changes comparing 6610686...9b9b6d6 |
|
I'll trust you regarding performance impact. I'm a fan of the simpler code though. Makes it more obvious what the type does without looking at the name 👍 Anything more you want to add before leaving Draft state? |
|
@eps1lon All good, just didn't want to bother anyone while the validation was running. |
|
@amcasey Much appreciated, thanks! |
This reverts commit 9d0caa5. The new version of `IsEmptyInterface` accepts objects with all optional properties and `And` and `Or` actually have negative perf impact on their own.
|
@eps1lon Is there someone I can work with to better understand the intentions behind the material-ui typings? We're still getting perf complaints and, while there's definitely room for the compiler to improve, some of the types surprised us with their complexity - maybe they can be simplified. Thanks! |
|
@amcasey That would be me. Best open a new issue and ask away what types in particular you need clarification with. |
|
@eps1lon Thanks! I think I worked out most of the answers I was looking for through trial and error, but I'll connect with you in the new year about what combination of TS and material-ui changes would best address the customer request. In the meantime, do you want an issue tracking the fact that this is causing pain for users? |
|
Yeah. I'll reference some more issues that I think are related and then we can tackle this in the new year. |
These tweaks seem to reduce the number of types generated by the TS compiler, but not by enough to substantially impact performance. Mostly, they seem to simplify the code.