Coding Patterns
Coding patterns we follow on our front end
Last updated
Was this helpful?
Coding patterns we follow on our front end
Last updated
Was this helpful?
We're using (RTK Query) to define our API endpoints and cache the response data.
For each model defined on the back end, create a file named after the model in the directory api
. At the top of the file, define the model on a global level and export it. Use the Model
type constructor.
In addition, the name of each model will need to be registered as a tag in tagTypes
, at api/index.ts
.
If you'd like to define an object containing a subset of a model's fields, you can use Pick
.
When defining the result (i.e. response body) and arg (i.e. request body) for an endpoint, you must define their types as a pair on a global level below the model's type and export them. The result's type should come first, immediately followed by the arg's type. The result & arg types should follow the naming convention {endpoint_name}Result
and {endpoint_name}Arg
. Each result & arg pair should be separated with one newline.
If no data is included in the result or arg, set either to null
.
Documentation coming soon
Endpoints should be defined below the result & arg pairs. Endpoints should be injected into the base API, imported from api/index.ts
. The subset of API endpoints should follow the naming convention {model_name}Api
and be exported as default. In addition, each hook auto-generated from the endpoints should be unpacked and exported as a constant below the default export.
When defining a retrieve endpoint, it's recommended to use the RetrieveResult
and RetrieveArg
type constructors. The endpoint should follow the naming convention retrieve{model_name}
, be defined as a query
, use the method "GET"
, and name the query's arg as id
. To build the URL, the buildUrl
utility should be called, providing the model's detail URL and id as a URL parameter. The tag should be provided by calling the tagData
utility and providing the model's name as an argument.
When defining a list endpoint, it's recommended to use the ListResult
and ListArg
type constructors. The endpoint should follow the naming convention list{model_name_plural}
, be defined as a query
, use the method "GET"
, and name the query's arg as search
. To build the URL, the buildUrl
utility should be called, providing the model's list URL and the search parameters. The tags should be provided by calling the tagData
utility and providing the model's name as an argument and setting includeListTag
to true.
When defining a create endpoint, it's recommended to use the CreateResult
and CreateArg
type constructors. The endpoint should follow the naming convention create{model_name}
, be defined as a mutation
, use the method "POST"
, and name the query's arg as body
. The URL should be set as the model's list URL. The tags should be invalidated by calling the tagData
utility and providing the model's name as an argument and setting includeListTag
to true.
When defining a update endpoint, it's recommended to use the UpdateResult
and UpdateArg
type constructors. The endpoint should follow the naming convention update{model_name}
, be defined as a mutation
, use the method "PATCH"
, and unpack the query's arg as ({ id, ...body })
. To build the URL, the buildUrl
utility should be called, providing the model's detail URL and id as a URL parameter. The tags should be invalidated by calling the tagData
utility and providing the model's name as an argument and setting includeListTag
to true.
When defining a destroy endpoint, it's recommended to use the DestoryResult
and DestroyArg
type constructors. The endpoint should follow the naming convention destroy{model_name}
, be defined as a mutation
, use the method "DELETE"
, and name the query's arg as id
. To build the URL, the buildUrl
utility should be called, providing the model's detail URL and id as a URL parameter. The tags should be invalidated by calling the tagData
utility and providing the model's name as an argument and setting includeListTag
to true.
Documentation coming soon
Documentation coming soon
Documentation coming soon
Documentation coming soon
Documentation coming soon
Documentation coming soon
Documentation coming soon
Documentation coming soon
Documentation coming soon
Documentation coming soon
Documentation coming soon
Documentation coming soon
Documentation coming soon
Documentation coming soon
Documentation coming soon
Documentation coming soon
Documentation coming soon
If the fields of the result or arg are fields of the model, use the Result
and Arg
type constructors. These function similarly to .
If the result and arg are for a , use the default type helper for the specific action. These function similarly to .