@upgrowth/firelight

Firelight

Overview

The best way to think about Firelight is as a "CMS builder". When building and app there is the front-end which end users see, but there is almost always a significant, and often larger, amount of work in building the 'back-end' administration system where the app administrator configures elements of the front-end application.

Firelight aims to provide a fast and reusable way to define that back-end administration system so that it does not need to be rebuilt from scratch for every project.

Usage

<FirelightView firelight='admin' viewName='main' baseRoute='/admin/content' />

This includes a Firelight Admin View into your application.

The firelight property tells Firelight to use the configuration defined in the Realtime Database under the 'admin' node (you can set this to whatever you like. For example, you could have two admin systems if needed).

The viewName property tells Firelight which Firelight "main" to load initially, in this case "MainView". (TODO: What is a "view"?)

Finally, the baseRoute property tells Firelight what url route it should mount at.

(Note: It might be good to default these values, perhaps as defined above?)

When combined with the following data in the Firebase Realtime Database, Firelight will render a very simple CMS with a single view named 'MainView'. The MainView consists of a single tab named 'Sample Page'. The 'Sample Page' tab contains one field, which is a simple string named 'content', the value of which the administrator can edit.

{
  "admin": {
    "views": {
      "main": {
        "type": "tabs",
        "of" : {
          "Sample Page": "samplePage"
        }
      }
    },
    "types": {
      "samplePage": {
        "content": "string"
      } 
    }
  }
}

Views

TODO

Types

Firelight understands a variety of implicitly defined data types.

Basic/Implicit Types

The basic set of implicit data types supported by Firelight "out-of-the-box" include:

• String (e.g. A simple HTML Input or TextArea )
• Boolean (e.g. A simple checkbox or switch)
• Markdown (e.g. for user defined Rich content)
• File (e.g. Image or Video etc)

Composing Custom Types

These basic types described above can then be composed into into more complex custom data structures by adding a type definition under the types node in the database.

For example, an Address and Customer type could be defined as follows:

{
    types: {
        Address: {
            type: "Object",
            of: {
                line1: "String",
                line2: "String",
                suburb: "String",
                postcde: "String",
                state: "String",
            }
        },
        Customer: {
            type: "Object",
            of: {
                firstName: "String",
                lastName: "String",
                postalAddress: "Address",
                billingAddress: "Address"
            }
        }
    }
}

In this example both Address and Customer are defined as Objects.

• An Object is simply a pre-defined set of properties (such as firstName), which themselves cannot be added or removed but the values of which can be changed.

In addition to Object we can also define properties to be Arrays or Collections:

• Arrays: Items in an Array are ordered. They can also be added, deleted, reordered etc in the Firelight UI.
• Collections: Items in a Collection are named but unordered. They can also be added, deleted, renamed etc in the Firelight UI.

Defining properties

TODO

Optionals?

Layouts

Collections can be laid out in a number of different ways:

Lists

A simple column of items (using CSS Flexbox )

Grids

Uses CSS Grid Layouts (e.g. define the number of columns and their width)

Forms

Uses an row/cell layout definition to explicitly define the layout of each row and the items within.

Tabs

As a set of navigation tabs

Pages (todo)

As a collection of pages