This document aims to document the high level architecture for Theme Designer v2 (TDv2) as discovery occurs.
Decision points
1. Should the application be built in NOP or as a stand alone application?
- Decision Made?
What was the decision?
...
Higher LOE to stand up an application vs building everything in nop could extend timeline to completion
...
2. What UI library should we use
...
the base components?
- Decision Made?
Considerations:
Should be Material Design based to align with ADS
Should not conflict with the UI library in host applications (Commerce)
Can it be name spaced to avoid CSS/JS conflicts?
Does the library have enough flexibility make the components look like the UX? https://www.figma.com/proto/4sRJ66lxX82nKRfVvc90kH/Panels?node-id=143-7756&scaling=scale-down&page-id=5%3A3&starting-point-node-id=143%3A7756
...
Proposals:
Vuetify 2
Vuetify 3
VueMaterial
VueTailwind
...
Who is researching this?
TBD
Benefits to this approach:
TBD
Risks and concerns with this approach:
TBD
...
Not yet assigned
...
3. How will we access the CSS properties on the loaded page?
- Decision Made?
...
What was the decision?
Research was conducted into 3rd party options to do this, as well as using configuration driven page mappings. No 3rd party options were identified that would provide the utility that we needed to access properties in a way that solved our problem. Further, a configuration based approach would make implementation less flexible and incur tech debt as these configs would have to be maintained.
...
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 and concerns 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)
...
4. How will we save, recall, and publish CSS
...
props for resort themes?
- Decision Made?
What was the decision?
TBD
Benefits to this approach:
TBD
Risks and concerns with this approach:
...
Considerations:
TBD
Proposals:
TBD
Who is researching this?
Jira ticket not yet assigned
...
5. How will we map the CSS prop names to the component library
- Decision Made?
Considerations:
Must allow us to map the props to groups
Must allow us to use the groups to create collapse points in an accordion
Must use a Vue supported Material UI library or let us use a UI library of our own choosing.
Must allow us to toggle controls based on dependencies. For example, if the user choses to not show the price on their product cards, we don't want to display the controls for price CSS props.
Nice to have: Ability to provide information to the user about the control/option.
Proposals:
JS Forms https://jsonforms.io/
Code our own solution using the component library selected in item 2.
Who is researching this?
Danno and Gibas