• JakenVeina@lemm.ee
    1·
    1 year ago

    I like TypeScript less for its ability to categorize my grocery list and more for its ability to stop anyone from putting cyanide on it.

    • DrM@feddit.de
      1·
      1 year ago

      I hate Typescript for promising me that nobody can put cyanide on the list, but in reality it disallows ME from putting cyanide on the list, but everyone else from the outside is still allowed to do so by using the API which is plain JavaScript again

        • DrM@feddit.de
          0·
          1 year ago

          The main problem with JavaScript and TypeScript is that there is such a little entrybarrier to it, that way too many people use it without understanding it. The amount of times that we had major issues in production because someone doesn’t understand TypeScript is not countable anymore and our project went live only 4 months ago.

          For example, when you use nest.js and want to use a boolean value as a query parameter.

          As an example:

          @Get('valueOfMyBoolean')
@ApiQuery(
  {
    name: 'myBoolean',
    type: boolean,
  }
)
myBooleanFunction(
  @Query('myBoolean') myBoolean: boolean
){
  if(myBoolean){
    return 'myBoolean is true';
  }
  return 'myBoolean is false';
}

          You see this code. You don’t see anything wrong with it. The architect looks at it in code review and doesn’t see anything wrong with it. But then you do a GET https://something.com/valueOfMyBoolean?myBoolean=false and you get “myBoolean is true” and if you do typeOf(myBoolean) you will see that, despite you declaring it twice, myBoolean is not a boolean but a string. But when running the unit-tests, myBoolean is a boolean.

          • jpeps@lemmy.world
            1·
            9 months ago

            Typically when creating API interfaces you’d be better off marking the inputs as unknown, and then using something like Zod to validate the types