--- title: <file_title> tags: UI reference --- <!-- READ CAREFULLY ALL COMMENTS AND NOTES HEREIN: 1. Replace text wrapped in angle brackets <replace_text_formatted_like_this>) 2. All components, elements, values... should be formatted as code) 3. The first part of the file doesn't support eDocs flavour. Everything must be in plain text. Eg. notes cannot be formatted with the :::tip syntax type. Just use the eDocs flavour in the second part) 4. If there's no information available for a section, it won't be rendered so that there may be a file with no props, slots, or events sections. The same applies to specific data in a section. I.e. If there's no binding for a slot, the binding field will be blank. --> [//]: # (FIRST PART. CODE DATA EXTRACTION) # <Component_name> <component_description> <!-- 1. DO NOT include a note indicating the required backend service should be added. E.g. The QuerySignals services must be implemented.) 2. If technical information needs to be included in the description -E.g. references to events emitted or classes- wrap it in a @remarks tag in VUE as follows: @remarks If query is not empty, it emits {@link XEventsTypes.UserAcceptedAQuery} and {@link SearchBoxXEvents.UserPressedSearchButton} events with the query as payload. It also adds `x-search-button--has-empty-query` as class when there is no query. @public This tag will be render as normal body text in the MD file. However plugin settings can be modified to change format. --> ## Props <!-- 1. Only if props are avaiable. Otherwise Props section will not be included. 2. Prop name, type, and default value should be formatted as code. 3. Indicate in italics before the description whether a prop is required. E.g. *Required*. Button content with a message. 3. If there's no information available, leave the corresponding field blank. --> | Prop name | Description | Type | Default | | --------- | ----------- | ---- | ------- | | | | | | | | | | | ## Slots <!-- 1. Only if slots are available. Otherwise Slots section will not be included. 2. Indicate in italics before the description whether a slot or binding is required. E.g. *Required*. Button content with a message. 3. The Bindings column includes the following information and in this order: the binding name in bold, the binding type as code, and a description. If a slot has more than one bindings, make sure that they are documented in the same cell, separated with line breaks. 4. If there's no information available, leave the field blank. --> | Slot name | Description | Bindings <br/> (name - type - description) | | ---- | ----------- | -------- | | | | | | | | | ## Dynamic classes <!-- Optional section! Just enter the corresponding description or information available. --> [//]: # (SECOND PART. DOC TAG RELATED INFORMATION) ## Events <!-- 1. Optional section. Only if events are emitted by the component. Otherwise the section will not be included. Note that some events are emitted by the module's emitters, so they are documented only in the corresponding module events list (TS file). 2. Organize events into an unordered list. Use code format. 4. Link every event to the corresponding file: module's events list or general/wiring events list. --> This component emits the following events: - <event_emitted_#1> - <event_emitted_#2> - <event_emitted_#3> - ... ## See it in action <!-- If a backend service is required, include a warning note here. For correct operation in VUE, wrap the warning with the prettier-ignore-start and prettier-ignore-end syntax: --> <!-- prettier-ignore-start --> ::: warning Backend service required The <sevice_name> microservice must be implemented. ::: <!-- prettier-ignore-end --> <!-- EXAMPLES GENERAL BEST PRACTICES 1. The following are sections to illustrate how to use the component and implement properties, slots, and events. 2. First, include a simple description or explanation for each example. 3. Add a call-to-action text. Adapt it to suit any scenario/option. 3. Finally, define a basic live example that relates with the definition of the component, the properties, slots, and events. --> Here you can see how... _Type “puzzle” or another toy in the input field to try it out!_ ```vue live <live_example_here> ``` ### Play with props <!-- Optional section. Only when there are props available and documented. --> <!-- Include an explanation of the example, the call-to-action text, and the live example. --> See how the related tag can be rendered... _Type “puzzle” or another toy in the input field to try it out!_ ```vue live <live_example_using_props_here> ``` ### Play with <slot_#1> slot <!-- Optional section. Only when there are slots available and documented. --> <!-- Include an explanation of the example, the call-to-action text, and the live example. --> In this example,... _Type “puzzle” or another toy in the input field to try it out!_ ```vue live <live_example_using_slot_here> ``` ### Play with <slot_#2> slot <!-- Optional section. Only when there are slots available and documented. --> <!-- Recurrent section for each slot available. --> In this example,... _Type “puzzle” or another toy in the input field to try it out!_ ```vue live <live_example_using_slot_here> ``` ### Play with events <!-- Optional section. Only when there are events available and documented. --> <!-- Include an explanation of the example, the call-to-action text, and the live example. --> In this example,... _Type “puzzle” or another toy in the input field to try it out!_ ```vue live <live_example_using_events_here> ``` ## Extending the component <!-- Optional section! Not all components have extended functionalities. --> <!-- Include an explanation of the example, the call-to-action text, and the live example. --> Components can be combined and communicate with each other. Commonly, the `<component_name>` component communicates with the `<component_name_with_link>` to... _Type “puzzle” or another toy in the input field to try it out!_ ```vue live <advanced_live_example_here> ```