I understand your frustration, however, consider just some Typescript interface. It likely says that ON interface IFoo, there is a property called x type T1 and one called y type T2, and that's it, that the interface. Now let f: IFoo. If you type f.x Typescript tells you you'd get some T1. Type f.y and Typescript will tell you you'd get some T2. Type z and.. Typescript will give you a "hold your horses". Because of course it would - what is property "z" on some IFoo? That's pretty much what Typescript is there for. Now, remember that f.x is just syntactic sugar for f["x"]. So, by specifying the interface, you're telling Typescript to limit the keys that variable f can accept, and telling it what type it returns for the allowed index keys. In Typescript, it's easy to define an interface that is like what you'd expect from "object" - as others noted in the comments. But this just isn't what this word is for, in Typescript. In Typescript, the specific type object refers to any non primitive. And of course, for when you're feeling lazy or are just indeed going very general, there's always good ol' "any".
It intrigues me that you're frustrated with that coming from C# specifically (first, because I am too, and second, because C#'s static typing is such a strength of it, and third, because I see Typescript as "Javascript translated for static-typed-OOP-languages speakers"). But each to their own I guess.
Do take time with it. Getting used to Javascript, you might just not only get used to this but also see why it's the right thing for Typescript.
BTW sorry for not writing code and formatting. Am currently not near a computer, and using phone.
I feel like the disconnect here comes when we refer to all-purpose, utility functions. It's fine to say that, in TS, an object must be defined as having Properties X with Value Types Y, but that only works when you're trying to write a narrowly-defined function.
In the example I gave, I wanted to know if any two objects share the same key, and the same value stored in that key. In my example, I illustrated two potential "user" objects. But if you look at the code in the JS example, the function doesn't require that each object shares a common set of keys. Nor do I want to constrict the function to only comparing objects that have matching sets of keys.
IMHO, TS starts to become a major PITA when you're trying to write these kinds of utility functions - the kind of functions where you want to process any object.
And sure, you can just slap that any on the inputs, but that feels really lame. First, it's lame because any would allow the input to be, say, a number, or a Boolean. But it's also lame because this is the definition of an object from the MDN docs (developer.mozilla.org/en-US/docs/W...
Property values can be values of any type, including other objects, which enables building complex data structures. Properties are identified using key values. A key value is either a String or a Symbol value.
If that's the definition in the MDN docs, why do I need to tell TS that a string is an acceptable key for an object???
It's all fine to tightly define object data types through tools like interfaces, but when I have logic that I want to run on a wide array of objects, I shouldn't have to explain to TS that those objects could have strings for keys.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I understand your frustration, however, consider just some Typescript interface. It likely says that ON interface IFoo, there is a property called x type T1 and one called y type T2, and that's it, that the interface. Now let f: IFoo. If you type f.x Typescript tells you you'd get some T1. Type f.y and Typescript will tell you you'd get some T2. Type z and.. Typescript will give you a "hold your horses". Because of course it would - what is property "z" on some IFoo? That's pretty much what Typescript is there for. Now, remember that f.x is just syntactic sugar for f["x"]. So, by specifying the interface, you're telling Typescript to limit the keys that variable f can accept, and telling it what type it returns for the allowed index keys. In Typescript, it's easy to define an interface that is like what you'd expect from "object" - as others noted in the comments. But this just isn't what this word is for, in Typescript. In Typescript, the specific type object refers to any non primitive. And of course, for when you're feeling lazy or are just indeed going very general, there's always good ol' "any".
It intrigues me that you're frustrated with that coming from C# specifically (first, because I am too, and second, because C#'s static typing is such a strength of it, and third, because I see Typescript as "Javascript translated for static-typed-OOP-languages speakers"). But each to their own I guess.
Do take time with it. Getting used to Javascript, you might just not only get used to this but also see why it's the right thing for Typescript.
BTW sorry for not writing code and formatting. Am currently not near a computer, and using phone.
I feel like the disconnect here comes when we refer to all-purpose, utility functions. It's fine to say that, in TS, an object must be defined as having Properties X with Value Types Y, but that only works when you're trying to write a narrowly-defined function.
In the example I gave, I wanted to know if any two objects share the same key, and the same value stored in that key. In my example, I illustrated two potential "user" objects. But if you look at the code in the JS example, the function doesn't require that each object shares a common set of keys. Nor do I want to constrict the function to only comparing objects that have matching sets of keys.
IMHO, TS starts to become a major PITA when you're trying to write these kinds of utility functions - the kind of functions where you want to process any object.
And sure, you can just slap that
anyon the inputs, but that feels really lame. First, it's lame becauseanywould allow the input to be, say, a number, or a Boolean. But it's also lame because this is the definition of an object from the MDN docs (developer.mozilla.org/en-US/docs/W...If that's the definition in the MDN docs, why do I need to tell TS that a string is an acceptable key for an object???
It's all fine to tightly define object data types through tools like interfaces, but when I have logic that I want to run on a wide array of objects, I shouldn't have to explain to TS that those objects could have strings for keys.