@merl.ooo/api-types

IMPORTANT NOTE: The type definitions should always be up to date with int.api.merl.ooo. This is the integration environment. So releases might be stuck there for some days, before being deployed to production api.merl.ooo. So you should test your frontend agains integration api in order to ensure consistency with type definitions of this packages. Then maybe wait until the new version is deployed to production. Or for your production deployment pin the version number of this package.

NOTE: RestResource types the members createdAt and updatedAt as Dates. But the REST api outputs Dates in ISO 8601 strings. So you have to convert those fields into Dates before the parsed api response will match the RestResource inheriting Types. This is also valid for all Date field specific to a resource.

Installation

npm i -D @merl.ooo/api-types

Usage

// use meta types (RestResource, ...) helpers (Color, ...) and specific Resources (Room, Event, ...)
import type { RestResource, ResourceId, FindQuery, Color, Room, Event, Tag, v1 /*...*/ } from '@merl.ooo/api-types';

// use a specific api version
import type { Room, Event, Tag /*...*/ } from '@merl.ooo/api-types/v1';
// versions are also exported as named (v1, v2) and the current version, so
// if v1 is the latest version, v1.Room and current.Room are identical to Room imported above
import type { v1, current } from '@merl.ooo/api-types';

enums

You can use fixed enums (eg. for event.kind or art event.essentials.status). Don't import those as types (and move it from devDependencies to regular dependencies, eg. leave out the -D when installing):

import { EventKind, ArtEventStatus } from '@merl.ooo/api-types/v1';

console.log(EventKind.art, ArtEventStatus.requested); // art requested

LICENSE

MIT