You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the previous pv-stylemark created two outputs for each component, one standalone with header, body etc. and one only had the component markup and was then wrapped by the stylemark. The issue with only creating one set of files is that for example tests can't be run on the standalone component html files anymore. Which means every test case that doesn't necessarily need to be showcased in the styleguide, still would need to be created by it (and be hidden with the hidden attribute). The downside to it is that it is more complex, the user would need to now the naming pattern used by stylemark and have to add stuff to the readme that is only meant for the tests and can lead to confusion in the long run.
A simple solution can be to re-enable the lsgTemplatesSrc etc and generate two files.
Or have stylamrk to check if the html already has <html> element and in that case skip rendering the headHtml etc. And only inject the css/js from the code blocks. (and have some magic comments in the html to find the component's markup for the preview option)
Assuming stylemark is going to be used only in combination with assemble-lite (as is currently the case in pv-stylemark), then i would argue that assemble(-lite) is a much more capable tool when it comes to generating markup than stylemark, and offloading the task as much as possible to assemble only makes sense. (the html generation by stylemark can still be used for the rare case of example's html code in the markdown file.)
(It might also be an option in the future to fully integrate the assemble in stylemark and have a MDX like files:
---name: Button---
example of a button
{{> e-button
type="primary"
label="label"
}}
with icon
{{> e-button
icon-id="icon-mail"
}}
but not sure if that has a better DX compared to the current dedicated components hbs files approach)
The text was updated successfully, but these errors were encountered:
Commit #c5a5e66 introduces the raw attribute. If set, then the html will be rendered as is, and won't be wrapped with the headHtml, bodyHtml, etc from config.stylemark.yaml.
This attribute can be enabled/disabled on code block e.g.:
```html example-1 ./demo/hero.html raw
```
in the front matter of the markdown file
---raw: true---
or in the config.stylemark.yaml file:
examples:
raw: true
e.g.
---raw: true---```html example-1 ./demo/hero.html
```
stylemark will render the page markup for example 2
```html example-2 raw=false
<input>
```
the previous pv-stylemark created two outputs for each component, one standalone with header, body etc. and one only had the component markup and was then wrapped by the stylemark. The issue with only creating one set of files is that for example tests can't be run on the standalone component html files anymore. Which means every test case that doesn't necessarily need to be showcased in the styleguide, still would need to be created by it (and be hidden with the
hidden
attribute). The downside to it is that it is more complex, the user would need to now the naming pattern used by stylemark and have to add stuff to the readme that is only meant for the tests and can lead to confusion in the long run.A simple solution can be to re-enable the
lsgTemplatesSrc
etc and generate two files.Or have stylamrk to check if the html already has
<html>
element and in that case skip rendering theheadHtml
etc. And only inject the css/js from the code blocks. (and have some magic comments in the html to find the component's markup for the preview option)Assuming stylemark is going to be used only in combination with assemble-lite (as is currently the case in pv-stylemark), then i would argue that assemble(-lite) is a much more capable tool when it comes to generating markup than stylemark, and offloading the task as much as possible to assemble only makes sense. (the html generation by stylemark can still be used for the rare case of example's html code in the markdown file.)
(It might also be an option in the future to fully integrate the assemble in stylemark and have a MDX like files:
but not sure if that has a better DX compared to the current dedicated components hbs files approach)
The text was updated successfully, but these errors were encountered: