Integration with @yamato-daiwa/es-extensions (YDEE)
Once the Functionality.pug file (located in the root directory
of the @yamato-daiwa/frontend npm package) has been
included,
all functionality of version 1.7 of
@yamato-daiwa/es-extensions (abbreviation: "YDEE") library becomes available.
The exception is such functionality which ceases to exist during the transpiling
from TypeScript to JavaScript, such as
interfaces and type aliases.
include ../../node_modules/@yamato-daiwa/frontend/Functionality.pugnode_modules directory could differ.
Functionality.pug file is already included;
including it again will cause an error.The main use case of this functionality is primitive data mocking during the static preview stage. For example, the following code demonstrates how to quickly create 16 item cards with random data:
ul.ProductsList
each index in Array.from(new Array(16).keys())
li.ProductCard
- const productTitle = getRandomString({ minimalCharactersCount: 6, minimalCharactersCount: 32 });
span.ProductCard-Title= productTitle
img.ProductCard-Photo(
src=getRandomObjectPropertyValue(DummyImagesURIs)
alt=`The photo of the "${ productTitle }" product`
)
span.ProductCard-PriceLabel
span.ProductCard-PriceLabel-Amount= getRandomInteger({ minimalValue: 100, maximalValue: 100000 })
span.ProductCard-PriceLabel-Currency $
Here, the functions getRandomString,
getRandomObjectPropertyValue, and getRandomInteger
from YDEE have been used.
The associative array-like constant
DummyImagesURIs is part of YDF.
As a result, for each card, HTML code similar to the following will be generated
(avoiding taking up too much space, the src attribute of the
img tag has been truncated):
<li class="ProductCard">
<span class="ProductCard-Title">5XDoHI8G9qbjrvfFAq0ZrjX2KP4qcFsHzDXS9IW6nJjOnvB0FQgulYL</span>
<img
class="ProductCard-Photo"
src="data:image/svg+xml;base64,PHN2ZyB4b(...)"
alt="The photo of the product"5XDoHI8G9qbjrvfFAq0ZrjX2KP4qcFsHzDXS9IW6nJjOnvB0FQgulYL""
>
<span class="ProductCard-PriceLabel">
<span class="ProductCard-PriceLabel-Amount">8301</span>
<span class="ProductCard-PriceLabel-Currency">$</span>
</span>
</li>
Even if you are not planning such usage of YDEE, it still requires the correct functioning of the YDF functionality related to markup, for example, for Pug mixin's parameters validation:
include ../../node_modules/@yamato-daiwa/frontend/Components.pug
+Badge--YDF({ value: [] })value property of the sole
parameter has the incorrect type, and one required property is missing.
However, because YDEE implements properties
validation, Pug-to-HTML conversion will fail with a detailed error report.
This allows issues to be fixed without reading the documentation.
Answers to FAQ and criticism
Do you mean that almost the entire code of YDEE has been embedded in the Pug code? Is it not overkill?
Will the usage of YDEE inside the Pug code on the backend with the MVC frameworks cause performance impact during Pug-to-HTML compilation?
It will, herewith significantly (about 2-3 seconds, but it is unacceptable for the case of generating the server response).
The YDEE integration is primarily intended for the static preview stage. However, if Pug-to-HTML conversion is performed preliminarily once per site or application deploy , there are basically no problems with using YDEE integration on other development stages.
Most likely, you are asking this because you want to know what you have to do when you need YDEE functionality on the stage of the interactive application with server-side rendering using MVC pattern (for example, to keep Pug mixins parameters validation , including mixins of the GUI components or to keep using the pages templates ), but without performance impact. There is a manual specialized in this problem , but in short it is required to provide two-stage Pug-to-HTML conversion. In the first stage, the intermediate template file is generated, and these files do not change due to dynamic data (such as data from the database). Also, these template files are generated only once before deploying each version of the website or the web application. At the second stage, the dynamic data is interpolated into the intermediate template, and the final HTML code is generated.