I am using TypeScript myself and, to be frank, at first I thought bad about it. But then I went to a project without any typing and I saw the benefits from static typings :)
One question though. When I work with large objects, for example a response from REST, and doing a model, should I write the entire interface for it? It can have many optional fields, given the quality of the API itself. How should I approach it?
That's a great question, and i'm not sure what the best approach is here. My intuition tells me that
the API response doesn't require an interface, but rather the model/object you create from the API response should be typed. The reason I say this is that you don't have control over fields the API returns, but you do have control over the properties on the model/object that you create from the API response.
Hopefully that wasn't too abstract of an answer and that it made sense.
While I agree with you, when I create a model, I need to know on which fields I can operate. This is a very common problem for me recently as I work with a lot of CMS' and integrate them into our app via modeling.
You do of course need to type what you expect to get in the response and then use within your application. In my experience any unused data needn't be typed...
But this is one situation where IMO typings can give a false sense of security: API responses that are out of your control can (and often will) change unexpectedly - e.g. return null on a property where you don't expect it; so it's still important to have some guards in place to avoid responses that might crash your application.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hey Robert, great article!
I am using TypeScript myself and, to be frank, at first I thought bad about it. But then I went to a project without any typing and I saw the benefits from static typings :)
One question though. When I work with large objects, for example a response from REST, and doing a model, should I write the entire interface for it? It can have many optional fields, given the quality of the API itself. How should I approach it?
That's a great question, and i'm not sure what the best approach is here. My intuition tells me that
the API response doesn't require an interface, but rather the model/object you create from the API response should be typed. The reason I say this is that you don't have control over fields the API returns, but you do have control over the properties on the model/object that you create from the API response.
Hopefully that wasn't too abstract of an answer and that it made sense.
Hey Robert, and thanks for your answer.
While I agree with you, when I create a model, I need to know on which fields I can operate. This is a very common problem for me recently as I work with a lot of CMS' and integrate them into our app via modeling.
You do of course need to type what you expect to get in the response and then use within your application. In my experience any unused data needn't be typed...
But this is one situation where IMO typings can give a false sense of security: API responses that are out of your control can (and often will) change unexpectedly - e.g. return
nullon a property where you don't expect it; so it's still important to have some guards in place to avoid responses that might crash your application.