Skip to content

Commit df20a90

Browse files
committed
Updated docs
1 parent a3fdeb3 commit df20a90

File tree

1 file changed

+141
-0
lines changed

1 file changed

+141
-0
lines changed

docs/modeling-guide.md

Lines changed: 141 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -138,3 +138,144 @@ type Timestamp = string
138138
type TimeSpan = string
139139
type DateString = string
140140
```
141+
142+
### Literal values
143+
144+
The compiler supports literal values as well. This can be useful if a
145+
definition changes based on a specific field.
146+
147+
```ts
148+
class Foo {
149+
type: 'foo',
150+
prop: string
151+
}
152+
153+
class Bar {
154+
type: 'bar',
155+
prop: boolean
156+
}
157+
158+
type FooOrBar = Foo | Bar
159+
```
160+
161+
The example shown above is the correct way to solve this cases, but to make it
162+
easy to use in every language you need to add a *variant* definition as well.
163+
You can find how it works in the next section.
164+
165+
### Variants
166+
167+
Variants is a special syntax that can be used by language generators to understand
168+
which type they will need to build based on the variant configuration.
169+
There are three type of variants:
170+
171+
#### Internal
172+
173+
The key used as variant is present inside the definition, for example:
174+
175+
```ts
176+
class Foo {
177+
type: 'foo', // 'type' is the variant
178+
prop: string
179+
}
180+
```
181+
182+
If the variant type is internal you should configure the parent type with
183+
the `@variants` js doc tag. teh syntax is:
184+
185+
```ts
186+
/** @variants internal tag='<field-name>' */
187+
```
188+
189+
For example:
190+
191+
```ts
192+
class Foo {
193+
type: 'foo',
194+
prop: string
195+
}
196+
197+
class Bar {
198+
type: 'bar',
199+
prop: boolean
200+
}
201+
202+
/** @variants internal tag='type' */
203+
type FooOrBar = Foo | Bar
204+
```
205+
206+
An example of internal variants are the type mapping properties.
207+
208+
#### External
209+
210+
The key that defines the variant is external to the definition, like in the
211+
case of aggregations in responses or suggesters.
212+
213+
The variant type should be configured in the parent type, while the variant
214+
name in the definition itself.
215+
216+
The syntax is:
217+
218+
```ts
219+
/** @variants external */
220+
221+
/** @variant name='<field-name>' */
222+
```
223+
224+
For example:
225+
226+
```ts
227+
/** @variants external */
228+
type FooAlias = Faz | Bar
229+
230+
/** @variant name='faz' */
231+
class Faz {
232+
prop: string
233+
}
234+
235+
/** @variant name='bar' */
236+
class Bar {
237+
prop: boolean
238+
}
239+
```
240+
241+
In the example above, `FooAlias` will look like this:
242+
243+
```json
244+
{
245+
"faz": {
246+
"prop": "hello world"
247+
}
248+
}
249+
```
250+
251+
or:
252+
253+
```json
254+
{
255+
"bar": {
256+
"prop": true
257+
}
258+
}
259+
```
260+
261+
#### Container
262+
263+
The container variant is used for all the types that contains all the
264+
variants inside the defintion. An example is `QueryContainer`.
265+
266+
The syntax is:
267+
268+
```ts
269+
/** @variants container */
270+
```
271+
272+
For example:
273+
274+
```ts
275+
/** @variants container */
276+
class FooContainer {
277+
bar: BarDefinition
278+
baz: BazDefinition
279+
faz: FazDefinition
280+
}
281+
```

0 commit comments

Comments
 (0)