Comment by jjakque | Hacker News Reader

Comment by jjakque | Hacker News Reader

Parent Full thread

I've done 2 commercial Typescript + React projects so far (along with few side projects using what I knew that time + what I want to try). My experience been:

- Discourage 'any' but not been afraid of using it when must. I think it as the 'technical debt spelled out': when you want to put down an 'any' and get on with what you're doing, by all mean, but remember its existence and make sure the team is well aware. If the usage going to persist (example, using a library without @type), then you treat it as JS and have appropriate amount of validation around the occurrence.

- Usage of "?" and "!" covers more scopes with less lines of code. For hobby/one-man project, I found their usages no-brainer, however I'm nervous when it comes working in a team of various experience level.

- I've had real headache typing API responses. On one hand, you have absolute no control of others' code quality that you might as well have "number | string | null | undefined" for all parameters. But doing that almost defeats the purpose of typing it, so I'll need to use my educated guesses and judge reliability of each known parameters in responses.

- TypeScript version of 'create-react-app' projects builds slower than its JavaScript counterpart without ejecting. It took 2~6 seconds per build while IIRC, it was <2 seconds for JS. I was keen to find a solution for this, but after a while it grow on me and I simple stop save after each line of code.

- JSDoc is still relevant in TS code. It is great to document event emitters, exceptions etc.

- tslint and prettier are must in my projects in order to retain sanity for unnecessary discussions around coding style.

When it comes to API responses you don't control, I recommend taking a look at user-defined type guards: https://basarat.gitbooks.io/typescript/content/docs/types/ty...

Also, +1 on tslint and prettier, they're great tools.

> type guard

Thanks for the link, I am currently doing something similar without knowing TS implicit behavior.

With 1st given example in the link, I forced on a style to such:

```

function doSomething(x: number | string) { if (typeof x === 'string') { doSomethingForString(x) }

  // Never do catch all to assume all non-strings are numbers
  if (typeof x === 'number') {
    doSomethingForNumber(x)
  }

  // Per transpiler rule, you not meant to be here, so error throwing is appropriate
  throw new Error('Unexpected type')

}

function doSomethingForString(x: string) { // Code }

function doSomethingForNumber(x: number) { // Code }

```

> tslint and prettier are must in my projects

You're probably tired of hearing this by now, but ESLint is the "official" way to go with TS from this point on. It has better integration with Prettier too, since Prettier formatting differences shows as errors/warnings.. and you can share JS/TS rules if needed.

Thanks for pointing this out.

It's simply a matter of time of phasing into preferable setup, consider the current setup is 'not yet broken'.

> Discourage 'any' but not been afraid of using it when must.

I've found that I rarely need `any` anymore. My solution has been `@ts-ignore` (and a warning coming out of tslint for that, to clean up as better typings, etc. arrive) and the `unknown` type, which better encapsulates the "valid" uses of `any`.

> I've had real headache typing API responses.

Swagger and generated library code has made this a lot better in my neck of the woods. It isn't perfect, of course, but it's incrementally better. (Obviously, if you don't own the API, it's harder. Though I've also defined Swagger docs for third-party APIs in the past and generated my own clients, if I understood them well enough.)

TypeScript + GraphQL works really well for typing API responses (assuming you’re in control of the API, of course)

Disclaimer, I work for ApolloGraphQL

I do not work for apollo but I completely concur! I use absinthe on the backend with apollo on the frontend.

incidentally, there any chance of you guys releasing an ios/kotin websocket adapter for phoenix. subscriptions don't currently work because it assumes a different transport later format and phoenix is indesputably the best websocket technology I've worked with. would love to run apollo subscriptions over phoenix channels. it works great on the browser currently

We’ve actually just released a roadmap for rehauling the Apollo Server transport layer, to better support different technologies there. Does https://github.com/apollographql/apollo-server/3184 help you at all?

Or, if this is something that would be implemented client-side, drop an issue over on the iOS client repo, we’ve just brought on a new engineer dedicated to the mobile native clients, she might be able to better help you.

Reply on news.ycombinator.com