Makes more sense. I thought it had to be named index.

I'd also use key or property but index should be just fine as it stands for index signature

Same thing but I use the Record syntax instead. Kinda more pleasing to look at

And it works

Same here 👌

No better time to start

​@@IAmLeslehI think this person wants to finish, not start 😏

Fuck typescript

You should try coding

You sure? type personData = Record; // This will cause a TypeScript error because it doesn't match the declared type function f(obj: personData) { return obj; } f(["3"]) // Argument of type 'string[]' is not assignable to parameter of type 'personData'.Index signature for type 'string' is missing in type 'string[]'.ts(2345)

I assumed you’d be putting the type in a generic (which is usually what you want - if your use case looks like that, it’s probably fine to just use `object` and allow arrays)

You can't pass any object with the type you defined. Thats the whole point of this short.

wouldn't the same apply to the 2 alternate solutions he provided?

You can make your intention more clear by using NonNullable

If you do not want to accept null or undefined then you can configure you typescript's strictNullChecks to true

@@GurjotSingh-no4hxno. Record limits the expectation to an object and not any of the aforementioned primitives

@@alexcoroza4518that’s not the point or intent of what I’m saying

Yea what's the point of using typescript if you don't want to define what the structure looks like lol

I can recommend Matt Pocock for that.

@@FurryDanOriginal ok thnx do ypu happen to know someone for php. Seems i need to learn it anyway.

@@justindouglas3659 Unfortunately no. Outside of some basics, I never needed PHP nor was interested in it. But by searching for PHP tutorials you surely should find a lot of creators and just stick to the one who seems to flow with your prefered style of learning the best.

​@@justindouglas3659 "php for beginners " from laracast channel one of the best php tutorial ever

did you not watch the short?

@bronzekoala9141 like he said everything inherits from object so there's a lot of potential reason to pass one around and there's plenty of room for mistakes due to how unintuitive something as abstract as object is

I agree, not a common mistake. I’ve been writing typescript for 10 years. This is a weird niche case where you want strictly compile time type checking for any object except a Date. I say strictly compile time cause you could always use runtime validation for Date very easily which most cases would likely use. His advice to never use object I find to be questionable advice, and his suggested use of the Record utility type is wrong according to the Typescript team. Record should only be used when you want strictly typed dictionary-like object. If you want to exclude date just use a conditional type: function processObjectWithoutDate(obj: T extends Date ? never : T): void { // Process the object // ... }

maybe it's really uncommon, but still the most common lol

Elaborate

@@TheSaintsVEVO Elaborate on what?

Everybody seems to like it tho

Why?

​@@pepperdayjackpac4521as it gets more views/ more people are curious

yeah. in Angular this is how they type things and it should be on most projects using typescript

@@alexcoroza4518 cheers man, I appreciate your reply.

Using an interface/type/class when you are expecting a specific object type is definitely the best option. In the rare case that you want to accept any object except a Date, instead of using his solution, I recommend using a conditional type: function processObjectWithoutDate(obj: T extends Date ? never : T): void { // Process the object // ... }

There is a spec for js comment annotations is the works, but it’s still some that 3rd parties like TS would read for typing.

just dont mix types and interfaces

You look like a Meghan Markle copycat

You are very welcome!

Unknown will throw an error until you check the type. Any will disable type checking and you don't have to check the type before using whatever you want

If you want a custom type for representing JSON objects in typescript, that provides additional type safety then I recommend the following: type JSONValue = string | number | boolean | null | JSONValue[] | Record;

They are like the exact opposites. Any allows any operation because it could be anything, unknown allows none without narrowing down the type. It’s better to read the documentation and code examples to really get the gist of it

You should only use Record utility type when you want a strictly defined dictionary-like object, so his solution is more of a hack. In his example, it’s a simple case where you want to just exclude the Date type, so using a simple conditional type to exclude Date is the best option: function processObjectWithoutDate(obj: T extends Date ? never : T): void { // Process the object // ... }

Yes, you can also use numbers and symbols: // Using numbers as keys type NumberRecord = Record; const numberObject: NumberRecord = { 1: "One", 2: "Two", 3: "Three" }; // Using symbols as keys const symbolKey1 = Symbol(); const symbolKey2 = Symbol(); type SymbolRecord = Record; const symbolObject: SymbolRecord = { [symbolKey1]: 42, [symbolKey2]: 99 };

Agree 😢😢 especially CSS

Ay man this is so unreadable

@@thecoolnewsguy This is a niche case when you want to accept all types except for a single type, therefore “T extends ? never : T” is exactly the type of readable logic you would want. It doesn’t rely on any unintended behavior to work. It works for multiple cases, not just for Dates. And this is the recommended approach from the Typescript team.

I always love those videos with devs that are spending couple of minutes here and there just to be type safe instead of focusing on the actual code :D. This is priceless…

this comment is harder to discern than trying to find the end of a class name in a java app.

@@inzdvlIf you’ve never had a type error before, you’ve never coded in your life. Also, typing enables autocompletion, so that I can focus on the actual code instead of looking for the documentation every time..

​@@Naej7pretty much any editor can do autocompletion without typescript.

@@juraev0056 How is the editor supposed to know the type of a parameter in a function if the type is not explicitly written ?

key is same as property

​@@birthdayzrock1426Oh, alright. Thank you for the clarification! ❤

Using {} as a type does not represent an empty object. Instead, it represents a type that matches any object shape. In other words, it’s a type that allows for any properties and values. If you’re specifically looking to represent an empty object type, you can use Record or {} along with as const for stricter type inference. Here’s an example: // Using Record const emptyObject1: Record = {}; // Using {} with as const const emptyObject2 = {} as const;

Replace the string with “foo” and unknown with number

Stackoverflow has entered the chat.

{ [index:string]: unknown, “foo”: number } this should work or maybe you have to reverse their order

Record & { foo: number; }

@@Dev-Siri rightttt, i learned yesterday about record, it seems very useful

TypeScript is like an enhanced version of JavaScript. It adds optional static typing to catch errors early, improves coding tools, helps maintain clean and documented code, supports modern features before they’re available in all browsers, and boosts code quality.

Writing frontend in Rust would be a nightmare

Probably a big mess.

They are types, so they are removed when it is compiled to js.

He literally said that lol