CODEWITHSUNDEEP
javascriptreactjstypescript
tscrip
tscrip

Reputation: 140

Typescript and REST API response

Let me preface this question by saying that I am fairly new to typescript, but a long time JavaScript developer.

I have an existing JavaScript application that I am looking to transition over to typescript. In the JavaScript app, it makes a rest API call to fetch data, then checks to see if it exists, and then conditionally renders the app. In JavaScript, I can dynamically check to see if Properties exist on the response object and conditionally render that. In typescript, it throws an error because the data is of any type, and it doesn’t know if that property exists or not.

In a typescript application, is it pretty common to go create types for all of your API responses, so that you can get type safety on them? Using node as your backend, I could see a huge opportunity where you might be able to share backend and front end models. I am currently using .net core for my backend, and I am concerned I might be shooting myself in the foot trying to always create typescript models from the entity framework models.

Does anyone else use .net core for the backend and react on the front end? How do you handle API responses in typescript?

Upvotes: 1

Views: 3691

Answers (2)

sam256
sam256

Reputation: 1421

We are using the same stack as you--.Net Core backend/React frontend--with typescript. The way we handle it is by creating types for the objects the backend sends us and then converting the dynamic checkers, like the ones you mention, into user-defined type guards.

So, roughly speaking, for the various data transfer objects the server returns we have a type/type guard pair that looks like this:

// type
export type SomeDto = { someKey: string; someOtherKey: number }
// type guard
export const isSomeDto = (returnedObj: any): returnedObj is SomeDto =>
  returnedObject.someKey && typeof returnedObj === "string"
  returnedObject.someOtherKey && tyepeof returnedObj === "number"

Then we have basically have the following in the fetching code:

const someReturn = fetchDatafromApi(endpoint)
if isSomeDto(someReturn) {
  //now typescript will recognize someReturn as SomeDto
} else {
  // throw or otherwise handle the fact you have bad data from the
  // server
}

This way you get the dynamic checking in javascript at runtime and type safety at compile time. These guards aren't super-fun to write (and you'll want to unit test them all), and I imagine if the possible number of objects was bigger we'd opt for a more automated solution like @Evert mentions in the other answer. But for a few objects, and existing javascript validators, it is a pretty convenient way to get typing on your API returns.

Upvotes: 1

Evert
Evert

Reputation: 99543

I can't tell you if it's common, but we write json-schema files for every endpoint. These schema files are:

  • Used to validate request bodies and generate errors.
  • Used to generate documentation.
  • Converted in to typescript types, which are used in both front- and backend.

Upvotes: 2

Related Questions