Health to the Web

  typeof extract a type from runtime code, typeof "make a type of it" (i.e. from it) e.g.   typeof "Hello world"  => string only legal on variable names can be used with functions or any other expressions aside: typeof vs keyof: keyof takes a type and creates a string/number union of it's keys. So keyof creates a new type from a type ....whereas typeof creates a type from an expression. good post Given a function: const myFunc = (name: string) => {   return `hello ${name}`;    }; type the function into MyFunc type MyFunc =   typeof myFunc; type a function return type (using built in ReturnType ) type MyFuncReturn = ReturnType<typeof myFunc>;  // string When the function changes, the types change! You can also type the parameters using utility type  Parameters      type MyFuncParams = Parameters<typeof myFunc>;  // string but Parameters will return a tuple (array), so you could index result like...

Typescript enums have their uses but are extra hassle when creating new dto instances. I don't think enums are a good fit for working with dtos.  When I try to instantiate a new AutoTagsConfigType instance as mock data for tests, typescript is reporting an error for the  status  field because it's defined as an  ATStatus  enum So setting status to a literal like this is not acceptable to typescript const mockData: AutoTagsConfigType = { status: 'Pending', id: 'd3f963fb-2201-4f5c-ae38-21bf22cec001', name: 'Big Spender', } but setting status as:  status: ATStatus.Pending  does work however that's not very nice to have to do (use the enum type all the time, I prefer using literals) especially if typescript has another way of achieving the same goal (limit status values) using unions if ATStatus is a union not an enum, then setting values literally works as we would like and typescript will only allow set one of those values type ATStatus = ...

Browser fetch is a simple well supported built in http api which we use for some apps at Opentable. But fetch has some differences to typical fetch libraries:  it does not throw for 4xx and 5xx responses, you have to check the ok property and if not true then it's a failed error code you have to call async json() on the response to convert to json (tiny tedium) So a simple wrapper facade over fetch to take care of these would be nice eh! And how about we use Typescript and use built in http types like RequestInit and Response as well as generics. That's what fwap is! and it's now available on npm. Of course our code has unit tests. Yes it's yet another fetch wrapper (yafwap was another name I considered) but it's also a good learning experience (it's the journey as much as the destination maaannnn) All my references are at the bottom of this post and I'm much indebted to those authors How I created: git init and npm init confirm fwap not already used add typ...

I'm a big fan of Alex Rauschmayer and his blog 2Ality  because Alex is a teacher, he shares great information in his posts and free books. Often at a deeper level than many other sources. And he's a trusted resource. We've been using Typescript for all our frontend code since 2018 and the frontend team all appreciate Typescripts benefits. But it's good to take a step back and refresh so I'm reading Alexs' book "Tackling Typescript". Typescript has become more and more popular and more and more positions require it. It's a language every javascript dev should know. Here are my notes on Alexs' book. Alex points out that Typescript identifies errors statically but also that Typescript is also documentation of the code which is also a big plus. Once you're used to Typescript (ts) you really notice the difference when comparing to plan js code...you get much more information in the ts code. Another plus is Typescript is an early adopter of new E...