Page Comparison

...

Should the application be built in NOP or as a stand alone application?

•  Decision Made?

What was the decision?

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.

...

• Theme Designer code updates can occur without a dependency on consumer application release cycles

• It TDv2 can be migrated to use on any front end in our application suite without significant refactoring to separate it from Commerce

• Does not add additional overhead to the current Commerce build pipeline

• Changes in the TDv2 application will incur no risk to the host application

Risks and concerns with this approach:

Higher LOE to stand up an application vs building everything in nop could extend timeline to completion

...

What UI library should we use for the 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

Poposals:

• Vuetify 2

• Vuetify 3

• VueMaterial

• VueTailwind

What was the decision?

TBD

Benefits to this approach:

TBD

Risks and concerns with this approach:

WIPTBD

...

Should we use a 3rd party framework to manage the CSS custom properties and

...

map them to controls?

•  Decision Made?

What was the decision?

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.

...

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)

...

How will we save, recall, and publish CSS theme props?

TBD

...

•  Decision Made?

What was the decision?

TBD

Benefits to this approach:

TBD

Risks and concerns with this approach:

TBD