8fold UIKit

This site showcases primarily the 8fold UIKit in conjunction with 8fold Web Assets.

An extension of 8fold Elements.

Note on quantity of available components: This library is being used to generate all 8fold websites, including 8fold.pro. Further, it is being developed using Lean and Agile Software Development concepts; therefore, if a component is missing it's because it is not needed at this time.

Having said that, we have been able to generate a diverse set of experiences with what is currently available in the kit.

Composer

$ composer require 8fold/php-uikit

Usage

The extends 8fold Elements to create more elaborate interfaces while reducing, as much as possible, the amount code required to generate that HTML.

Let's take an alert for example. Here's the HTML we're looking for:

<div class="ef-alert ef-alert-success" role="alert">
  <div class="ef-alert-body">
    <h3 class="ef-alert-heading">
      Success Status
    </h3>
    <p>Lorem ipsum dolor sit amet, elit, sed do eiusmod.</p>
  </div>
</div>

244 characters (including whitespace). This can get pretty tedious. There are four alert types altogether, two ARIA roles (alert and alertdialog). The only content that really changes between them is the content of the h3 tag and the body text that follows.

What if we were to do this using 8fold Elements?

UIKit::div([
  'attributes' => [
    'role' => 'alert',
    'class' => 'ef-alert ef-alert-success single-centered'
  ],
  'content' => [
    [
      'element' => 'div',
      'attributes' => [
        'class' => 'ef-alert-body'
      ],
      'content' => [
        [
          'element' => 'h3',
          'attributes' => [
            'class' => 'ef-alert-heading'
          ],
          'content' => 'Success Status'
        ],
        '<p>Lorem ipsum dolor sit amet, elit, 
          sed do eiusmod.</p>'
      ]
    ]
  ]
]);

657 characters (including whitespace). But, in defense of 8fold Elements, its job is not reducing the amount of characters needed to define a component.

What happens when we move it to the kit?

UIKit::alert([
  'type'        => success,
  'interactive' => false,
  'title'       => 'Success Status',
  'body'        => '<p>Lorem ipsum dolor sit amet, elit, 
                    sed do eiusmod.</p>'
]);

194 characters (including whitespace). 20% reduction from hand-jamming HTML. The only thing that really changes from one alert to the next though is the title and body; so, why not set rational defaults for the type and interactive (we chose info and false, respectively; so, we won't get the same exact HTML output)?

UIKit::alert([
  'title' => 'Success Status',
  'body'  => '<p>Lorem ipsum dolor sit amet, elit, 
              sed do eiusmod.</p>'
]);

125 characters (including whitespace). Almost a 50% reduction from the original HTML, and we don't have to worry about whether we messed the HTML up or not. And, if we did, we can change it where it matters, and automatically get the benefits of the change site-wide. Heck, there may even come a time where HTML has an alert element as part of the specification, and we can quickly update ours to follow suit…again, site-wide.