**A Loki Component is a block with a PHTML template that is transformed into a Loki Component by underlying backend logic: Its HTML is modified to include a reference to an Alpine.js component (x-data), a specific Alpine.js initialization element (script of type loki-component) and various HTML attributes are added. Some of this could be influenced using XML layout arguments.
<block name="yireo-training.example" template="YireoTraining_Example::component/example.phtml">
<arguments>
<argument name="foo" xsi:type="string">bar</argument>
</arguments>
</block>
A component block can be supplied with the following XML arguments:
js_component_name (string)This refers to the Alpine.js component name to initialize the Loki Component with.
<block name="yireo-training.example">
<arguments>
<argument name="js_component_name" xsi:type="string">LokiComponent</argument>
</arguments>
</block>
css_classes (array)If the PHTML template includes references to the $css() CSS utility, then the css_classes argument allows for extending these CSS classes.
<block name="yireo-training.example-field">
<arguments>
<argument name="css_classes" xsi:type="array">
<item name="block" xsi:type="array">
<item name="additional" xsi:type="string">p-2</item>
</item>
</argument>
</arguments>
</block>
See Customizing CSS classes for more details.
css_styles (array)If the PHTML template includes references to the $style() CSS utility, then the css_styles argument allows for extending these CSS styles. For instance, if a CSS style name starts with --, this can be used as a CSS property.
<block name="yireo-training.example-field">
<arguments>
<argument name="css_styles" xsi:type="array">
<item name="background-color" xsi:type="string">red</item>
<item name="--example-var" xsi:type="string">42</item>
</argument>
</arguments>
</block>
lazy_load (bool, default false)Whenever a Loki Component is loaded as part of the page, its ComponentViewModel loads in the value. This could delay the initial TTFB of the page, while maybe the data could be fetched as well after the page is done loading (lazy loading via AJAX). Or, maybe, the data are not publicly cacheable (like with the Full Page Cache). Lazy loading offers a solution here. Note that the Alpine.js component needs to support lazy loading for this to work.
<block name="yireo-training.example">
<arguments>
<argument name="lazy_load" xsi:type="boolean">true</argument>
</arguments>
</block>
lazy_update (bool, default false)When a Loki Component its Alpine.js part uses the post() method to submit an AJAX call, the call actually ends up in a queue. This queue is empty after a short amount of time (the blink of an eye) so that almost-simultaneous component updates are performed in a single HTTP call. However, a component update could also be delayed, until the next component updates is sent to Magento. This is accomplished by toggling lazy_update to true. Note that the component update will just hang in the queue indefinitely, until another component updates comes along or when the lazy_update_timeout is hit.
<block name="yireo-training.example">
<arguments>
<argument name="lazy_update" xsi:type="boolean">true</argument>
</arguments>
</block>
lazy_update_timeout (int, default 0)When a Loki Component is configured to use lazy_update, its component update actually ends up in the AJAX queue indefinitely, until another composer update is performed or when the lazy_update_timeout is hit. If the lazy_update_timeout is 0 (default), then nothing happens. If the lazy_update_timeout is higher than 0, but lazy_update is false, nothing happens. If the lazy_update_timeout is higher than 0 and lazy updating is enabled, then a JavaScript timeout with the value of lazy_update_timeout (in milliseconds) is set, after which the lazy_update property is disabled again, effectively making the component update run after the first queue run.
<block name="yireo-training.example">
<arguments>
<argument name="lazy_update_timeout" xsi:type="number">10000</argument>
</arguments>
</block>
skip_queue (boolean, default false)When a Loki Component runs its post() method, it adds a component update to the AJAX queue. With that, it might happen that multiple component updates are sent to the Magento backend by using a single AJAX call, which is great for performance. It might be possible that you don't want this, simply because a single component update is too heavy to combine with other updates. In that case, you can skip the queue and perform the AJAX call directly, by setting the property skip_queue to true.
<block name="yireo-training.example">
<arguments>
<argument name="skip_queue" xsi:type="boolean">true</argument>
</arguments>
</block>
validators (array)If the Loki Component allows for validating its value, additional validators could be declared in this argument. Note that each validator is a reference to a DI entry for the Loki\Components\Validator\ValidatorRegistry.
<block name="yireo-training.example-field">
<arguments>
<argument name="validators" xsi:type="array">
<item name="positive_number" xsi:type="string">positive_number</item>
</argument>
</arguments>
</block>
filters (array)If the Loki Component allows for filtering its value, additional filters could be declared in this argument. Note that each filter is a reference to a DI entry for the Loki\Components\Filter\FilterRegistry.
<block name="yireo-training.example-field">
<arguments>
<argument name="filters" xsi:type="array">
<item name="capitalize" xsi:type="string">capitalize</item>
</argument>
</arguments>
</block>
dispatch_local_messages (bool, default true)When a Loki Component allows for validation and if during validation, an error occurs, this error needs to be shown to the end-user in the browser. An error is then either a global message (in the top of the page) or a local message. By default, validation errors are shown as local messages. Toggle this flag to show them as global messages instead.
<block name="yireo-training.example">
<arguments>
<argument name="dispatch_local_messages" xsi:type="boolean">false</argument>
</arguments>
</block>