interface question

[blazing siren]

well

why not make it a class from the start?

[molten tide]

k then whats the point of an interface

[molten tide]

whats the point of an interface then if I can just make everything a class and get that extra safety if I need to add methods

[blazing siren]

e.g. for objects that come over JSON apis

or for types of parameters

or for declaration merging

[molten tide]

wait so if you were creating a model for a REST api you'd never use an interface

[blazing siren]

in case a user wants to add properties to an interface

[molten tide]

this is broad, you can pass basically anything as a parameter though?

[blazing siren]

you'd always use an interface*

[blazing siren]

yeah but it'd be silly passing a class instance just to immediately deconstruct it

[molten tide]

but what if I want to add methods to the model

e.g. this is the js code I got given

[blazing siren]

a bunch of people use functions

what the heck global variable

[molten tide]

did that image load

i hate that code tho fr it's goofy

how would you do it in typescript

[blazing siren]

const products: Product = [];
interface Product { title: string; }
export function saveProduct(product: Product) {
  products.push(product);
}
export function fetchAll() {
  return products;
}

functional :D

[molten tide]

ah ok so its like C

[blazing siren]

you could use a class

[blazing siren]

i mean some people do use classes still

[molten tide]

yeah but u said its bad

plus another question when would you definitely use a class over an interface

[blazing siren]

but if it's already in the right shape and all you'd be doing is manually assinging every single property (potentially slow)

[blazing siren]

when it's not just plain data

e.g. if you want private members

[molten tide]

ok last question bro (ur smart af btw 😮 ) how do u check if an object is an instance of a particular interface

thank u for givng me help btw

bro u there

[blazing siren]

no

rip

[blazing siren]

can't

you have to create the validator using a library like zod or typebox

[molten tide]

sad

[blazing siren]

and call a magic generic type to get the type

[molten tide]

thats f-cked wow

like wtf tho

🤣

[molten tide]

anyways one last question, say I want to create an object of type Product (As u saw prevoiusly), whenever I do it my ide says it's of this type but not Product is that an issue:

(maybe I need to import the Product model? Or use explicit type annotation)

[strong badger]

nothing about this says it's a Product

an explicit type annotation would be that declaration

[blazing siren]

makes sense though, ts doesnt exist at runtime

[molten tide]

