docs: Events tag #4152
docs: Events tag #4152
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 2 Ignored Deployments
|
src/lib/openapi/spec/event-schema.ts
Outdated
| name: { | ||
| type: 'string', | ||
| }, | ||
| description: { | ||
| type: 'string', | ||
| }, | ||
| type: { | ||
| type: 'string', | ||
| }, | ||
| project: { | ||
| type: 'string', | ||
| }, | ||
| stale: { | ||
| type: 'boolean', | ||
| }, | ||
| variants: { | ||
| type: 'array', | ||
| items: { | ||
| $ref: '#/components/schemas/variantSchema', | ||
| }, | ||
| }, |
There was a problem hiding this comment.
I know these properties are only here to allow the example (or at least that's what I seem to remember), but could we still give them a description? It might be hard because they can vary between events, though 🤔
There was a problem hiding this comment.
Well, I can still give it a go certainly, I can steal with pride from our feature schema 👍
There was a problem hiding this comment.
Sounds good! Just try and make it clear in some way that the descriptions may apply to different things depending on what the event is for
| description: | ||
| 'The api version of this response. A natural increasing number. Only increases if format changes', |
There was a problem hiding this comment.
I'd suggest maybe even adding an enum here, so that we have to explicitly mark it when we bump a version. Makes it easier for users to know what to expect. Also: this needs an example
| description: 'An API versioning number', | ||
| minimum: 1, | ||
| example: 1, |
There was a problem hiding this comment.
Same comment as above regarding enums
| adminRole = rootRoles.find((r) => r.name === RoleName.ADMIN)!!; | ||
| viewerRole = rootRoles.find((r) => r.name === RoleName.VIEWER)!!; |
There was a problem hiding this comment.
Do we need double bangs or is it enough with a single one? Think I saw this somewhere else and that a single one will suffice 💁🏼
There was a problem hiding this comment.
I think I might've inadvertently used Kotlin syntax here. Let me see what the compiler says with a single bang :P
There was a problem hiding this comment.
Indeed, a single bang is enough. Will update.
| type: 'string', | ||
| }, | ||
| type: { | ||
| type: 'string', |
There was a problem hiding this comment.
// I wonder if we can inject the enum type here so we don't have to maintain the list in two places
| type: 'string', | |
| type: 'string', | |
| example: 'APPLICATION_CREATED', |
There was a problem hiding this comment.
Good shout! That should be possible
There was a problem hiding this comment.
Not really, cause it's not the event type, it could be the feature type here.
There was a problem hiding this comment.
The example for our feature-created events has type: 'release' here. So unfortunately, we can't inject the event type enum here.
There was a problem hiding this comment.
maybe we can have a union type for event-type + feature-type, but I think that'd be requesting too much on this PR. This is good for me 👍
|
|
||
| const eventDataSchema = { | ||
| type: 'object', | ||
| additionalProperties: true, |
There was a problem hiding this comment.
Do we have some required properties? Maybe
| additionalProperties: true, | |
| additionalProperties: true, | |
| required: ['name', 'type'], |
There was a problem hiding this comment.
I don't believe we do. There's nothing preventing you from creating an event of {}, if you just want to use the event to trigger some other behaviour.
| @@ -3,115 +3,222 @@ import { FeatureToggle, IStrategyConfig, ITag, IVariant } from './model'; | |||
| import { IApiToken } from './models/api-token'; | |||
| import { IUser } from './user'; | |||
|
|
|||
| export const APPLICATION_CREATED = 'application-created'; | |||
| export const APPLICATION_CREATED = 'application-created' as const; | |||
There was a problem hiding this comment.
| export const FEATURES_EXPORTED = 'features-exported' as const; | ||
| export const FEATURES_IMPORTED = 'features-imported' as const; | ||
|
|
||
| export const IEventTypes = [ |
There was a problem hiding this comment.
@chriswk by making it this strict, we can't build unleash-enterprise, as there are types in enterprise which are not defined here: https://github.com/ivarconr/unleash-enterprise/actions/runs/5473805611/jobs/9967754171 I think we should make it string again
What
This PR adds documentation for our endpoints that are covered by our "Events" tag. It also adds a type for all valid events, and then uses this as valid values for type argument.