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:
It's simple.
Now, consider a dystopian version of the same input field where simplicity is not valued as highly:
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:
If you want more control, you can compose the form field manually from its individual parts:
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:
If you want to trigger a dropdown using that button, simply wrap it in
<flux:dropdown>
:
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
:
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:
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":
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":
Composition helps with this quest for brevity. Consider the following dropdown menu component:
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:
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:
Another example is using the
<dialog>
element for modals instead of something hand written:
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:
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:
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).