futility-ui

Futility UI

Futility UI is a Vue 3 component library inspired by the Flowbite design language. It focuses on practical, ready-to-use UI building blocks with a consistent visual style and straightforward integration.

Live Demo

Why Futility UI

• Vue 3 components with a consistent look and feel
• Storybook documentation with interactive examples
• Multiple style distribution options for different integration strategies
• A pragmatic component set built from real project needs

Installation

Install the library:

pnpm add futility-ui

Styles

Choose how you want to include styles in your project.

Import the stylesheet from JavaScript:

import 'futility-ui/styles.tailwind.css'; // or styles.base.css

Or import it from your main CSS file:

@import 'futility-ui/styles.tailwind.css'; /* or styles.base.css */

Available stylesheets:

• styles.base.css includes only Futility UI component styles
• styles.tailwind.css includes component styles together with Tailwind CSS utilities

Usage

You can register the library globally:

import { createApp } from 'vue';
import FutilityUI from 'futility-ui';

createApp(App)
	.use(FutilityUI)
	.mount('#app')
;

Or import only the components you need:

import { FButton, FInput } from 'futility-ui';

For more details about stylesheet selection and integration options, see the Usage page in the documentation.

Roadmap

• Icons
• Loader
• Buttons
• Text button
• Switch
• Checkbox
• Input
• Widgets group (A component that visually merges widgets without spacing, such as an input field immediately followed by a button.)
• Radio button
• Input Autocomplete (with loading options)
  • Ability to group options when needed
• Select
  • Custom dropdown for desktop screen and native for mobile [???]
• Tooltip
• Form row (A component that renders a form row with a label, widget, help text, and error text.)
• Control label (A component that adds a label for widgets such as checkbox, radio button, etc.)
• Generic Form
  • utils for make meta from DRF metadata
• Dropdown
• Textarea
• Modal
• Tabs
• Number picker
• Header pannel <- you are here
• MultiSelect
• Tag Select
• Tree Editor
• FileSelect
• FileSelectArea
• Paginator
• Popover
• [FGenericForm] number range (from - to, inputs)
• [FGenericForm] date range
• etc.

Refactor

• Split styles into base styles and theme-specific styles
• Add support for scaling icons inside buttons
• Update button focus styles (especially for the dark theme)
• Sizes for checkbox, radiobutton and switch

Extended

• Integrate Tailwind configuration and theming (seems implemented, but needs verification)
• Tag panel
• Multi-select autocomplete
• Select with custom dropdown (search, loading, etc...)
• Select Autocomplete (likely not needed if Input Autocomplete exists)
• Custom DatePicker [???]
• Custom TimePicker [???]
• Custom MultiSelect with filters

Dev

• Storybook on GitHub Pages
• npm publishing
• Web interface for customizing styles

Oh great, another UI library.

You might be wondering: why the heck do we need yet another UI library? The short answer is: just because.

This library isn`t necessarily better than others. It has a much smaller community, it evolves more slowly, and it doesn`t really have any unique killer feature. It exists simply because none of the existing options fully work for me. Either there aren`t enough components, or they`re incredibly complicated, or not truly native to Vue, or they`re paid, or… they just look ugly. So, I decided to build my own.

This library grew out of components I use at work. And my colleagues are probably asking themselves: why bother extracting the UI into a separate repo? Here are a few reasons:

• I don`t like monorepos.

• It`s easier to isolate components, code style, and dependencies.

• Components are simpler to organize and structure.

• Writing documentation is easier when you build components outside the context of the main project.

• A separate repo makes it simpler to set up tests, build processes, and all that stuff. (Yeah, yeah - I know there are no tests yet, but eventually I`ll add some, at least out of curiosity.)

• You can improve the UI independently from the main project.

• It helps keep the main project`s codebase cleaner - less clutter unrelated to business logic.

• Reusability? That`s a cliche argument, and it`s not really the main goal here (But who knows - maybe I`ll use this library in other projects too. I already have a few ideas).

• An attempt to turn legacy code into a documented library that anyone can use.