UI Customization

All aspects of the UI are available for customization. For example, the toolbar can accept additions, modifications, and deletions per the needs of end-users. The UI markup is compiled by recursive, functional React calls. The recursion tree is reflected by the directory structure containing the modules which compose the UI. To override any given module, copy the directory structure leading to the module from https://github.com/electric-eloquence/fepper-npm/tree/dev/ui/core/styleguide/index/html to source/_ui/index/html, respective to your implementation. Modifications to modules in that directory will override the corresponding modules in core. Additions (so long as they are correctly nested) will also be recognized.

A working example of UI customization can be found at https://github.com/electric-eloquence/fepper-drupal/blob/dev/source/_ui/index/html/00-head/head.component.js. The Fepper for Drupal project overrides its HTML title to read "Fepper for Drupal" instead of "Fepper". In order to do so, it has the head.component.js module nested in directories that correspond to the tags that nest the head HTML element. Both head.component.js and its nesting directories must be named similarly to their corresponding elements. .component.js indicates that the file is a module to be rendered by React. It must export properties that React.createElement() understands. The numeric prefix to 00-head orders it to precede 01-foot, even though "foot" precedes "head" alphabetically.

In this example, by allowing customizations in the 00-head directory separate from the core components, core updates will be respected for all components except for the HTML head.

Browser JavaScript and CSS customizations can (and should) be componentized this way as well. While a head element is unlikely to have associated scripts or styles, the UI's main element does have its scripts and styles componentized as main.js and main.css in index/html/01-body/40-main. A big advantage for this type of componentization comes when elements are renamed or deleted. When you rename or delete the element, are you absolutely sure you'll rename or delete accordingly in some far-flung, monolithic script or style file?

Alas, no one should be forced to componentize this way. Generic modifications to UI scripts can be added to source/_scripts/ui-extender.js.

Similarly, generic modifications to UI styles can be added to source/_styles/pattern-scaffolding.css. (The file is named this way to adhere to the Pattern Lab convention on defining pattern states. It should not be relied on for pattern scaffolding.)

View All markup can also be overridden by copying the .mustache files in https://github.com/electric-eloquence/fepper-npm/tree/dev/ui/core/styleguide/viewall and pasting them to source/_ui/viewall (nested correctly). Modifications will then be recognized and displayed in the UI. (No additions are allowed.) Custom View All styles can be added to source/_styles/pattern-scaffolding.css.

You will need to compile the UI in order for the browser to pick up custom changes to the UI:

fp ui:compile

New UI customizations will not be picked up simply by restarting Fepper.

The UI exposes these additional tasks: