Layouts

Principles

Flux is not a set of UI Blade components, it's a system of them. The design of this system is guided by a set of principles that, when applied, result in a cleaner, more creative, and more intuitive, app-building experience.

Simplicity

Above all else, simplicity is the quality Flux aims for in its syntax, implementation, and visuals.
Take for example, a basic input field written with Flux:
Copy to clipboard
It's simple.
Now, consider a dystopian version of the same input field where simplicity is not valued as highly:
Copy to clipboard
It's a mess.

Complexity

Of course simplicity comes with trade-offs. It's harder to customize smaller parts of a single component that "does too much".
That's why Flux offers composable alternatives to overly simple components.
Consider the previous version of the input field:
Copy to clipboard
If you want more control, you can compose the form field manually from its individual parts:
Copy to clipboard
This gives you the best of both worlds. A short, succinct, syntax for the common case, and the ability to customize each part on an as-needed basis.

Friendliness

When given the chance, Flux chooses familiar, friendly, names for its components instead of overly technical ones.
For example, you won't find words like "form controls" in Flux. Most developers use simple terminology like "form inputs" instead.
You also won't find the word "popover" either. Most developers use "dropdown" instead.
Even if a word like "popover" is more acurate, we won't use it because it's not familiar enough.
Another example is "accordion" instead of "disclosure" for collapsible sections. "disclosure" is the more acurate UI pattern, however, "accordion" is the more commonly used term amongst application developers.

Composition

After simplicity, composability is the next highest value. Ideally, you learn a handful of core components, and then you mix and match them to create (or compose) more robust components.
For example, the following is a common Button component in Flux:
Copy to clipboard
If you want to trigger a dropdown using that button, simply wrap it in
<flux:dropdown>
:
Copy to clipboard
Many other libraries force you into more rigid component shapes, dissalowing use of a simple button inside a dropdown and instead forcing you to use a more perscriptive alternative like
<flux:dropdown.button>
.
Because composition is a priority, you can turn this navigation dropdown into a "system menu" containing submenus, checkable items, and keyboard control by swapping
navmenu
for
menu
:
Copy to clipboard
Because
<flux:menu>
is a standalone component in its own right, you can use it to create a context menu that opens on right click instead using the
<flux:context>
component:
Copy to clipboard
This is the power of composition; the ability to combine independent components into new and more powerful ones.

Consistency

Inconsistent naming, component structure, etc. leads to confusion and frustration. It robs from the intuitiveness of a system.
Therefore, you will find repeated syntax patterns all over Flux.
One simple example is the use of the word "heading" instead of "title" or "name" in many components.
The same goes for "subheading" instead of "subtitle", "description", or "caption".
This way, you can more easily memorize component terms without having to guess or look them up.
Here are a few examples of Flux components that use the word "heading":
Copy to clipboard

Brevity

Next to simplicity, brevity is another priority. Flux aims to be as brief as possible without sacrificing any of the above principles.
In general, we avoid compound words that require hyphens in Flux syntax. We also avoid too many levels of nested (dot-seperated) names.
For example, we use the simple word "input" instead of "text-input", "input-text", "form-input", or "form-control":
Copy to clipboard
Composition helps with this quest for brevity. Consider the following dropdown menu component:
Copy to clipboard
Notice the simple, single-word names for the dropdown component.
Consider what it might look like if composability and brevity weren't as high a priority:
Copy to clipboard

Use the browser

Modern browsers have a lot to offer. Flux aims to leverage this to its full potential.
When you use native browser features, you are depending on reliable behavior that you don't have to download any JavaScript libraries for.
For example, anytime you see a dropdown (popover) in Flux, it will likely by using the
popover
attribute under the hood. This is a relatively new, but widely supported, feature that solves many problems that plague hand-built dropdown menus:
Copy to clipboard
Another example is using the
<dialog>
element for modals instead of something hand written:
Copy to clipboard
By using the native
<dialog>
element, you get a much more consistent and reliable modal experience with things like focus management, accessibility, and keyboard navigation out of the box.

Use CSS

CSS is becoming a more and more powerful tool for authoring composable design systems. With new feature like
:has()
,
:not()
and
:where()
, things that historically required JavaScript, can be done with CSS alone.
When you peer into the source of a Flux component, you may notice some complicated Tailwind utilities being used.
This is a tradeoff in complexity. In Flux, if a component can use CSS to solve a problem, instead of using PHP or JavaScript, that component will use CSS.
For example, consider the following
flux:heading
and
flux:subheading
components:
Copy to clipboard
When rendered in the browsers, there will be a small margin added between these two components. However, if they are rendered as independant components elsewhere, there will be no margin.
This is accomplished using CSS's new
:has()
selector. Here's the actual Tailwind utility taken from the
flux:heading
component:
Copy to clipboard
The above selector will match any heading element that has a sibling element with the
data-flux-subheading
attribute (each Flux component has a
data-flux-*
attribute for styling situations like this).

We style, you space

In general, Flux provides styling out of the box, and leaves spacing to you. Another, more practical way to put it is: We provide padding, you provide margins.
For example, take a look at the following "Create account" form:
Copy to clipboard
Notice how Flux handles the styling of individual components, but leaves the spacing and layout to you.
The reason for this pattern is that spacing is contextual, and styling is less-so. Therefore, if we baked spacing into Flux, you would be constantly overriding it, or worse, preserving it and risking your app looking disjointed.
It takes slightly more work to manage spacing and layout yourself, however, the payoff in flexibility is well worth it.
Copyright © 2024 Wireable LLC ·Terms of Service
Built with by
Caleb Porzio and Hugo Sainte-Marie