In this context class is a waste i.e. it isn't carrying its weight. On a personal level I'm not fond of classes as they tend to conflate type space and value space (just like TypeScript does with regular function declarations and expressions)
On introduction I'd go with
// Type definition in the type (TypeScript) spacetypePizza={variant:string;size:string;price:number;extraCheese:boolean;takeAway:boolean;};// Value creation in value (JavaScript) spaceconstmyPizza:Pizza={variant:"Maxican green wave",size:"medium",price:550,extraCheese:true,takeAway:false};console.log(myPizza);
By going with an object literal TypeScript can verify that myPizza conforms with the Pizza type and as a bonus the object properties act as "named parameters". For example variant and size are both string but there is no confusing them as you have to refer to them by name.
Creating Pizza's all over the place I'd move to:
// Type definition in the type (TypeScript) spacetypePizza={variant:string;size:string;price:number;extraCheese:boolean;takeAway:boolean;};typeMakePizza=(variant:string,size:string,price:number,extraCheese:boolean,takeAway:boolean)=>Pizza;// Value creation in value (JavaScript) spaceconstmakePizza:MakePizza=(variant='',size='',price=0,extraCheese=false,takeAway=false)=>{return{variant,size,price,extraCheese,takeAway,};};constmyPizza=makePizza('Mexican green wave','medium',550,true,false);console.log(myPizza);
Now I can mass produce Pizza objects - yet don't have to bother with either new or this (not that they'll slow me down if it came to it).
However there is a trade off by going with a factory function (or a for that matter a constructor) - TypeScript won't be able to detect whether you swapped variant with size or extraCheese with takeAway.
Bottom line: I don't go "class-oriented" until there is a clear benefit - until then I'll stay function-oriented.
classPizza{constructor(publicvariant:string='',publicsize:string='',publicprice:number=0,publicextraCheese:boolean=false,publictakeAway:boolean=false){}}constmyPizza=newPizza('Mexican green wave','medium',550,true,false);console.log(myPizza);
Is it convenient? Perhaps.
Is it correct? Not in my book.
A type is a specification that a value has to conform to, to be considered a member of that type. It's a "target" that should be spelled out in explicit detail separately and prominently - not be buried inside the code that is responsible for creating the value.
I don’t need to remember anything any more. IntelliSense will remember it for me. Besides, I justify to myself, I may not want those 60,000 methods and properties cluttering up my mind. My overall mental health will undoubtedly be better without them, but at the same time I’m prevented from ever achieving a fluid coding style because the coding is not coming entirely from my head. My coding has become a constant dialog with IntelliSense.
So I don’t think IntelliSense is helping us become better programmers. The real objective is for us to become faster programmers, which also means that it’s cheapening our labor.
So if IntelliSense can't keep up - that's its problem . And no, I don't use Visual Code (The IDE Divide).
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.
In this context
class
is a waste i.e. it isn't carrying its weight. On a personal level I'm not fond of classes as they tend to conflate type space and value space (just like TypeScript does with regular function declarations and expressions)On introduction I'd go with
By going with an object literal TypeScript can verify that
myPizza
conforms with thePizza
type and as a bonus the object properties act as "named parameters". For examplevariant
andsize
are bothstring
but there is no confusing them as you have to refer to them by name.Creating
Pizza
's all over the place I'd move to:Now I can mass produce
Pizza
objects - yet don't have to bother with eithernew
orthis
(not that they'll slow me down if it came to it).However there is a trade off by going with a factory function (or a for that matter a constructor) - TypeScript won't be able to detect whether you swapped
variant
withsize
orextraCheese
withtakeAway
.Bottom line: I don't go "class-oriented" until there is a clear benefit - until then I'll stay function-oriented.
As to the issue of not using parameter properties - one could simply write:
Is it convenient? Perhaps.
Is it correct? Not in my book.
A type is a specification that a value has to conform to, to be considered a member of that type. It's a "target" that should be spelled out in explicit detail separately and prominently - not be buried inside the code that is responsible for creating the value.
For all your examples, does intellisense work on each?
Are you familiar with Does Visual Studio Rot the Mind?:
So if IntelliSense can't keep up - that's its problem . And no, I don't use Visual Code (The IDE Divide).