An Update On Component Strategy For The 0.0.1 Release
By Tim Post on 2025-03-22 | Tagged: v0.0.1 updates
With waist-deep work on components underway, I'm starting to realize that the goals of separating out all of the CSS of all of the existing Infima components is just not practical. What it would likely do is just add an additional several dozen theme variables to make up for all of the places where things like border colors, radius, and other extremely repetitive things are shared.
It can be done. As in, we could ship just the Infima design and spacing elements and variables and dynamically load all of the rest as it's used but it's less than 100kb in total and it would require maintaining a separate compatibility fork with everything loaded, or we break compatibility for those that have existing content.

There's also the issue of, not every Infima component is most conveniently accessed exclusively with a plugin: buttons, badges, even pills are mostly stand-alone. And, importing markup from other Infima sites would be broken unless you used the compatibility theme I'd need to maintain. Only alerts and tabs really lend to the model, as much as it seemed like the others did too.
So here's what I decided: We'll just load the Infima component CSS. We have
plugins removing unused classes anyway. But, all the stuff built using
those components will be Lume 3 components. Examples are the comp.feedback()
component I have brewing, plus Lume 2 style components that don't load css
or scripts in _components/
.
You Can Still Component-ize The Infima Scripts
Look at _components/alert.vto
.
If you wanted, you could easily turn that into
_components/alert/comp.vto
and move the accompanying _includes/js/infima/alert.js
helper script that monitors for close events over to _components/alert/script.js
.
This will cause Lume to understand that script needs to be loaded when the component is invoked. You can do the same with some of the other scripts, but beware that they share some functionality, and have subtle dependencies.
But if I did that for everyone, those who have existing Infima content would have trouble bringing it over unless they had a file that loaded every component. That's silly, and not the good kind of silly.
New Components Adding Styles Or Scripts Must Use The Lume 3 System
Let's say I'm writing a component that will return some styled block elements and has a script the client needs to run to pull in some data to show.
I would structure my component like this:
src/
_components/
widget/
comp.vto
style.CSS
script.js
What's going to happen here is when {{ await comp.widget() }}
is invoked the first
time, Lume is going to put the contents of widget/style.css
into _site/style.css
and the contents of script.js
into _site/script.js
(if you use the defaults).
The template then loads those files, so it has any CSS and JS that was loaded along the way by components while generating.
However, if the component has no CSS or JS, just make it _components/component.vto
instead. Don't add complexity just to make it a certain shape, if you don't need to
load styles or scripts, just use the Vento template.
This Change Only Affects The Existing Infima CSS Code
That's it. We're just loading all of the infima components as base CSS for our own components to use. We're not further-componentizing Infima (unless, as noted above, you want to!)
It's your site, at the end of the day. Generate it the way you think it should be! I just can't take patches that make componentization of the framework itself "hegemony".
Note that, it's not usual to separate Infima components into individual files. It's just technically possible with some lifting and compatibility layers in place. It's just not a good goal for this theme.
This Change Removes Complexity & Maintainer Grief
People who have content with Infima markup and want to use Deno should always have an easy path to this theme and breaking that would make me very sad. But at the same time, I don't want to maintain a "stripped down" version of the theme that gets further broken down the way the existing one currently does - that's just way too much work for me.
So hopefully, you breathe a sigh of relief too, and look forward to making awesome components with the Infima building blocks (and whatever else you bring to them!)
In This Article:
Other posts are in the archive .
Published Later
A Quick Update On Accessibility For 0.0.1
« Published Previously
Why I Evangelize Static Sites As A Seasoned Engineer