Developers warn the new standard could introduce unprecedented uncertainty, while executives praise its flexibility and reduced documentation requirements.
You may need a tagged type. It is done on our code base such that currency of one type can’t be operated on currency of another type. The basic is that TAG<number, 'USD'> !== TAG<number, 'EUR'> because even if the underlying type is the same (number), they are of different types on the type system. See also type-fest library that provide a ton more helper type like that
I don’t know shit about your codebase. But it sounds like you aren’t abstracting your API calls property. Ideally you have an API Client that consumes those blobs and converts them to some generically typed return value.
On top of that you have your actual API, which accepts actions and returns actual objects/collections, or just fucking fails and bubbles up as a generic error because something’s gone fucking wrong.
It’s mainly because, for the industry we’re in, we’re not very big. So we have small teams with few devs…
We also have web, native ios and Android, an internal portal for support staff and cms, all consuming the same dB and many of the same api endpoints. This means they can be undefined for one, but not the other.
So even though on Web you will always have join_table_id… It could be undefined (for another platform)
So, an equivalent to C#'s Type? or Python’s Optional[Type]? That’s still a lot better than nothing. You aren’t going to get an array when you asked for a float, for example.
You still might. Typescript is just a fancy linter, it doesn’t actually stop anything from happening. If a backend API changes to give you an array, you will get an array, and it will be a disaster
“We use TypeScript.”
Every single return and argument type is
any.We use typescript and try very hard not to return any… But 95% of out back ends api returns are
type bob: Type || undefinedSo we have to cater for that almost everywhere and half the time it feels like “strong typing” is a waste of effort.
But I still prefer the relative certainty of typescript
You may need a tagged type. It is done on our code base such that currency of one type can’t be operated on currency of another type. The basic is that
TAG<number, 'USD'> !== TAG<number, 'EUR'>because even if the underlying type is the same (number), they are of different types on the type system. See alsotype-festlibrary that provide a ton more helper type like thatI don’t know shit about your codebase. But it sounds like you aren’t abstracting your API calls property. Ideally you have an API Client that consumes those blobs and converts them to some generically typed return value.
On top of that you have your actual API, which accepts actions and returns actual objects/collections, or just fucking fails and bubbles up as a generic error because something’s gone fucking wrong.
It’s mainly because, for the industry we’re in, we’re not very big. So we have small teams with few devs…
We also have web, native ios and Android, an internal portal for support staff and cms, all consuming the same dB and many of the same api endpoints. This means they can be undefined for one, but not the other.
So even though on Web you will always have
join_table_id… It could be undefined (for another platform)So, an equivalent to C#'s
Type?or Python’sOptional[Type]? That’s still a lot better than nothing. You aren’t going to get an array when you asked for a float, for example.You still might. Typescript is just a fancy linter, it doesn’t actually stop anything from happening. If a backend API changes to give you an array, you will get an array, and it will be a disaster
Project I am on right now did kinda that. “We use typescript”, not a single check flag was turned on. (Neither for ts, nor angular)
What? Cmon’…
Promise<T>
*(okay it isn’t really a sin like any, but I wanted to wedge this into this thread somewhere)
as unknown as anymeanwhile, up above:
async function foo<T=any>(): Promise<T> {