Request component markup via cURL

[Wolfr]

Feature request to be able to request component via cuRL. E.g.

curl -O http://projectname.company.com/styleguide/components/c-contact-card/c-contact-card-1.html

Resulting output:

<div class="c-panel">
    <div class="c-panel__body">
        <div class="c-contact-card">
            <div class="u-spacer-bottom">
                <div class="c-avatar c-avatar--large">PB</div>
                <div class="c-contact-card__title">Pagac Buildings</div>
                <p class="c-body-2">Construction</p>
            </div>
            <ul class="c-tag-list">
                <li class="c-tag">Residences</li>
                <li class="c-tag">Durable</li>
            </ul>
        </div>
    </div>
</div>

[thusc]

There are two use cases that make this feature interesting:

• Given an HTML such as the one presented above, it is possible to diff it against another implementation (e.g. using Jinja2 templates in the Python world, or Mustache). Although it can be seen as duplication, it means the design system as implemented in Bedrock can be used as a source of truth (in an automated way) for others implementations. In other words, designers can update the design system or add to it and an automated tool can diff it so that developers from other teams can propagate the necessary changes to their own implementations. (This also means that a way to list all available components is needed).

  (An alternative to serving those partial HTML is to be able to generate them from the command-line.)

• Another reason is that partial HTML (fragments) can also be used as-is with some frontend technologies such as htmx. It seems a bit old school to serve HTML instead of something like JSON but is regaining traction (see e.g. Phoenix LiveView, and imho is just useful indenpendently of the hype). This means that some pages presented in Bedrock could actually use htmx (or similar) without requiring anything else than Bedrock itself.

[Wolfr]

Thank you @thusc for your clarificiation.

BTW above example is a combined component so probably not the neatest example.

[thusc]

Actually combined components are quite useful, because it means that you can also validate the logic to combine them used by other implementations (e.g. should I wrap a table in an additional div when I embed it in a more complete page ?).

[thusc]

As an example for the second bullet points above about the fragments, consider those three pages:

• https://design.smart.coop/development/template-examples/tools-simulation-empty.html
• https://design.smart.coop/development/template-examples/tools-simulation-loading.html
• https://design.smart.coop/development/template-examples/tools-simulation.html

We can clearly see how, starting with the first screen, we could use something like an AJAX call to only fetch the HTML fragment containing the result of the simulation, and inject it at the right place to avoid a full page refresh when submitting the form. For instance this can be achieved with htmx.

[Wolfr]

Correct URLs are:

• https://design.smart.coop/development/tools/simulation-empty.html
• https://design.smart.coop/development/tools/simulation-loading.html
• https://design.smart.coop/development/tools/simulation.html