-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Type inference works incorrectly when using spread operator over an object property #34558
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
Comments
has to do with this PR: #30769 |
@AviVahl Wow, that was unexpected :). Do you know of any official work-around (apart of cast)? |
I'm not even sure this is a bug. I mean, my intuition (aka heuristics of my brain) tells me this should be allowed: What type should be allowed to be set on I believe that this is a case where using generics is the correct solution: |
Yes, you've hit the nail on the head, this was in fact the exact rationale behind the relevant part of #30769. If As for why the case of |
@AviVahl Okay, this is a clever solution, even though i'm not sure why it works :). In any case, if we think a bit further and try to extend my original example to work for arbitrary number of elements in "layouts" property, this solution also does not work (since it enumerates the keys explicitly). So, i've tried to build a generic solution here, by adding some typedefs etc.: But this does not compile either. I have a feeling i'm missing something very trivial here. Can someone give me hand? |
There are several possible ways to go, depending on the API and behavior you are looking for. I've extracted |
@AviVahl Well, your last suggestion would not work well if 'layuots' object is dynamic, e.g. layers might be added/removed on the fly. That what i was trying in achieve in my prev attempt by having 'key' as an arbitrary string here:
Actually, that attempt boils down to an error here: |
But all this is totally unrelated to the original question i've asked and i'm just ruminating on my task at hand :) |
It can either be static, which means key types can be inferred as a union, or it's dynamic (any string key is fine), in which case you can have the values type-checked to a specific structure . The error in that last link is a separate issue. Depending on the type you want, also can be solved in several ways:
Probably better to keep further discussion in stack overflow (for future developers). |
TypeScript Version: 3.5.1 and up
Code
Expected behavior: Code compiles
Actual behavior: Code produces a compilation error. Version < 3.5 works fine
Playground Link: http://www.typescriptlang.org/play/index.html?ts=3.5.1#code/MYGwhgzhAEAqCmEAu0DeAoaXrgJ4HsBXJGAXjU2yuHwDskiAnCALgqo+wHIA3ASwh8ARnxB8kuLm14DhIeFwA0lTlS5ja8ALQArfH1pToXRkVoATJStVZ1B7cDAAHIybOXrVAL7KbAW0IIeEI-VnYbbn5BETEJVyi5BU9sL2svAG50awYAcxz5ABkwXHhGAAp4HiQ2VGgeMBBCeGkaeiYILmgAH2MAoJCO6C8ASnDOJAALAQA6PCISAG1KpGn6xvgAXWhyWoB6XegAHlJyAGEAeQBZAAUASQKAQVhb84A5aABRACUv86-oAAS3w+yU403Bkxmc2IECWVVWDSaG18ESwCRi4lwbEhEFmxXmsOWCPWG1WsgxEm2J2M6PknQA-MZaHQFNBpLSkjYMml0F4gA
The text was updated successfully, but these errors were encountered: