Skip to content

Latest commit

 

History

History
381 lines (303 loc) · 18 KB

UI-COMPONENTS.md

File metadata and controls

381 lines (303 loc) · 18 KB
Raw

Visual Laravel Logo

UI Components

A critical design choice for Visual Laravel is the choice of Livewire UI components for both the development and runtime environments.

At this early stage the plan is:

  1. For the development environment to be based on Laravel Livewire;
  2. The the initial runtime environment to be based only on Livewire.

Both of these environments will need a wide variety of (open-source) Livewire components, and this web page gives the current state of research into how to provide these.

At this stage it is not clear what the runtime requirements will be long-term, i.e. whether supporting Livewire (using lightweight AlpineJs under the covers) will be sufficient to work alongside all other front-end technologies without needing directly and separately to support those technologies or whether these other technologies will need VL to support them directly. In other words, if other parts of an existing web site are in InertiaJs/Vue or IntertiaJs/React or the VL is being called using an API from e.g. Joomla which is using something else, then will Livewire work seamlessly with these other technologies, or will we need to support these other technologies and compile the Visual Laravel model to code that uses these other technologies natively.

(In the research below we have not had the time to compare and contrast all the various component libraries, however for a very high level comparison we have summarised the number of components in each library).

High-level Requirements

Leaving aside the wide-variety of different components themselves, here are a few additional requirements:

  • Theming - they should be "headless" in the sense that they have no styling applied, and styling should be possible using themes (that apply consistently to all components) rather than requiring individual detailed styling.

    VL should probably provide a few standard "themes" such as Material Design, light / dark / high contrast, and these should be immutable. VL should also allow users to define new themes or extend existing ones (as deltas so that changes in new VL versions will be applied to extended themes).

  • I18n - all text strings in components should be translateable, all dates, numbers and currencies should be expressable in locally correct ways.

  • Accessible - all components should be suitable for screen readers etc. for the blind, and (if not automatically supported by the underlying browser/operating system) should support keyboard enhancements etc.

Using existing Livewire libraries

At the time of writing we had identified the following existing Livewire component libraries:

  • Livewire: 0?
  • Jetstream: ?
  • Filament Forms: 24 (inc. 6 from a 3rd party - but there is a vibrant plugins library which provides many more though there may be technical and visual incompatibilities when using components from many different sources with varying degrees of support)
  • Wire UI v2: c. 28
  • DaisyUI: 53
  • Mary UI: 30
  • New library from Caleb not yet announced (but given that his AlpineJS library is commercial, this is likely to be too)

We should note that at the time of writing this design note, the existing Livewire component libraries do not use a library-specific namespace, and so it is likely that there will be namespace clashes between e.g. Livewire or Filament etc. and whatever package we choose, more so if we find we need to use existing Livewire components from more than one library.

Note to library writers: Your component library needs to coexist nicely with other libraries. Since components with the same name are likely to have some differences anyway and are likely not to be plug-and-play interchangeable with each other without some code changes, at the time of writing I am unclear why library authors do not namespace their components.

Porting non-Livewire libraries to Livewire

The current research into Livewire components suggests that compared to other frameworks there are relatively few components available (see below), and it seems pretty likely that we will need to look to other frameworks (like Vue or React) to provide components that can be ported over to Livewire, and we will want these components to be visually consistent (which is most likely when they are part of a substantial existing framework).

On obvious potential source for components is Vue; research suggests that porting Vue components to Livewire is technically possible (see Google, but for one (easy) example see DevDojo, and Vue (for example) has a large base of component libraries e.g.

Another obvious potential source for components is the Tailwind ecosystem:

Tailwind components are going to be headless and reasonably themeable, and with this quantity available, they probably represent a great starting point, but they are not Livewire capable and so would need modifying.

It seems likely that React and some other technologies may have a similar breadth of compponents e.g.

  • React - Mantine: 100+ and a partial "port" to Svelte SvelteUI: 40+
  • Svelte - Attractions: 49
  • Svelte - Skeleton: ? - Interesting because it supports Tailwind and theming.

However, in the future event that we need to directly support these other technologies, we would not want to have to port all the e.g. Vue->Livewire components over to these other frameworks if we can avoid this by thinking ahead now. Fortunately a number of cross-technology component libraries are already available e.g.

Alternatively, according to some Svelte documentation it is easy to use the same Svelte components in various frameworks. Svelte has a reputation for being the most performance JS framework, so perhaps some research into Svelte components libraries would be worthwhile. That said, Svelte gets its performance by compiling into native JS without use of a runtime library shadow-DOM, and Livewire will still require use of AlpineJs to handle the Livewire linkage regardless, whilst already using native JS for any component JS code and needing any links to other native Livewire components to link through Alpine, so I am unconvinced that there would be any benefit to this. (but if at a later date it turns out to be beneficial then I guess we can switch over).

Another alternative is to base our approach on Web Components which are platform independent. AFAIK, there are currently no major web component libraries, nor any web component integration with Livewire, both of which are major downsides - however the upside is that they will likely be more usable across various target environments, and are likely to have greater technical longevity than other technologies (though I would hope that the flexible architecture we are developing would easily enable a migration of LV developed applications at a later date). Native Web Components can also be supported by frameworks that can provide some orchestration and state-management across multiple components on a page, though of these perhaps only two are of interest:

  • StencilJS designed specifically to support design systems and development of component libraries

  • Slim.js seems small and simple and might be ideal for our needs.

Given the number and breadth of these libraries, a reasonably comprehensive evaluation will be quite time consuming, especially if we need to prototype the conversion to Livewire in order to confirm that such a conversion is technically feasible and reasonably easy.

One possible short-term plan is to review these cross-technology libraries for breadth of components, and compare it to the few existing Livewire component libraries, to see whether the existing libraries will meet our needs or whether we need to select a more general library and convert it to Livewire (contributing the Livewire library back to the community as we go).

However a first, gut, reaction is that it is likely that none of the above is going to meet our needs long-term, and so perhaps we should start with using WireUI v2 / DaisyUI or MaryUI (all of which are TailwindCSS ready) and, (over the course of time), (shamelessly) plagiarise any suitable component library for components we need, perhaps focusing on the Tailwind Component libraries due to headlessness and native JS, reworking them to be Livewire, themeable, translateable and accessible.

Appendix - Existing Livewire libraries

Filament Forms

In addition to the above provided with Filament itself, there are one or more Filament plugins that provide similar functionality:

Filament Components plugin

  • Sidebar
  • Timestamps
  • UpdatedAt
  • CreatedAt
  • DeletedAt
  • Timestamp

Wire UI v1

At the time of writing v2 is announced and documented but not available.

Form Components

UI Components

Livewire components

Actions

Advanced

Wire UI v2

This v2 list appears to be backwardly compatible with v1, with the addition of alert and link components.

UI Components

Form Components

Actions

Advanced

Mary UI

At the time of writing Mary was still a very new library (literally only a week or so since full release). We were able to persuade the author to add name-space support to avoid clashes between Mary and components with identical names in other libraries (in this case a report about a clash with Jetstream.

Forms

List data

Menus

Dialogs

UI

Third-party