This document aims to document the high level architecture for Theme Designer v2 (TDv2) as discovery occurs.
Decision points
Should the application be built in NOP or as a stand alone application?
The application will be built standalone, likely with Nuxt but the script for the application will be referenced from within a NOP plugin. This will allow us to insert the TDv2 user interface into a live Commerce store.
The TDv2 script will be stored in a central location that can be accessed by any commerce store.
Benefits to this approach:
Theme Designer code updates can occur without a dependency on consumer application release cycles
It can be migrated to use on any front end in our application suite without significant refactoring
Does not add additional overhead to the current Commerce build pipeline
Risks with this approach:
WIP
Should we use a 3rd party framework to manage the CSS custom properties and associated UI controls?
A couple of 3rd party options were considered but both options require maintaining context specific configurations and/or extensive integration into the client app. This would make implementation less flexible and incur tech debt as these configs would have to be maintained.
A more flexible approach is one in which the application parses the CSS DOM for implemented CSS custom props and returns an object that can be used to generate the UI controls dynamically. We have proven this approach out in this prototype:
https://bitbucket.org/aspenwareunity/commerce-theme-builder/branch/theme-designer-prototype
In this solution, the CSS DOM is parsed for props the --ads prefix, deconstruct the prop name into a deep nested relational object parent > child > child > ... propType . Arrays of those relational objects are flattened into a single relational object and that object can be used by the view layer to render a dynamic UI. The UI will use a component library that has been modified to match the Aspenware Design System (ADS) requirements
This flexibility has one dependency – following the design token naming structure defined in the Theme Designer Var Document when adding new theme properties:
Required CSS Vars for Theme Designer V2
Benefits to this approach:
Highly flexible – can be applied to any web application that uses --ads custom props
Mitigates tech debt by removing the requirement of managing configuration files for CSS property changes
Allows us to layer in a UI component library of our choosing for the prop controls
No 3rd party library to become competent at to use it properly and effectively
Risks with this approach:
Higher risk of bugs early on to roll our own property management solution since there is a smaller test pool than a published 3rd party solution
Ensuring adequate cross platform compatibility as the solution requires the use of some lesser used JS methods and CSS DOM parsing techniques.
Malformed props might be introduced into the system by developers (note: we plan to mitigate this with prop validation)
How will we save, recall, and publish CSS theme props?
TBD