47 | );
48 | };
49 |
50 | export default Nav;
51 |
--------------------------------------------------------------------------------
/src/components/select-template.tsx:
--------------------------------------------------------------------------------
1 | import React, { FunctionComponent } from "react";
2 | import { TemplateEnum } from "@/lib/prompt-by-template";
3 |
4 | interface ITemplate {
5 | label: string;
6 | value: TemplateEnum;
7 | }
8 |
9 | export const templates: ITemplate[] = [
10 | { label: "Flowchart", value: TemplateEnum.FLOWCHART },
11 | { label: "Mindmap", value: TemplateEnum.MINDMAP },
12 | { label: "Timeline", value: TemplateEnum.TIMELINE },
13 | { label: "User Journey", value: TemplateEnum.USERJOURNEY },
14 | { label: "Entity Relationship", value: TemplateEnum.ENTITYRELATIONSHIP },
15 | { label: "Sequence Diagram", value: TemplateEnum.SEQUENCE },
16 | { label: "State Diagram", value: TemplateEnum.STATE },
17 | // { label: "Class Diagram", value: TemplateEnum.CLASS }, // FIXME: syntax mistake is pretty common for this
18 | ];
19 |
20 | interface ISelectTemplate {
21 | onChange: (e: React.ChangeEvent) => void;
22 | }
23 |
24 | const SelectTemplate: FunctionComponent = ({ onChange }) => {
25 | return (
26 |
33 | );
34 | };
35 |
36 | export default SelectTemplate;
37 |
--------------------------------------------------------------------------------
/src/lib/generate.ts:
--------------------------------------------------------------------------------
1 | import { OpenAI } from "langchain/llms";
2 | import { BaseChain, LLMChain, loadQAMapReduceChain } from "langchain/chains";
3 | import { Document } from "langchain/document";
4 | import { TextLoader } from "langchain/document_loaders";
5 |
6 | import { MarkdownTextSplitter } from "langchain/text_splitter";
7 | import { PromptTemplate } from "langchain";
8 |
9 | export const generate = async ({ input, selectedTemplate }) => {
10 | try {
11 | const model = new OpenAI({ temperature: 0.9 });
12 |
13 | const template =
14 | "{syntax} - {instructions} learn from syntax above and write {template} in mermaid syntax about {input}?";
15 | const prompt = new PromptTemplate({
16 | template,
17 | inputVariables: ["template", "input", "syntax", "instructions"],
18 | });
19 |
20 | const chain = new LLMChain({ llm: model, prompt });
21 |
22 | // @ts-ignore
23 | const syntaxDoc = await import(
24 | `./syntax/${selectedTemplate.toLowerCase()}.md`
25 | );
26 |
27 | const res = await chain.call({
28 | template: selectedTemplate,
29 | input,
30 | syntax: syntaxDoc.default,
31 | instructions: `
32 | - use different shapes, colors and also use icons when possible as mentioned in the doc.
33 | - strict rules: do not add Note and do not explain the code and do not add any additional text except code,
34 | - do not use 'end' syntax
35 | - do not use any parenthesis inside block
36 | `,
37 | });
38 |
39 | return res;
40 | } catch (e) {
41 | console.log("openai:debug", e?.response?.data);
42 | throw e;
43 | }
44 | };
45 |
--------------------------------------------------------------------------------
/src/lib/helpers.ts:
--------------------------------------------------------------------------------
1 | export const sanitizeText = (text: string) => text.trim().replaceAll("\n", " ");
2 |
--------------------------------------------------------------------------------
/src/lib/prompt-by-template.ts:
--------------------------------------------------------------------------------
1 | export enum TemplateEnum {
2 | FLOWCHART = "FLOWCHART",
3 | MINDMAP = "MINDMAP",
4 | TIMELINE = "TIMELINE",
5 | USERJOURNEY = "USERJOURNEY",
6 | CLASS = "CLASS",
7 | ENTITYRELATIONSHIP = "ENTITYRELATIONSHIP",
8 | SEQUENCE = "SEQUENCE",
9 | STATE = "STATE",
10 | }
11 |
12 | const commonRules = `- strict rules: do not add Note and do not explain the code and do not add any additional text except code, do not use 'end' syntax
13 | - do not use any parenthesis inside block`;
14 |
15 | export const promptByTemplate = {
16 | [TemplateEnum.FLOWCHART]: (input: string) => `write flowchart about ${input}
17 | ${commonRules}
18 | eg: correct: C -->|true| D(setLoading), wrong: correct: C -->|true| D(setLoading=>true)
19 | eg: correct: C -->|true| D(axios.post=>'/api/ask', input), wrong: C -->|true| D(axios.post('/api/ask', {input,}))
20 | eg: correct: J -->|text| L[Print 'number is not a prime number'] wrong: J -->|| L[Print 'number is not a prime number']
21 | `,
22 |
23 | [TemplateEnum.MINDMAP]: (input: string) => `write mindmap about ${input}
24 | ${commonRules}
25 | syntax:
26 |
27 | `,
28 | };
29 |
--------------------------------------------------------------------------------
/src/lib/syntax/class.md:
--------------------------------------------------------------------------------
1 | # Class diagrams
2 |
3 | > "In software engineering, a class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, operations (or methods), and the relationships among objects."
4 | >
5 | > \-Wikipedia
6 |
7 | The class diagram is the main building block of object-oriented modeling. It is used for general conceptual modeling of the structure of the application, and for detailed modeling to translate the models into programming code. Class diagrams can also be used for data modeling. The classes in a class diagram represent both the main elements, interactions in the application, and the classes to be programmed.
8 |
9 | Mermaid can render class diagrams.
10 |
11 | ```mermaid-example
12 | ---
13 | title: Animal example
14 | ---
15 | classDiagram
16 | note "From Duck till Zebra"
17 | Animal <|-- Duck
18 | note for Duck "can fly\ncan swim\ncan dive\ncan help in debugging"
19 | Animal <|-- Fish
20 | Animal <|-- Zebra
21 | Animal : +int age
22 | Animal : +String gender
23 | Animal: +isMammal()
24 | Animal: +mate()
25 | class Duck{
26 | +String beakColor
27 | +swim()
28 | +quack()
29 | }
30 | class Fish{
31 | -int sizeInFeet
32 | -canEat()
33 | }
34 | class Zebra{
35 | +bool is_wild
36 | +run()
37 | }
38 | ```
39 |
40 | ```mermaid
41 | ---
42 | title: Animal example
43 | ---
44 | classDiagram
45 | note "From Duck till Zebra"
46 | Animal <|-- Duck
47 | note for Duck "can fly\ncan swim\ncan dive\ncan help in debugging"
48 | Animal <|-- Fish
49 | Animal <|-- Zebra
50 | Animal : +int age
51 | Animal : +String gender
52 | Animal: +isMammal()
53 | Animal: +mate()
54 | class Duck{
55 | +String beakColor
56 | +swim()
57 | +quack()
58 | }
59 | class Fish{
60 | -int sizeInFeet
61 | -canEat()
62 | }
63 | class Zebra{
64 | +bool is_wild
65 | +run()
66 | }
67 | ```
68 |
69 | ## Syntax
70 |
71 | ### Class
72 |
73 | UML provides mechanisms to represent class members, such as attributes and methods, and additional information about them.
74 | A single instance of a class in the diagram contains three compartments:
75 |
76 | - The top compartment contains the name of the class. It is printed in bold and centered, and the first letter is capitalized. It may also contain optional annotation text describing the nature of the class.
77 | - The middle compartment contains the attributes of the class. They are left-aligned and the first letter is lowercase.
78 | - The bottom compartment contains the operations the class can execute. They are also left-aligned and the first letter is lowercase.
79 |
80 | ```mermaid-example
81 | ---
82 | title: Bank example
83 | ---
84 | classDiagram
85 | class BankAccount
86 | BankAccount : +String owner
87 | BankAccount : +Bigdecimal balance
88 | BankAccount : +deposit(amount)
89 | BankAccount : +withdrawal(amount)
90 |
91 | ```
92 |
93 | ```mermaid
94 | ---
95 | title: Bank example
96 | ---
97 | classDiagram
98 | class BankAccount
99 | BankAccount : +String owner
100 | BankAccount : +Bigdecimal balance
101 | BankAccount : +deposit(amount)
102 | BankAccount : +withdrawal(amount)
103 |
104 | ```
105 |
106 | ## Define a class
107 |
108 | There are two ways to define a class:
109 |
110 | - Explicitly using keyword **class** like `class Animal` which would define the Animal class.
111 | - Via a **relationship** which defines two classes at a time along with their relationship. For instance, `Vehicle <|-- Car`.
112 |
113 | ```mermaid-example
114 | classDiagram
115 | class Animal
116 | Vehicle <|-- Car
117 | ```
118 |
119 | ```mermaid
120 | classDiagram
121 | class Animal
122 | Vehicle <|-- Car
123 | ```
124 |
125 | Naming convention: a class name should be composed only of alphanumeric characters (including unicode), and underscores.
126 |
127 | ### Class labels
128 |
129 | In case you need to provide a label for a class, you can use the following syntax:
130 |
131 | ```mermaid-example
132 | classDiagram
133 | class Animal["Animal with a label"]
134 | class Car["Car with *! symbols"]
135 | Animal --> Car
136 | ```
137 |
138 | ```mermaid
139 | classDiagram
140 | class Animal["Animal with a label"]
141 | class Car["Car with *! symbols"]
142 | Animal --> Car
143 | ```
144 |
145 | You can also use backticks to escape special characters in the label:
146 |
147 | ```mermaid-example
148 | classDiagram
149 | class `Animal Class!`
150 | class `Car Class`
151 | `Animal Class!` --> `Car Class`
152 | ```
153 |
154 | ```mermaid
155 | classDiagram
156 | class `Animal Class!`
157 | class `Car Class`
158 | `Animal Class!` --> `Car Class`
159 | ```
160 |
161 | ## Defining Members of a class
162 |
163 | UML provides mechanisms to represent class members such as attributes and methods, as well as additional information about them.
164 |
165 | Mermaid distinguishes between attributes and functions/methods based on if the **parenthesis** `()` are present or not. The ones with `()` are treated as functions/methods, and all others as attributes.
166 |
167 | There are two ways to define the members of a class, and regardless of whichever syntax is used to define the members, the output will still be same. The two different ways are :
168 |
169 | - Associate a member of a class using **:** (colon) followed by member name, useful to define one member at a time. For example:
170 |
171 | ```mermaid-example
172 | classDiagram
173 | class BankAccount
174 | BankAccount : +String owner
175 | BankAccount : +BigDecimal balance
176 | BankAccount : +deposit(amount)
177 | BankAccount : +withdrawal(amount)
178 | ```
179 |
180 | ```mermaid
181 | classDiagram
182 | class BankAccount
183 | BankAccount : +String owner
184 | BankAccount : +BigDecimal balance
185 | BankAccount : +deposit(amount)
186 | BankAccount : +withdrawal(amount)
187 | ```
188 |
189 | - Associate members of a class using **{}** brackets, where members are grouped within curly brackets. Suitable for defining multiple members at once. For example:
190 |
191 | ```mermaid-example
192 | classDiagram
193 | class BankAccount{
194 | +String owner
195 | +BigDecimal balance
196 | +deposit(amount)
197 | +withdrawal(amount)
198 | }
199 | ```
200 |
201 | ```mermaid
202 | classDiagram
203 | class BankAccount{
204 | +String owner
205 | +BigDecimal balance
206 | +deposit(amount)
207 | +withdrawal(amount)
208 | }
209 | ```
210 |
211 | #### Return Type
212 |
213 | Optionally you can end a method/function definition with the data type that will be returned (note: there must be a space between the final `)` and the return type). An example:
214 |
215 | ```mermaid-example
216 | classDiagram
217 | class BankAccount{
218 | +String owner
219 | +BigDecimal balance
220 | +deposit(amount) bool
221 | +withdrawal(amount) int
222 | }
223 | ```
224 |
225 | ```mermaid
226 | classDiagram
227 | class BankAccount{
228 | +String owner
229 | +BigDecimal balance
230 | +deposit(amount) bool
231 | +withdrawal(amount) int
232 | }
233 | ```
234 |
235 | #### Generic Types
236 |
237 | Members can be defined using generic types, such as `List`, for fields, parameters, and return types by enclosing the type within `~` (**tilde**). **Nested** type declarations such as `List>` are supported.
238 |
239 | Generics can be represented as part of a class definition and also in the parameters or the return value of a method/function:
240 |
241 | ```mermaid-example
242 | classDiagram
243 | class Square~Shape~{
244 | int id
245 | List~int~ position
246 | setPoints(List~int~ points)
247 | getPoints() List~int~
248 | }
249 |
250 | Square : -List~string~ messages
251 | Square : +setMessages(List~string~ messages)
252 | Square : +getMessages() List~string~
253 | Square : +getDistanceMatrix() List~List~int~~
254 | ```
255 |
256 | ```mermaid
257 | classDiagram
258 | class Square~Shape~{
259 | int id
260 | List~int~ position
261 | setPoints(List~int~ points)
262 | getPoints() List~int~
263 | }
264 |
265 | Square : -List~string~ messages
266 | Square : +setMessages(List~string~ messages)
267 | Square : +getMessages() List~string~
268 | Square : +getDistanceMatrix() List~List~int~~
269 | ```
270 |
271 | #### Visibility
272 |
273 | To describe the visibility (or encapsulation) of an attribute or method/function that is a part of a class (i.e. a class member), optional notation may be placed before that members' name:
274 |
275 | - `+` Public
276 | - `-` Private
277 | - `#` Protected
278 | - `~` Package/Internal
279 |
280 | > _note_ you can also include additional _classifiers_ to a method definition by adding the following notation to the _end_ of the method, i.e.: after the `()`:
281 | >
282 | > - `*` Abstract e.g.: `someAbstractMethod()*`
283 | > - `$` Static e.g.: `someStaticMethod()$`
284 |
285 | > _note_ you can also include additional _classifiers_ to a field definition by adding the following notation to the end of its name:
286 | >
287 | > - `$` Static e.g.: `String someField$`
288 |
289 | ## Defining Relationship
290 |
291 | A relationship is a general term covering the specific types of logical connections found on class and object diagrams.
292 |
293 | [classA][Arrow][ClassB]
294 |
295 | There are eight different types of relations defined for classes under UML which are currently supported:
296 |
297 | | Type | Description |
298 | | ------- | ------------- |
299 | | `<\|--` | Inheritance |
300 | | `*--` | Composition |
301 | | `o--` | Aggregation |
302 | | `-->` | Association |
303 | | `--` | Link (Solid) |
304 | | `..>` | Dependency |
305 | | `..\|>` | Realization |
306 | | `..` | Link (Dashed) |
307 |
308 | ```mermaid-example
309 | classDiagram
310 | classA <|-- classB
311 | classC *-- classD
312 | classE o-- classF
313 | classG <-- classH
314 | classI -- classJ
315 | classK <.. classL
316 | classM <|.. classN
317 | classO .. classP
318 |
319 | ```
320 |
321 | ```mermaid
322 | classDiagram
323 | classA <|-- classB
324 | classC *-- classD
325 | classE o-- classF
326 | classG <-- classH
327 | classI -- classJ
328 | classK <.. classL
329 | classM <|.. classN
330 | classO .. classP
331 |
332 | ```
333 |
334 | We can use the labels to describe the nature of the relation between two classes. Also, arrowheads can be used in the opposite direction as well:
335 |
336 | ```mermaid-example
337 | classDiagram
338 | classA --|> classB : Inheritance
339 | classC --* classD : Composition
340 | classE --o classF : Aggregation
341 | classG --> classH : Association
342 | classI -- classJ : Link(Solid)
343 | classK ..> classL : Dependency
344 | classM ..|> classN : Realization
345 | classO .. classP : Link(Dashed)
346 |
347 | ```
348 |
349 | ```mermaid
350 | classDiagram
351 | classA --|> classB : Inheritance
352 | classC --* classD : Composition
353 | classE --o classF : Aggregation
354 | classG --> classH : Association
355 | classI -- classJ : Link(Solid)
356 | classK ..> classL : Dependency
357 | classM ..|> classN : Realization
358 | classO .. classP : Link(Dashed)
359 |
360 | ```
361 |
362 | ### Labels on Relations
363 |
364 | It is possible to add label text to a relation:
365 |
366 | [classA][Arrow][ClassB]:LabelText
367 |
368 | ```mermaid-example
369 | classDiagram
370 | classA <|-- classB : implements
371 | classC *-- classD : composition
372 | classE o-- classF : aggregation
373 | ```
374 |
375 | ```mermaid
376 | classDiagram
377 | classA <|-- classB : implements
378 | classC *-- classD : composition
379 | classE o-- classF : aggregation
380 | ```
381 |
382 | ### Two-way relations
383 |
384 | Relations can logically represent an N:M association:
385 |
386 | ```mermaid-example
387 | classDiagram
388 | Animal <|--|> Zebra
389 | ```
390 |
391 | ```mermaid
392 | classDiagram
393 | Animal <|--|> Zebra
394 | ```
395 |
396 | Here is the syntax:
397 |
398 | [Relation Type][Link][Relation Type]
399 |
400 | Where `Relation Type` can be one of:
401 |
402 | | Type | Description |
403 | | ----- | ----------- |
404 | | `<\|` | Inheritance |
405 | | `\*` | Composition |
406 | | `o` | Aggregation |
407 | | `>` | Association |
408 | | `<` | Association |
409 | | `\|>` | Realization |
410 |
411 | And `Link` can be one of:
412 |
413 | | Type | Description |
414 | | ---- | ----------- |
415 | | -- | Solid |
416 | | .. | Dashed |
417 |
418 | ## Cardinality / Multiplicity on relations
419 |
420 | Multiplicity or cardinality in class diagrams indicates the number of instances of one class that can be linked to an instance of the other class. For example, each company will have one or more employees (not zero), and each employee currently works for zero or one companies.
421 |
422 | Multiplicity notations are placed near the end of an association.
423 |
424 | The different cardinality options are :
425 |
426 | - `1` Only 1
427 | - `0..1` Zero or One
428 | - `1..*` One or more
429 | - `*` Many
430 | - `n` n {where n>1}
431 | - `0..n` zero to n {where n>1}
432 | - `1..n` one to n {where n>1}
433 |
434 | Cardinality can be easily defined by placing the text option within quotes `"` before or after a given arrow. For example:
435 |
436 | [classA] "cardinality1" [Arrow] "cardinality2" [ClassB]:LabelText
437 |
438 | ```mermaid-example
439 | classDiagram
440 | Customer "1" --> "*" Ticket
441 | Student "1" --> "1..*" Course
442 | Galaxy --> "many" Star : Contains
443 | ```
444 |
445 | ```mermaid
446 | classDiagram
447 | Customer "1" --> "*" Ticket
448 | Student "1" --> "1..*" Course
449 | Galaxy --> "many" Star : Contains
450 | ```
451 |
452 | ## Annotations on classes
453 |
454 | It is possible to annotate classes with markers to provide additional metadata about the class. This can give a clearer indication about its nature. Some common annotations include:
455 |
456 | - `<>` To represent an Interface class
457 | - `<>` To represent an abstract class
458 | - `<>` To represent a service class
459 | - `<>` To represent an enum
460 |
461 | Annotations are defined within the opening `<<` and closing `>>`. There are two ways to add an annotation to a class, and either way the output will be same:
462 |
463 | - In a **_separate line_** after a class is defined:
464 |
465 | ```mermaid-example
466 | classDiagram
467 | class Shape
468 | <> Shape
469 | Shape : noOfVertices
470 | Shape : draw()
471 | ```
472 |
--------------------------------------------------------------------------------
/src/lib/syntax/entityrelationship.md:
--------------------------------------------------------------------------------
1 | # Entity Relationship Diagrams
2 |
3 | > An entity–relationship model (or ER model) describes interrelated things of interest in a specific domain of knowledge. A basic ER model is composed of entity types (which classify the things of interest) and specifies relationships that can exist between entities (instances of those entity types). Wikipedia.
4 |
5 | Note that practitioners of ER modelling almost always refer to _entity types_ simply as _entities_. For example the `CUSTOMER` entity _type_ would be referred to simply as the `CUSTOMER` entity. This is so common it would be inadvisable to do anything else, but technically an entity is an abstract _instance_ of an entity type, and this is what an ER diagram shows - abstract instances, and the relationships between them. This is why entities are always named using singular nouns.
6 |
7 | Mermaid can render ER diagrams
8 |
9 | ```mermaid-example
10 | ---
11 | title: Order example
12 | ---
13 | erDiagram
14 | CUSTOMER ||--o{ ORDER : places
15 | ORDER ||--|{ LINE-ITEM : contains
16 | CUSTOMER }|..|{ DELIVERY-ADDRESS : uses
17 | ```
18 |
19 | ```mermaid
20 | ---
21 | title: Order example
22 | ---
23 | erDiagram
24 | CUSTOMER ||--o{ ORDER : places
25 | ORDER ||--|{ LINE-ITEM : contains
26 | CUSTOMER }|..|{ DELIVERY-ADDRESS : uses
27 | ```
28 |
29 | Entity names are often capitalised, although there is no accepted standard on this, and it is not required in Mermaid.
30 |
31 | Relationships between entities are represented by lines with end markers representing cardinality. Mermaid uses the most popular crow's foot notation. The crow's foot intuitively conveys the possibility of many instances of the entity that it connects to.
32 |
33 | ER diagrams can be used for various purposes, ranging from abstract logical models devoid of any implementation details, through to physical models of relational database tables. It can be useful to include attribute definitions on ER diagrams to aid comprehension of the purpose and meaning of entities. These do not necessarily need to be exhaustive; often a small subset of attributes is enough. Mermaid allows them to be defined in terms of their _type_ and _name_.
34 |
35 | ```mermaid-example
36 | erDiagram
37 | CUSTOMER ||--o{ ORDER : places
38 | CUSTOMER {
39 | string name
40 | string custNumber
41 | string sector
42 | }
43 | ORDER ||--|{ LINE-ITEM : contains
44 | ORDER {
45 | int orderNumber
46 | string deliveryAddress
47 | }
48 | LINE-ITEM {
49 | string productCode
50 | int quantity
51 | float pricePerUnit
52 | }
53 | ```
54 |
55 | ```mermaid
56 | erDiagram
57 | CUSTOMER ||--o{ ORDER : places
58 | CUSTOMER {
59 | string name
60 | string custNumber
61 | string sector
62 | }
63 | ORDER ||--|{ LINE-ITEM : contains
64 | ORDER {
65 | int orderNumber
66 | string deliveryAddress
67 | }
68 | LINE-ITEM {
69 | string productCode
70 | int quantity
71 | float pricePerUnit
72 | }
73 | ```
74 |
75 | When including attributes on ER diagrams, you must decide whether to include foreign keys as attributes. This probably depends on how closely you are trying to represent relational table structures. If your diagram is a _logical_ model which is not meant to imply a relational implementation, then it is better to leave these out because the associative relationships already convey the way that entities are associated. For example, a JSON data structure can implement a one-to-many relationship without the need for foreign key properties, using arrays. Similarly an object-oriented programming language may use pointers or references to collections. Even for models that are intended for relational implementation, you might decide that inclusion of foreign key attributes duplicates information already portrayed by the relationships, and does not add meaning to entities. Ultimately, it's your choice.
76 |
77 | ## Syntax
78 |
79 | ### Entities and Relationships
80 |
81 | Mermaid syntax for ER diagrams is compatible with PlantUML, with an extension to label the relationship. Each statement consists of the following parts:
82 |
83 | [ : ]
84 |
85 | Where:
86 |
87 | - `first-entity` is the name of an entity. Names must begin with an alphabetic character and may also contain digits, hyphens, and underscores.
88 | - `relationship` describes the way that both entities inter-relate. See below.
89 | - `second-entity` is the name of the other entity.
90 | - `relationship-label` describes the relationship from the perspective of the first entity.
91 |
92 | For example:
93 |
94 | PROPERTY ||--|{ ROOM : contains
95 |
96 | This statement can be read as _a property contains one or more rooms, and a room is part of one and only one property_. You can see that the label here is from the first entity's perspective: a property contains a room, but a room does not contain a property. When considered from the perspective of the second entity, the equivalent label is usually very easy to infer. (Some ER diagrams label relationships from both perspectives, but this is not supported here, and is usually superfluous).
97 |
98 | Only the `first-entity` part of a statement is mandatory. This makes it possible to show an entity with no relationships, which can be useful during iterative construction of diagrams. If any other parts of a statement are specified, then all parts are mandatory.
99 |
100 | ### Relationship Syntax
101 |
102 | The `relationship` part of each statement can be broken down into three sub-components:
103 |
104 | - the cardinality of the first entity with respect to the second,
105 | - whether the relationship confers identity on a 'child' entity
106 | - the cardinality of the second entity with respect to the first
107 |
108 | Cardinality is a property that describes how many elements of another entity can be related to the entity in question. In the above example a `PROPERTY` can have one or more `ROOM` instances associated to it, whereas a `ROOM` can only be associated with one `PROPERTY`. In each cardinality marker there are two characters. The outermost character represents a maximum value, and the innermost character represents a minimum value. The table below summarises possible cardinalities.
109 |
110 | | Value (left) | Value (right) | Meaning |
111 | | :----------: | :-----------: | ----------------------------- |
112 | | `\|o` | `o\|` | Zero or one |
113 | | `\|\|` | `\|\|` | Exactly one |
114 | | `}o` | `o{` | Zero or more (no upper limit) |
115 | | `}\|` | `\|{` | One or more (no upper limit) |
116 |
117 | **Aliases**
118 |
119 | | Value (left) | Value (right) | Alias for |
120 | | :----------: | :-----------: | ------------ |
121 | | one or zero | one or zero | Zero or one |
122 | | zero or one | zero or one | Zero or one |
123 | | one or more | one or more | One or more |
124 | | one or many | one or many | One or more |
125 | | many(1) | many(1) | One or more |
126 | | 1+ | 1+ | One or more |
127 | | zero or more | zero or more | Zero or more |
128 | | zero or many | zero or many | Zero or more |
129 | | many(0) | many(1) | Zero or more |
130 | | 0+ | 0+ | Zero or more |
131 | | only one | only one | Exactly one |
132 | | 1 | 1 | Exactly one |
133 |
134 | ### Identification
135 |
136 | Relationships may be classified as either _identifying_ or _non-identifying_ and these are rendered with either solid or dashed lines respectively. This is relevant when one of the entities in question can not have independent existence without the other. For example a firm that insures people to drive cars might need to store data on `NAMED-DRIVER`s. In modelling this we might start out by observing that a `CAR` can be driven by many `PERSON` instances, and a `PERSON` can drive many `CAR`s - both entities can exist without the other, so this is a non-identifying relationship that we might specify in Mermaid as: `PERSON }|..|{ CAR : "driver"`. Note the two dots in the middle of the relationship that will result in a dashed line being drawn between the two entities. But when this many-to-many relationship is resolved into two one-to-many relationships, we observe that a `NAMED-DRIVER` cannot exist without both a `PERSON` and a `CAR` - the relationships become identifying and would be specified using hyphens, which translate to a solid line:
137 |
138 | **Aliases**
139 |
140 | | Value | Alias for |
141 | | :-----------: | :---------------: |
142 | | to | _identifying_ |
143 | | optionally to | _non-identifying_ |
144 |
145 | ```mermaid-example
146 | erDiagram
147 | CAR ||--o{ NAMED-DRIVER : allows
148 | PERSON ||--o{ NAMED-DRIVER : is
149 | ```
150 |
151 | ```mermaid
152 | erDiagram
153 | CAR ||--o{ NAMED-DRIVER : allows
154 | PERSON ||--o{ NAMED-DRIVER : is
155 | ```
156 |
157 | ### Attributes
158 |
159 | Attributes can be defined for entities by specifying the entity name followed by a block containing multiple `type name` pairs, where a block is delimited by an opening `{` and a closing `}`. The attributes are rendered inside the entity boxes. For example:
160 |
161 | ```mermaid-example
162 | erDiagram
163 | CAR ||--o{ NAMED-DRIVER : allows
164 | CAR {
165 | string registrationNumber
166 | string make
167 | string model
168 | }
169 | PERSON ||--o{ NAMED-DRIVER : is
170 | PERSON {
171 | string firstName
172 | string lastName
173 | int age
174 | }
175 | ```
176 |
177 | ```mermaid
178 | erDiagram
179 | CAR ||--o{ NAMED-DRIVER : allows
180 | CAR {
181 | string registrationNumber
182 | string make
183 | string model
184 | }
185 | PERSON ||--o{ NAMED-DRIVER : is
186 | PERSON {
187 | string firstName
188 | string lastName
189 | int age
190 | }
191 | ```
192 |
193 | The `type` and `name` values must begin with an alphabetic character and may contain digits, hyphens, underscores, parentheses and square brackets. Other than that, there are no restrictions, and there is no implicit set of valid data types.
194 |
195 | #### Attribute Keys and Comments
196 |
197 | Attributes may also have a `key` or comment defined. Keys can be `PK`, `FK` or `UK`, for Primary Key, Foreign Key or Unique Key. To specify multiple key constraints on a single attribute, separate them with a comma (e.g., `PK, FK`).. A `comment` is defined by double quotes at the end of an attribute. Comments themselves cannot have double-quote characters in them.
198 |
199 | ```mermaid-example
200 | erDiagram
201 | CAR ||--o{ NAMED-DRIVER : allows
202 | CAR {
203 | string registrationNumber PK
204 | string make
205 | string model
206 | string[] parts
207 | }
208 | PERSON ||--o{ NAMED-DRIVER : is
209 | PERSON {
210 | string driversLicense PK "The license #"
211 | string(99) firstName "Only 99 characters are allowed"
212 | string lastName
213 | string phone UK
214 | int age
215 | }
216 | NAMED-DRIVER {
217 | string carRegistrationNumber PK, FK
218 | string driverLicence PK, FK
219 | }
220 | MANUFACTURER only one to zero or more CAR : makes
221 | ```
222 |
223 | ```mermaid
224 | erDiagram
225 | CAR ||--o{ NAMED-DRIVER : allows
226 | CAR {
227 | string registrationNumber PK
228 | string make
229 | string model
230 | string[] parts
231 | }
232 | PERSON ||--o{ NAMED-DRIVER : is
233 | PERSON {
234 | string driversLicense PK "The license #"
235 | string(99) firstName "Only 99 characters are allowed"
236 | string lastName
237 | string phone UK
238 | int age
239 | }
240 | NAMED-DRIVER {
241 | string carRegistrationNumber PK, FK
242 | string driverLicence PK, FK
243 | }
244 | MANUFACTURER only one to zero or more CAR : makes
245 | ```
--------------------------------------------------------------------------------
/src/lib/syntax/flowchart.md:
--------------------------------------------------------------------------------
1 | # Flowcharts - Basic Syntax
2 |
3 | All Flowcharts are composed of **nodes**, the geometric shapes and **edges**, the arrows or lines. The mermaid code defines the way that these **nodes** and **edges** are made and interact.
4 |
5 | It can also accommodate different arrow types, multi directional arrows, and linking to and from subgraphs.
6 |
7 | > **Important note**: Do not type the word "end" as a Flowchart node. Capitalize all or any one the letters to keep the flowchart from breaking, i.e, "End" or "END". Or you can apply this [workaround](https://github.com/mermaid-js/mermaid/issues/1444#issuecomment-639528897).
8 |
9 | ### A node (default)
10 |
11 | ```mermaid-example
12 | ---
13 | title: Node
14 | ---
15 | flowchart LR
16 | id
17 | ```
18 |
19 | ```mermaid
20 | ---
21 | title: Node
22 | ---
23 | flowchart LR
24 | id
25 | ```
26 |
27 | > **Note**
28 | > The id is what is displayed in the box.
29 |
30 | ### A node with text
31 |
32 | It is also possible to set text in the box that differs from the id. If this is done several times, it is the last text
33 | found for the node that will be used. Also if you define edges for the node later on, you can omit text definitions. The
34 | one previously defined will be used when rendering the box.
35 |
36 | ```mermaid-example
37 | ---
38 | title: Node with text
39 | ---
40 | flowchart LR
41 | id1[This is the text in the box]
42 | ```
43 |
44 | ```mermaid
45 | ---
46 | title: Node with text
47 | ---
48 | flowchart LR
49 | id1[This is the text in the box]
50 | ```
51 |
52 | ## Graph
53 |
54 | This statement declares the direction of the Flowchart.
55 |
56 | This declares the flowchart is oriented from top to bottom (`TD` or `TB`).
57 |
58 | ```mermaid-example
59 | flowchart TD
60 | Start --> Stop
61 | ```
62 |
63 | ```mermaid
64 | flowchart TD
65 | Start --> Stop
66 | ```
67 |
68 | This declares the flowchart is oriented from left to right (`LR`).
69 |
70 | ```mermaid-example
71 | flowchart LR
72 | Start --> Stop
73 | ```
74 |
75 | ```mermaid
76 | flowchart LR
77 | Start --> Stop
78 | ```
79 |
80 | ## Flowchart Orientation
81 |
82 | Possible FlowChart orientations are:
83 |
84 | - TB - top to bottom
85 | - TD - top-down/ same as top to bottom
86 | - BT - bottom to top
87 | - RL - right to left
88 | - LR - left to right
89 |
90 | ## Node shapes
91 |
92 | ### A node with round edges
93 |
94 | ```mermaid-example
95 | flowchart LR
96 | id1(This is the text in the box)
97 | ```
98 |
99 | ```mermaid
100 | flowchart LR
101 | id1(This is the text in the box)
102 | ```
103 |
104 | ### A stadium-shaped node
105 |
106 | ```mermaid-example
107 | flowchart LR
108 | id1([This is the text in the box])
109 | ```
110 |
111 | ```mermaid
112 | flowchart LR
113 | id1([This is the text in the box])
114 | ```
115 |
116 | ### A node in a subroutine shape
117 |
118 | ```mermaid-example
119 | flowchart LR
120 | id1[[This is the text in the box]]
121 | ```
122 |
123 | ```mermaid
124 | flowchart LR
125 | id1[[This is the text in the box]]
126 | ```
127 |
128 | ### A node in a cylindrical shape
129 |
130 | ```mermaid-example
131 | flowchart LR
132 | id1[(Database)]
133 | ```
134 |
135 | ```mermaid
136 | flowchart LR
137 | id1[(Database)]
138 | ```
139 |
140 | ### A node in the form of a circle
141 |
142 | ```mermaid-example
143 | flowchart LR
144 | id1((This is the text in the circle))
145 | ```
146 |
147 | ```mermaid
148 | flowchart LR
149 | id1((This is the text in the circle))
150 | ```
151 |
152 | ### A node in an asymmetric shape
153 |
154 | ```mermaid-example
155 | flowchart LR
156 | id1>This is the text in the box]
157 | ```
158 |
159 | ```mermaid
160 | flowchart LR
161 | id1>This is the text in the box]
162 | ```
163 |
164 | Currently only the shape above is possible and not its mirror. _This might change with future releases._
165 |
166 | ### A node (rhombus)
167 |
168 | ```mermaid-example
169 | flowchart LR
170 | id1{This is the text in the box}
171 | ```
172 |
173 | ```mermaid
174 | flowchart LR
175 | id1{This is the text in the box}
176 | ```
177 |
178 | ### A hexagon node
179 |
180 | ```mermaid-example
181 | flowchart LR
182 | id1{{This is the text in the box}}
183 | ```
184 |
185 | ```mermaid
186 | flowchart LR
187 | id1{{This is the text in the box}}
188 | ```
189 |
190 | ### Parallelogram
191 |
192 | ```mermaid-example
193 | flowchart TD
194 | id1[/This is the text in the box/]
195 | ```
196 |
197 | ```mermaid
198 | flowchart TD
199 | id1[/This is the text in the box/]
200 | ```
201 |
202 | ### Parallelogram alt
203 |
204 | ```mermaid-example
205 | flowchart TD
206 | id1[\This is the text in the box\]
207 | ```
208 |
209 | ```mermaid
210 | flowchart TD
211 | id1[\This is the text in the box\]
212 | ```
213 |
214 | ### Trapezoid
215 |
216 | ```mermaid-example
217 | flowchart TD
218 | A[/Christmas\]
219 | ```
220 |
221 | ```mermaid
222 | flowchart TD
223 | A[/Christmas\]
224 | ```
225 |
226 | ### Trapezoid alt
227 |
228 | ```mermaid-example
229 | flowchart TD
230 | B[\Go shopping/]
231 | ```
232 |
233 | ```mermaid
234 | flowchart TD
235 | B[\Go shopping/]
236 | ```
237 |
238 | ### Double circle
239 |
240 | ```mermaid-example
241 | flowchart TD
242 | id1(((This is the text in the circle)))
243 | ```
244 |
245 | ```mermaid
246 | flowchart TD
247 | id1(((This is the text in the circle)))
248 | ```
249 |
250 | ## Links between nodes
251 |
252 | Nodes can be connected with links/edges. It is possible to have different types of links or attach a text string to a link.
253 |
254 | ### A link with arrow head
255 |
256 | ```mermaid-example
257 | flowchart LR
258 | A-->B
259 | ```
260 |
261 | ```mermaid
262 | flowchart LR
263 | A-->B
264 | ```
265 |
266 | ### An open link
267 |
268 | ```mermaid-example
269 | flowchart LR
270 | A --- B
271 | ```
272 |
273 | ```mermaid
274 | flowchart LR
275 | A --- B
276 | ```
277 |
278 | ### Text on links
279 |
280 | ```mermaid-example
281 | flowchart LR
282 | A-- This is the text! ---B
283 | ```
284 |
285 | ```mermaid
286 | flowchart LR
287 | A-- This is the text! ---B
288 | ```
289 |
290 | or
291 |
292 | ```mermaid-example
293 | flowchart LR
294 | A---|This is the text|B
295 | ```
296 |
297 | ```mermaid
298 | flowchart LR
299 | A---|This is the text|B
300 | ```
301 |
302 | ### A link with arrow head and text
303 |
304 | ```mermaid-example
305 | flowchart LR
306 | A-->|text|B
307 | ```
308 |
309 | ```mermaid
310 | flowchart LR
311 | A-->|text|B
312 | ```
313 |
314 | or
315 |
316 | ```mermaid-example
317 | flowchart LR
318 | A-- text -->B
319 | ```
320 |
321 | ```mermaid
322 | flowchart LR
323 | A-- text -->B
324 | ```
325 |
326 | ### Dotted link
327 |
328 | ```mermaid-example
329 | flowchart LR
330 | A-.->B;
331 | ```
332 |
333 | ```mermaid
334 | flowchart LR
335 | A-.->B;
336 | ```
337 |
338 | ### Dotted link with text
339 |
340 | ```mermaid-example
341 | flowchart LR
342 | A-. text .-> B
343 | ```
344 |
345 | ```mermaid
346 | flowchart LR
347 | A-. text .-> B
348 | ```
349 |
350 | ### Thick link
351 |
352 | ```mermaid-example
353 | flowchart LR
354 | A ==> B
355 | ```
356 |
357 | ```mermaid
358 | flowchart LR
359 | A ==> B
360 | ```
361 |
362 | ### Thick link with text
363 |
364 | ```mermaid-example
365 | flowchart LR
366 | A == text ==> B
367 | ```
368 |
369 | ```mermaid
370 | flowchart LR
371 | A == text ==> B
372 | ```
373 |
374 | ### An invisible link
375 |
376 | This can be a useful tool in some instances where you want to alter the default positioning of a node.
377 |
378 | ```mermaid-example
379 | flowchart LR
380 | A ~~~ B
381 | ```
382 |
383 | ```mermaid
384 | flowchart LR
385 | A ~~~ B
386 | ```
387 |
388 | ### Chaining of links
389 |
390 | It is possible declare many links in the same line as per below:
391 |
392 | ```mermaid-example
393 | flowchart LR
394 | A -- text --> B -- text2 --> C
395 | ```
396 |
397 | ```mermaid
398 | flowchart LR
399 | A -- text --> B -- text2 --> C
400 | ```
401 |
402 | It is also possible to declare multiple nodes links in the same line as per below:
403 |
404 | ```mermaid-example
405 | flowchart LR
406 | a --> b & c--> d
407 | ```
408 |
409 | ```mermaid
410 | flowchart LR
411 | a --> b & c--> d
412 | ```
413 |
--------------------------------------------------------------------------------
/src/lib/syntax/mindmap.md:
--------------------------------------------------------------------------------
1 | # Mindmap
2 |
3 | "A mind map is a diagram used to visually organize information into a hierarchy, showing relationships among pieces of the whole. It is often created around a single concept, drawn as an image in the center of a blank page, to which associated representations of ideas such as images, words and parts of words are added. Major ideas are connected directly to the central concept, and other ideas branch out from those major ideas." Wikipedia
4 |
5 | ### An example of a mindmap.
6 |
7 | ```mermaid
8 | mindmap
9 | root((mindmap))
10 | Origins
11 | Long history
12 | ::icon(fa fa-book)
13 | Popularisation
14 | British popular psychology author Tony Buzan
15 | Research
16 | On effectiveness and features
17 | On Automatic creation
18 | Uses
19 | Creative techniques
20 | Strategic planning
21 | Argument mapping
22 | Tools
23 | Pen and paper
24 | Mermaid
25 |
26 | ```
27 |
28 | ## Syntax
29 |
30 | The syntax for creating Mindmaps is simple and relies on indentation for setting the levels in the hierarchy.
31 |
32 | In the following example you can see how there are 3 different levels. One with starting at the left of the text and another level with two rows starting at the same column, defining the node A. At the end there is one more level where the text is indented further then the previous lines defining the nodes B and C.
33 |
34 | ```
35 | mindmap
36 | Root
37 | A
38 | B
39 | C
40 | ```
41 |
42 | In summary is a simple text outline where there are one node at the root level called `Root` which has one child `A`. `A` in turn has two children `B`and `C`. In the diagram below we can see this rendered as a mindmap.
43 |
44 | ```mermaid
45 | mindmap
46 | Root
47 | A
48 | B
49 | C
50 | ```
51 |
52 | In this way we can use a text outline to generate a hierarchical mindmap.
53 |
54 | ## Different shapes
55 |
56 | Mermaid mindmaps can show nodes using different shapes. When specifying a shape for a node the syntax is similar to flowchart nodes, with an id followed by the shape definition and with the text within the shape delimiters. Where possible we try/will try to keep the same shapes as for flowcharts, even though they are not all supported from the start.
57 |
58 | Mindmap can show the following shapes:
59 |
60 | ### Square
61 |
62 | ```mermaid-example
63 | mindmap
64 | id[I am a square]
65 | ```
66 |
67 | ### Rounded square
68 |
69 | ```mermaid-example
70 | mindmap
71 | id(I am a rounded square)
72 | ```
73 |
74 | ### Circle
75 |
76 | ```mermaid-example
77 | mindmap
78 | id((I am a circle))
79 | ```
80 |
81 | ### Bang
82 |
83 | ```mermaid-example
84 | mindmap
85 | id))I am a bang((
86 | ```
87 |
88 | ### Cloud
89 |
90 | ```mermaid-example
91 | mindmap
92 | id)I am a cloud(
93 | ```
94 |
95 | ### Hexagon
96 |
97 | ```mermaid-example
98 | mindmap
99 | id{{I am a hexagon}}
100 | ```
101 |
102 | ### Default
103 |
104 | ```mermaid-example
105 | mindmap
106 | I am the default shape
107 | ```
108 |
109 | More shapes will be added, beginning with the shapes available in flowcharts.
110 |
111 | # Icons and classes
112 |
113 | ## Icons
114 |
115 | As with flowcharts you can add icons to your nodes but with an updated syntax. The styling for the font based icons are added during the integration so that they are available for the web page. _This is not something a diagram author can do but has to be done with the site administrator or the integrator_. Once the icon fonts are in place you add them to the mind map nodes using the `::icon()` syntax. You place the classes for the icon within the parenthesis like in the following example where icons for material design and fontawesome 4 are displayed. The intention is that this approach should be used for all diagrams supporting icons. **Experimental feature:** This wider scope is also the reason Mindmaps are experimental as this syntax and approach could change.
116 |
117 | ```mermaid-example
118 | mindmap
119 | Root
120 | A
121 | ::icon(fa fa-book)
122 | B(B)
123 | ::icon(mdi mdi-skull-outline)
124 | ```
125 |
126 | ## Classes
127 |
128 | Again the syntax for adding classes is similar to flowcharts. You can add classes using a triple colon following a number of css classes separated by space. In the following example one of the nodes has two custom classes attached urgent turning the background red and the text white and large increasing the font size:
129 |
130 | ```mermaid-example
131 | mindmap
132 | Root
133 | A[A]
134 | :::urgent large
135 | B(B)
136 | C
137 | ```
138 |
139 | _These classes need to be supplied by the site administrator._
140 |
141 | ## Unclear indentation
142 |
143 | The actual indentation does not really matter only compared with the previous rows. If we take the previous example and disrupt it a little we can se how the calculations are performed. Let us start with placing C with a smaller indentation than `B`but larger then `A`.
144 |
145 | ```
146 | mindmap
147 | Root
148 | A
149 | B
150 | C
151 | ```
152 |
153 | This outline is unclear as `B` clearly is a child of `A` but when we move on to `C` the clarity is lost. `C` is not a child of `B` with a higher indentation nor does it have the same indentation as `B`. The only thing that is clear is that the first node with smaller indentation, indicating a parent, is A. Then Mermaid relies on this known truth and compensates for the unclear indentation and selects `A` as a parent of `C` leading till the same diagram with `B` and `C` as siblings.
154 |
155 | ```mermaid
156 | mindmap
157 | Root
158 | A
159 | B
160 | C
161 | ```
162 |
163 | ## Markdown Strings
164 |
165 | The "Markdown Strings" feature enhances mind maps by offering a more versatile string type, which supports text formatting options such as bold and italics, and automatically wraps text within labels.
166 |
167 | ```mermaid-example
168 | mindmap
169 | id1["`**Root** with
170 | a second line
171 | Unicode works too: 🤓`"]
172 | id2["`The dog in **the** hog... a *very long text* that wraps to a new line`"]
173 | id3[Regular labels still works]
174 | ```
175 |
176 | Formatting:
177 |
178 | - For bold text, use double asterisks \*\* before and after the text.
179 | - For italics, use single asterisks \* before and after the text.
180 | - With traditional strings, you needed to add tags for text to wrap in nodes. However, markdown strings automatically wrap text when it becomes too long and allows you to start a new line by simply using a newline character instead of a tag.
--------------------------------------------------------------------------------
/src/lib/syntax/sequence.md:
--------------------------------------------------------------------------------
1 | # Sequence diagrams
2 |
3 | > A Sequence diagram is an interaction diagram that shows how processes operate with one another and in what order.
4 |
5 | Mermaid can render sequence diagrams.
6 |
7 | ```mermaid-example
8 | sequenceDiagram
9 | Alice->>John: Hello John, how are you?
10 | John-->>Alice: Great!
11 | Alice-)John: See you later!
12 | ```
13 |
14 | ```mermaid
15 | sequenceDiagram
16 | Alice->>John: Hello John, how are you?
17 | John-->>Alice: Great!
18 | Alice-)John: See you later!
19 | ```
20 |
21 | > **Note**
22 | > A note on nodes, the word "end" could potentially break the diagram, due to the way that the mermaid language is scripted.
23 | >
24 | > If unavoidable, one must use parentheses(), quotation marks "", or brackets {},\[], to enclose the word "end". i.e : (end), \[end], {end}.
25 |
26 | ## Syntax
27 |
28 | ### Participants
29 |
30 | The participants can be defined implicitly as in the first example on this page. The participants or actors are
31 | rendered in order of appearance in the diagram source text. Sometimes you might want to show the participants in a
32 | different order than how they appear in the first message. It is possible to specify the actor's order of
33 | appearance by doing the following:
34 |
35 | ```mermaid-example
36 | sequenceDiagram
37 | participant Alice
38 | participant Bob
39 | Alice->>Bob: Hi Bob
40 | Bob->>Alice: Hi Alice
41 | ```
42 |
43 | ```mermaid
44 | sequenceDiagram
45 | participant Alice
46 | participant Bob
47 | Alice->>Bob: Hi Bob
48 | Bob->>Alice: Hi Alice
49 | ```
50 |
51 | ### Actors
52 |
53 | If you specifically want to use the actor symbol instead of a rectangle with text you can do so by using actor statements as per below.
54 |
55 | ```mermaid-example
56 | sequenceDiagram
57 | actor Alice
58 | actor Bob
59 | Alice->>Bob: Hi Bob
60 | Bob->>Alice: Hi Alice
61 | ```
62 |
63 | ```mermaid
64 | sequenceDiagram
65 | actor Alice
66 | actor Bob
67 | Alice->>Bob: Hi Bob
68 | Bob->>Alice: Hi Alice
69 | ```
70 |
71 | ### Aliases
72 |
73 | The actor can have a convenient identifier and a descriptive label.
74 |
75 | ```mermaid-example
76 | sequenceDiagram
77 | participant A as Alice
78 | participant J as John
79 | A->>J: Hello John, how are you?
80 | J->>A: Great!
81 | ```
82 |
83 | ```mermaid
84 | sequenceDiagram
85 | participant A as Alice
86 | participant J as John
87 | A->>J: Hello John, how are you?
88 | J->>A: Great!
89 | ```
90 |
91 | ### Grouping / Box
92 |
93 | The actor(s) can be grouped in vertical boxes. You can define a color (if not, it will be transparent) and/or a descriptive label using the following notation:
94 |
95 | box Aqua Group Description
96 | ... actors ...
97 | end
98 | box Group without description
99 | ... actors ...
100 | end
101 | box rgb(33,66,99)
102 | ... actors ...
103 | end
104 |
105 | > **Note**
106 | > If your group name is a color you can force the color to be transparent:
107 |
108 | box transparent Aqua
109 | ... actors ...
110 | end
111 |
112 | ```mermaid-example
113 | sequenceDiagram
114 | box Purple Alice & John
115 | participant A
116 | participant J
117 | end
118 | box Another Group
119 | participant B
120 | participant C
121 | end
122 | A->>J: Hello John, how are you?
123 | J->>A: Great!
124 | A->>B: Hello Bob, how is Charly ?
125 | B->>C: Hello Charly, how are you?
126 | ```
127 |
128 | ```mermaid
129 | sequenceDiagram
130 | box Purple Alice & John
131 | participant A
132 | participant J
133 | end
134 | box Another Group
135 | participant B
136 | participant C
137 | end
138 | A->>J: Hello John, how are you?
139 | J->>A: Great!
140 | A->>B: Hello Bob, how is Charly ?
141 | B->>C: Hello Charly, how are you?
142 | ```
143 |
144 | ## Messages
145 |
146 | Messages can be of two displayed either solid or with a dotted line.
147 |
148 | [Actor][Arrow][Actor]:Message text
149 |
150 | There are six types of arrows currently supported:
151 |
152 | | Type | Description |
153 | | ------ | ------------------------------------------------ |
154 | | `->` | Solid line without arrow |
155 | | `-->` | Dotted line without arrow |
156 | | `->>` | Solid line with arrowhead |
157 | | `-->>` | Dotted line with arrowhead |
158 | | `-x` | Solid line with a cross at the end |
159 | | `--x` | Dotted line with a cross at the end. |
160 | | `-)` | Solid line with an open arrow at the end (async) |
161 | | `--)` | Dotted line with a open arrow at the end (async) |
162 |
163 | ## Activations
164 |
165 | It is possible to activate and deactivate an actor. (de)activation can be dedicated declarations:
166 |
167 | ```mermaid-example
168 | sequenceDiagram
169 | Alice->>John: Hello John, how are you?
170 | activate John
171 | John-->>Alice: Great!
172 | deactivate John
173 | ```
174 |
175 | ```mermaid
176 | sequenceDiagram
177 | Alice->>John: Hello John, how are you?
178 | activate John
179 | John-->>Alice: Great!
180 | deactivate John
181 | ```
182 |
183 | There is also a shortcut notation by appending `+`/`-` suffix to the message arrow:
184 |
185 | ```mermaid-example
186 | sequenceDiagram
187 | Alice->>+John: Hello John, how are you?
188 | John-->>-Alice: Great!
189 | ```
190 |
191 | ```mermaid
192 | sequenceDiagram
193 | Alice->>+John: Hello John, how are you?
194 | John-->>-Alice: Great!
195 | ```
196 |
197 | Activations can be stacked for same actor:
198 |
199 | ```mermaid-example
200 | sequenceDiagram
201 | Alice->>+John: Hello John, how are you?
202 | Alice->>+John: John, can you hear me?
203 | John-->>-Alice: Hi Alice, I can hear you!
204 | John-->>-Alice: I feel great!
205 | ```
206 |
207 | ```mermaid
208 | sequenceDiagram
209 | Alice->>+John: Hello John, how are you?
210 | Alice->>+John: John, can you hear me?
211 | John-->>-Alice: Hi Alice, I can hear you!
212 | John-->>-Alice: I feel great!
213 | ```
214 |
215 | ## Notes
216 |
217 | It is possible to add notes to a sequence diagram. This is done by the notation
218 | Note \[ right of | left of | over ] \[Actor]: Text in note content
219 |
220 | See the example below:
221 |
222 | ```mermaid-example
223 | sequenceDiagram
224 | participant John
225 | Note right of John: Text in note
226 | ```
227 |
228 | ```mermaid
229 | sequenceDiagram
230 | participant John
231 | Note right of John: Text in note
232 | ```
233 |
234 | It is also possible to create notes spanning two participants:
235 |
236 | ```mermaid-example
237 | sequenceDiagram
238 | Alice->John: Hello John, how are you?
239 | Note over Alice,John: A typical interaction
240 | ```
241 |
242 | ```mermaid
243 | sequenceDiagram
244 | Alice->John: Hello John, how are you?
245 | Note over Alice,John: A typical interaction
246 | ```
247 |
248 | It is also possible to add a line break (applies to text input in general):
249 |
250 | ```mermaid-example
251 | sequenceDiagram
252 | Alice->John: Hello John, how are you?
253 | Note over Alice,John: A typical interaction But now in two lines
254 | ```
255 |
256 | ```mermaid
257 | sequenceDiagram
258 | Alice->John: Hello John, how are you?
259 | Note over Alice,John: A typical interaction But now in two lines
260 | ```
261 |
262 | ## Loops
263 |
264 | It is possible to express loops in a sequence diagram. This is done by the notation
265 |
266 | loop Loop text
267 | ... statements ...
268 | end
269 |
270 | See the example below:
271 |
272 | ```mermaid-example
273 | sequenceDiagram
274 | Alice->John: Hello John, how are you?
275 | loop Every minute
276 | John-->Alice: Great!
277 | end
278 | ```
279 |
280 | ```mermaid
281 | sequenceDiagram
282 | Alice->John: Hello John, how are you?
283 | loop Every minute
284 | John-->Alice: Great!
285 | end
286 | ```
287 |
288 | ## Alt
289 |
290 | It is possible to express alternative paths in a sequence diagram. This is done by the notation
291 |
292 | alt Describing text
293 | ... statements ...
294 | else
295 | ... statements ...
296 | end
297 |
298 | or if there is sequence that is optional (if without else).
299 |
300 | opt Describing text
301 | ... statements ...
302 | end
303 |
304 | See the example below:
305 |
306 | ```mermaid-example
307 | sequenceDiagram
308 | Alice->>Bob: Hello Bob, how are you?
309 | alt is sick
310 | Bob->>Alice: Not so good :(
311 | else is well
312 | Bob->>Alice: Feeling fresh like a daisy
313 | end
314 | opt Extra response
315 | Bob->>Alice: Thanks for asking
316 | end
317 | ```
318 |
319 | ```mermaid
320 | sequenceDiagram
321 | Alice->>Bob: Hello Bob, how are you?
322 | alt is sick
323 | Bob->>Alice: Not so good :(
324 | else is well
325 | Bob->>Alice: Feeling fresh like a daisy
326 | end
327 | opt Extra response
328 | Bob->>Alice: Thanks for asking
329 | end
330 | ```
331 |
332 | ## Parallel
333 |
334 | It is possible to show actions that are happening in parallel.
335 |
336 | This is done by the notation
337 |
338 | par [Action 1]
339 | ... statements ...
340 | and [Action 2]
341 | ... statements ...
342 | and [Action N]
343 | ... statements ...
344 | end
345 |
346 | See the example below:
347 |
348 | ```mermaid-example
349 | sequenceDiagram
350 | par Alice to Bob
351 | Alice->>Bob: Hello guys!
352 | and Alice to John
353 | Alice->>John: Hello guys!
354 | end
355 | Bob-->>Alice: Hi Alice!
356 | John-->>Alice: Hi Alice!
357 | ```
358 |
359 | ```mermaid
360 | sequenceDiagram
361 | par Alice to Bob
362 | Alice->>Bob: Hello guys!
363 | and Alice to John
364 | Alice->>John: Hello guys!
365 | end
366 | Bob-->>Alice: Hi Alice!
367 | John-->>Alice: Hi Alice!
368 | ```
369 |
370 | It is also possible to nest parallel blocks.
371 |
372 | ```mermaid-example
373 | sequenceDiagram
374 | par Alice to Bob
375 | Alice->>Bob: Go help John
376 | and Alice to John
377 | Alice->>John: I want this done today
378 | par John to Charlie
379 | John->>Charlie: Can we do this today?
380 | and John to Diana
381 | John->>Diana: Can you help us today?
382 | end
383 | end
384 | ```
385 |
386 | ```mermaid
387 | sequenceDiagram
388 | par Alice to Bob
389 | Alice->>Bob: Go help John
390 | and Alice to John
391 | Alice->>John: I want this done today
392 | par John to Charlie
393 | John->>Charlie: Can we do this today?
394 | and John to Diana
395 | John->>Diana: Can you help us today?
396 | end
397 | end
398 | ```
399 |
400 | ## Critical Region
401 |
402 | It is possible to show actions that must happen automatically with conditional handling of circumstances.
403 |
404 | This is done by the notation
405 |
406 | critical [Action that must be performed]
407 | ... statements ...
408 | option [Circumstance A]
409 | ... statements ...
410 | option [Circumstance B]
411 | ... statements ...
412 | end
413 |
414 | See the example below:
415 |
416 | ```mermaid-example
417 | sequenceDiagram
418 | critical Establish a connection to the DB
419 | Service-->DB: connect
420 | option Network timeout
421 | Service-->Service: Log error
422 | option Credentials rejected
423 | Service-->Service: Log different error
424 | end
425 | ```
--------------------------------------------------------------------------------
/src/lib/syntax/state.md:
--------------------------------------------------------------------------------
1 | # State diagrams
2 |
3 | > "A state diagram is a type of diagram used in computer science and related fields to describe the behavior of systems.
4 | > State diagrams require that the system described is composed of a finite number of states; sometimes, this is indeed the
5 | > case, while at other times this is a reasonable abstraction." Wikipedia
6 |
7 | Mermaid can render state diagrams. The syntax tries to be compliant with the syntax used in plantUml as this will make
8 | it easier for users to share diagrams between mermaid and plantUml.
9 |
10 | ```mermaid-example
11 | ---
12 | title: Simple sample
13 | ---
14 | stateDiagram-v2
15 | [*] --> Still
16 | Still --> [*]
17 |
18 | Still --> Moving
19 | Moving --> Still
20 | Moving --> Crash
21 | Crash --> [*]
22 | ```
23 |
24 | ```mermaid
25 | ---
26 | title: Simple sample
27 | ---
28 | stateDiagram-v2
29 | [*] --> Still
30 | Still --> [*]
31 |
32 | Still --> Moving
33 | Moving --> Still
34 | Moving --> Crash
35 | Crash --> [*]
36 | ```
37 |
38 | Older renderer:
39 |
40 | ```mermaid-example
41 | stateDiagram
42 | [*] --> Still
43 | Still --> [*]
44 |
45 | Still --> Moving
46 | Moving --> Still
47 | Moving --> Crash
48 | Crash --> [*]
49 | ```
50 |
51 | ```mermaid
52 | stateDiagram
53 | [*] --> Still
54 | Still --> [*]
55 |
56 | Still --> Moving
57 | Moving --> Still
58 | Moving --> Crash
59 | Crash --> [*]
60 | ```
61 |
62 | In state diagrams systems are described in terms of _states_ and how one _state_ can change to another _state_ via
63 | a _transition._ The example diagram above shows three states: **Still**, **Moving** and **Crash**. You start in the
64 | **Still** state. From **Still** you can change to the **Moving** state. From **Moving** you can change either back to the **Still** state or to
65 | the **Crash** state. There is no transition from **Still** to **Crash**. (You can't crash if you're still.)
66 |
67 | ## States
68 |
69 | A state can be declared in multiple ways. The simplest way is to define a state with just an id:
70 |
71 | ```mermaid-example
72 | stateDiagram-v2
73 | stateId
74 | ```
75 |
76 | ```mermaid
77 | stateDiagram-v2
78 | stateId
79 | ```
80 |
81 | Another way is by using the state keyword with a description as per below:
82 |
83 | ```mermaid-example
84 | stateDiagram-v2
85 | state "This is a state description" as s2
86 | ```
87 |
88 | ```mermaid
89 | stateDiagram-v2
90 | state "This is a state description" as s2
91 | ```
92 |
93 | Another way to define a state with a description is to define the state id followed by a colon and the description:
94 |
95 | ```mermaid-example
96 | stateDiagram-v2
97 | s2 : This is a state description
98 | ```
99 |
100 | ```mermaid
101 | stateDiagram-v2
102 | s2 : This is a state description
103 | ```
104 |
105 | ## Transitions
106 |
107 | Transitions are path/edges when one state passes into another. This is represented using text arrow, "-->".
108 |
109 | When you define a transition between two states and the states are not already defined, the undefined states are defined
110 | with the id from the transition. You can later add descriptions to states defined this way.
111 |
112 | ```mermaid-example
113 | stateDiagram-v2
114 | s1 --> s2
115 | ```
116 |
117 | ```mermaid
118 | stateDiagram-v2
119 | s1 --> s2
120 | ```
121 |
122 | It is possible to add text to a transition to describe what it represents:
123 |
124 | ```mermaid-example
125 | stateDiagram-v2
126 | s1 --> s2: A transition
127 | ```
128 |
129 | ```mermaid
130 | stateDiagram-v2
131 | s1 --> s2: A transition
132 | ```
133 |
134 | ## Start and End
135 |
136 | There are two special states indicating the start and stop of the diagram. These are written with the \[\*] syntax and
137 | the direction of the transition to it defines it either as a start or a stop state.
138 |
139 | ```mermaid-example
140 | stateDiagram-v2
141 | [*] --> s1
142 | s1 --> [*]
143 | ```
144 |
145 | ```mermaid
146 | stateDiagram-v2
147 | [*] --> s1
148 | s1 --> [*]
149 | ```
150 |
151 | ## Composite states
152 |
153 | In a real world use of state diagrams you often end up with diagrams that are multidimensional as one state can
154 | have several internal states. These are called composite states in this terminology.
155 |
156 | In order to define a composite state you need to use the state keyword followed by an id and the body of the composite
157 | state between {}. See the example below:
158 |
159 | ```mermaid-example
160 | stateDiagram-v2
161 | [*] --> First
162 | state First {
163 | [*] --> second
164 | second --> [*]
165 | }
166 | ```
167 |
168 | ```mermaid
169 | stateDiagram-v2
170 | [*] --> First
171 | state First {
172 | [*] --> second
173 | second --> [*]
174 | }
175 | ```
176 |
177 | You can do this in several layers:
178 |
179 | ```mermaid-example
180 | stateDiagram-v2
181 | [*] --> First
182 |
183 | state First {
184 | [*] --> Second
185 |
186 | state Second {
187 | [*] --> second
188 | second --> Third
189 |
190 | state Third {
191 | [*] --> third
192 | third --> [*]
193 | }
194 | }
195 | }
196 | ```
197 |
198 | ```mermaid
199 | stateDiagram-v2
200 | [*] --> First
201 |
202 | state First {
203 | [*] --> Second
204 |
205 | state Second {
206 | [*] --> second
207 | second --> Third
208 |
209 | state Third {
210 | [*] --> third
211 | third --> [*]
212 | }
213 | }
214 | }
215 | ```
--------------------------------------------------------------------------------
/src/lib/syntax/timeline.md:
--------------------------------------------------------------------------------
1 | # Timeline Diagram
2 |
3 | "A timeline is a type of diagram used to illustrate a chronology of events, dates, or periods of time. It is usually presented graphically to indicate the passing of time, and it is usually organized chronologically. A basic timeline presents a list of events in chronological order, usually using dates as markers. A timeline can also be used to show the relationship between events, such as the relationship between the events of a person's life." Wikipedia
4 |
5 | ### An example of a timeline.
6 |
7 | ```mermaid-example
8 | timeline
9 | title History of Social Media Platform
10 | 2002 : LinkedIn
11 | 2004 : Facebook
12 | : Google
13 | 2005 : Youtube
14 | 2006 : Twitter
15 | ```
16 |
17 | ```mermaid
18 | timeline
19 | title History of Social Media Platform
20 | 2002 : LinkedIn
21 | 2004 : Facebook
22 | : Google
23 | 2005 : Youtube
24 | 2006 : Twitter
25 | ```
26 |
27 | ## Syntax
28 |
29 | The syntax for creating Timeline diagram is simple. You always start with the `timeline` keyword to let mermaid know that you want to create a timeline diagram.
30 |
31 | After that there is a possibility to add a title to the timeline. This is done by adding a line with the keyword `title` followed by the title text.
32 |
33 | Then you add the timeline data, where you always start with a time period, followed by a colon and then the text for the event. Optionally you can add a second colon and then the text for the event. So, you can have one or more events per time period.
34 |
35 | ```
36 | {time period} : {event}
37 | ```
38 |
39 | or
40 |
41 | ```
42 | {time period} : {event} : {event}
43 | ```
44 |
45 | or
46 |
47 | ```
48 | {time period} : {event}
49 | : {event}
50 | : {event}
51 | ```
52 |
53 | NOTE: Both time period and event are simple text, and not limited to numbers.
54 |
55 | Let us look at the syntax for the example above.
56 |
57 | ```mermaid-example
58 | timeline
59 | title History of Social Media Platform
60 | 2002 : LinkedIn
61 | 2004 : Facebook : Google
62 | 2005 : Youtube
63 | 2006 : Twitter
64 | ```
65 |
66 | ```mermaid
67 | timeline
68 | title History of Social Media Platform
69 | 2002 : LinkedIn
70 | 2004 : Facebook : Google
71 | 2005 : Youtube
72 | 2006 : Twitter
73 | ```
74 |
75 | In this way we can use a text outline to generate a timeline diagram.
76 |
77 | ## Grouping of time periods in sections/ages
78 |
79 | ```mermaid-example
80 | timeline
81 | title Timeline of Industrial Revolution
82 | section 17th-20th century
83 | Industry 1.0 : Machinery, Water power, Steam power
84 | Industry 2.0 : Electricity, Internal combustion engine, Mass production
85 | Industry 3.0 : Electronics, Computers, Automation
86 | section 21st century
87 | Industry 4.0 : Internet, Robotics, Internet of Things
88 | Industry 5.0 : Artificial intelligence, Big data,3D printing
89 | ```
90 |
91 | ```mermaid
92 | timeline
93 | title Timeline of Industrial Revolution
94 | section 17th-20th century
95 | Industry 1.0 : Machinery, Water power, Steam power
96 | Industry 2.0 : Electricity, Internal combustion engine, Mass production
97 | Industry 3.0 : Electronics, Computers, Automation
98 | section 21st century
99 | Industry 4.0 : Internet, Robotics, Internet of Things
100 | Industry 5.0 : Artificial intelligence, Big data,3D printing
101 | ```
102 |
103 | ## Wrapping of text for long time-periods or events
104 |
105 | ```mermaid-example
106 | timeline
107 | title England's History Timeline
108 | section Stone Age
109 | 7600 BC : Britain's oldest known house was built in Orkney, Scotland
110 | 6000 BC : Sea levels rise and Britain becomes an island. The people who live here are hunter-gatherers.
111 | section Broze Age
112 | 2300 BC : People arrive from Europe and settle in Britain. They bring farming and metalworking.
113 | : New styles of pottery and ways of burying the dead appear.
114 | 2200 BC : The last major building works are completed at Stonehenge. People now bury their dead in stone circles.
115 | : The first metal objects are made in Britain.Some other nice things happen. it is a good time to be alive.
116 |
117 | ```
118 |
119 | ```mermaid
120 | timeline
121 | title England's History Timeline
122 | section Stone Age
123 | 7600 BC : Britain's oldest known house was built in Orkney, Scotland
124 | 6000 BC : Sea levels rise and Britain becomes an island. The people who live here are hunter-gatherers.
125 | section Broze Age
126 | 2300 BC : People arrive from Europe and settle in Britain. They bring farming and metalworking.
127 | : New styles of pottery and ways of burying the dead appear.
128 | 2200 BC : The last major building works are completed at Stonehenge. People now bury their dead in stone circles.
129 | : The first metal objects are made in Britain.Some other nice things happen. it is a good time to be alive.
130 |
131 | ```
132 |
133 | ```mermaid-example
134 | timeline
135 | title MermaidChart 2023 Timeline
136 | section 2023 Q1 Release Personal Tier
137 | Buttet 1 : sub-point 1a : sub-point 1b
138 | : sub-point 1c
139 | Bullet 2 : sub-point 2a : sub-point 2b
140 | section 2023 Q2 Release XYZ Tier
141 | Buttet 3 : sub-point 3a : sub-point 3b
142 | : sub-point 3c
143 | Bullet 4 : sub-point 4a : sub-point 4b
144 | ```
145 |
146 | ```mermaid
147 | timeline
148 | title MermaidChart 2023 Timeline
149 | section 2023 Q1 Release Personal Tier
150 | Buttet 1 : sub-point 1a : sub-point 1b
151 | : sub-point 1c
152 | Bullet 2 : sub-point 2a : sub-point 2b
153 | section 2023 Q2 Release XYZ Tier
154 | Buttet 3 : sub-point 3a : sub-point 3b
155 | : sub-point 3c
156 | Bullet 4 : sub-point 4a : sub-point 4b
157 | ```
--------------------------------------------------------------------------------
/src/lib/syntax/userjourney.md:
--------------------------------------------------------------------------------
1 | # User Journey Diagram
2 |
3 | > User journeys describe at a high level of detail exactly what steps different users take to complete a specific task within a system, application or website. This technique shows the current (as-is) user workflow, and reveals areas of improvement for the to-be workflow. (Wikipedia)
4 |
5 | Mermaid can render user journey diagrams:
6 |
7 | ```mermaid-example
8 | journey
9 | title My working day
10 | section Go to work
11 | Make tea: 5: Me
12 | Go upstairs: 3: Me
13 | Do work: 1: Me, Cat
14 | section Go home
15 | Go downstairs: 5: Me
16 | Sit down: 5: Me
17 | ```
18 |
19 | ```mermaid
20 | journey
21 | title My working day
22 | section Go to work
23 | Make tea: 5: Me
24 | Go upstairs: 3: Me
25 | Do work: 1: Me, Cat
26 | section Go home
27 | Go downstairs: 5: Me
28 | Sit down: 5: Me
29 | ```
30 |
31 | Each user journey is split into sections, these describe the part of the task
32 | the user is trying to complete.
33 |
34 | Tasks syntax is `Task name: : `
--------------------------------------------------------------------------------
/src/pages/_app.tsx:
--------------------------------------------------------------------------------
1 | import '@/styles/globals.css'
2 | import type { AppProps } from 'next/app'
3 |
4 | export default function App({ Component, pageProps }: AppProps) {
5 | return
6 | }
7 |
--------------------------------------------------------------------------------
/src/pages/_document.tsx:
--------------------------------------------------------------------------------
1 | import { Html, Head, Main, NextScript } from 'next/document'
2 |
3 | export default function Document() {
4 | return (
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 | )
13 | }
14 |
--------------------------------------------------------------------------------
/src/pages/api/ask.ts:
--------------------------------------------------------------------------------
1 | import { OpenAI } from "langchain";
2 | import { NextApiRequest, NextApiResponse } from "next";
3 | import { HumanChatMessage, SystemChatMessage } from "langchain/schema";
4 | import { ChatOpenAI } from "langchain/chat_models";
5 | import { sanitizeText } from "@/lib/helpers";
6 | import { promptByTemplate, TemplateEnum } from "@/lib/prompt-by-template";
7 | import { generate } from "@/lib/generate";
8 |
9 | const chat = new ChatOpenAI({ temperature: 0 });
10 |
11 | export default async function handler(
12 | req: NextApiRequest,
13 | res: NextApiResponse
14 | ) {
15 | const { input, selectedTemplate = TemplateEnum.FLOWCHART } = req.body;
16 |
17 | if (!input) {
18 | return res.status(400).json({ message: "No input in the request" });
19 | }
20 |
21 | // NOTE: OpenAI recommends replacing newlines with spaces for best results
22 |
23 | try {
24 | const ans = await generate({ input, selectedTemplate });
25 |
26 | // TODO: implement langchain parsed answer
27 | const text = ans.text
28 | .replaceAll("```", "")
29 | .replaceAll(`"`, `'`)
30 | .replaceAll(`end[End]`, `ends[End]`)
31 | .replace("mermaid", "");
32 |
33 | return res.status(200).json({ text });
34 | } catch (e) {
35 | throw e;
36 |
37 | return res.status(400).json(e);
38 | }
39 | }
40 |
--------------------------------------------------------------------------------
/src/pages/index.tsx:
--------------------------------------------------------------------------------
1 | import React, { useState } from "react";
2 | import axios from "axios";
3 | import { Mermaid } from "@/components/mermaid";
4 | import SelectTemplate from "@/components/select-template";
5 | import { TemplateEnum } from "@/lib/prompt-by-template";
6 | import Image from "next/image";
7 | import Nav from "@/components/nav";
8 |
9 | const Index = () => {
10 | const [error, setError] = useState("");
11 | const [loading, setLoading] = useState(false);
12 | const [input, setInput] = useState("");
13 | const [selectedTemplate, setSelectedTemplate] = useState(
14 | TemplateEnum.FLOWCHART
15 | );
16 |
17 | const name = input ? input.replace(/\s/g, "-").toLowerCase() : "";
18 |
19 | const [chart, setChart] = useState("");
20 |
21 | const handleFlow = async (e: any) => {
22 | e.preventDefault();
23 | if (!input && !loading) return;
24 | setLoading(true);
25 |
26 | try {
27 | const res = await axios.post("/api/ask", {
28 | input,
29 | selectedTemplate,
30 | });
31 |
32 | if (res.data.text) {
33 | setChart(res.data.text);
34 | } else {
35 | setError("Sorry! a small issue occurred");
36 | }
37 | } catch (e) {
38 | console.log(e);
39 | setError("Sorry! a small issue occurred");
40 | } finally {
41 | setLoading(false);
42 | }
43 | };
44 |
45 | return (
46 |
3 |
4 |