ok then, say @strong badger say you were creating a REST api in Node.JS and you wanted to create an object of the model (it's an interface), would you then use an explicit type annotation

[molten tide]

ah ok, wise words

[strong badger]

yes, that's kinda what they're for

[molten tide]

i never saw them used in the documentation tho g

for the interface

like here:

[strong badger]

sidenote; you don't absolutely have to use libraries like zod or typebox to do runtime checks. there's also a library that does an extra step to generate checks from typings, and you could also write typeguards yourself (with the cost of being less safe)

[strong badger]

this is literally just demonstrating interface subtypes

[molten tide]

where dude ?

they didnt use an explicit type annotation for creating myObj

[strong badger]

yeah, because it's illegal

myObj there fulfills LabeledValue, it isn't LabeledValue exactly

that's why it can be passed to printLabel

[molten tide]

k ill need to do more research but thanks for the help so far bud

(me trying to brush off the fact that i just made myself look like an idiot)

[strong badger]

don't worry about it, we all started somewhere lol

[molten tide]

ok one last question when would you not use an explicit type annotation for creating an interface type

[strong badger]

(i couldve probably chosen better phrasing, i didn't mean to be condescending there, sorry)

[molten tide]

yeah true, I come from a java/kotlin so Im finding this confusing

[strong badger]

https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#literal-inference
if this section wasn't about literals, the req example there would be great for an explicit annotation

[strong badger]

hmm, to me this question feels self-answering. if you want to explicitly create the interface, then you'd have to explicitly annotate it, simple as that

[molten tide]

yeah its fine, it wasn't condescending. I dont consider myself a noob to programming but Im new to web development, so you're right on target bud

[molten tide]

k thanks

[strong badger]

when you don't have an annotation, the type gets inferred from the value, and when that's an object, that inferment goes to every key down to primitives unless they're already literals
so imo, if you don't have an annotation, then you're basically just creating an arbitrary object that can get checked later

(personal choice) i prefer being explicit with basically everything so stuff can get checked right where they're created tbh

[molten tide]

'basically everything' so that means also with function return types

[strong badger]

something i took from java's explicitness

yes

i treat all my functions as interfaces, i know what i want them to return

[molten tide]

yeah but the return type for a function is already inferred, and is correct for 99% of the time

[strong badger]

don't want that to go wrong when i don't expect it

[molten tide]

this is weird, my ide is saying it's inferring the type of 'proudct' as {title: any}, but it's still working when being passed to the 'saveProduct' function which takes in a product, what do you have to say about this?

[strong badger]

like if i write a return in the wrong spot, if i resolve something weird from a returned Promise, well, that's just in the return type now.
if the return type is declared, then that new erraneous code can get checked. signatures tend to change a lot less than implementations

[strong badger]

what does saveProduct take exactly

[molten tide]

yeah you have a point. I think the stronger you type the safer you are, and typescript doesn't force you to type really strongly which is something I dont like, thats why I like java since everything is strongly typed

[strong badger]

well, ts is built on js, gotta work with that a bit

[strong badger]

right, what's Product

[strong badger]

any disables typechecking

https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#any

oh wait it's the same Product 💀
i got confused by the use of name above lmao mb

[molten tide]

it didn't infer it of being type 'any'

[strong badger]

but title was

[molten tide]

alg bud, but as I said my ide is saying it's inferred as type { title: any }, so why is it fitting into the function which accept a Product

[blazing siren]

because any bypasses type checking

[strong badger]

provided: { title: any }
expected: { title: string }
{ title: any } assignable to { title: string } ?
  properties `title` present? yes
  properties `title` assignable ?
    any assignable to string? yes
  yes
yes

[molten tide]

wow that's cool

so it's best to use an explicit type annotation for that code then right

[strong badger]

"best" isn't a thing

i'd go with at least some validation, but you do you

it's a quick way to get rid of any, but it's inherently unsafe there because of that

request.body.title might not exist, or it might not be a string

[molten tide]

Understood 🫡

I wish typescript would make it so you create interfaces like this const m = Product { title: "Hi" }

[hybrid crag]

interface Product { title: string; }
function $<T>(it: T): T { return it; }
const m = $<Product>({ title: "Hi" })
//    ^? - const m: Product

[blazing siren]

@molten tide

[strong badger]

jquery trying to sneak back into your codebase

[hybrid crag]

interface Product { title: string; }
const m = <Product> { title: "Hi" }
//    ^? - const m: Product

[blazing siren]

(don't do this one, it's a type assertion which is unsafe)

[molten tide]

ok thanks for that

[strong badger]

that's basically a class at that point

[blazing siren]

but without the overhead

[molten tide]

why? just cause the syntax is different?

[strong badger]

what?

how am i supposed to answer that question

[molten tide]

what question

[strong badger]

why?

[molten tide]

well you said that it's a class just because the syntax changed

[strong badger]

this part

just cause the syntax is different?
is like in response to saying that 2 things are different, but i didn't say that?

[strong badger]

well, first off, no, you can do const ident: Class = ... as well, i didn't say that because syntax changed

but is Product { title: "" } really that far off from new Product({ title: "" }) syntactically

that's what im saying

if you want that sort of pattern, why not just use a class

[molten tide]

idk since using a class is not the typescript way of doing things

[strong badger]

what

what makes you think that?

[molten tide]

because, I believe that most people would recommend you use an interface for a REST api model

and yeah I prefer the class syntax but you should follow what other people are doing

[strong badger]

that's just for transferring data though

the interface is just about sending and receiving data through the api

you still need stuff to operate on the data once you have it

you could do that via FP or OOP patterns

[molten tide]

how much experience do you have with typescript/web dev

wjat you said is out of my league

[strong badger]

js 4 years, rest api consumer 4 years, ts about 6 months i think, rest api designer a lot more sparse

[molten tide]

ah ok, understood.

do u think spring boot is better than node/express

[strong badger]

nope, unless something is really outdated and unmaintained then it's not better or worse than any alternatives, just different

[molten tide]

do u have experience with spring boot

[molten tide]

ah ok, I was about to go through the spring boot route, but I guess node/express is good enough

[strong badger]

nope, sorry

[molten tide]

/close

/channel close

[strong badger]

!resolved/!close

[molten tide]

!close