UI Components

[alexmatson-da]

The Wallet Kernel(s) will render bits of UIs in a variety of places and environments:

• The HTTP wallet kernel web pages
• The browser extension wallet kernel UI*
• The Electron desktop app wallet kernel UI*
• Embedded directly (i.e. not hosted anywhere) in browser popup windows by the SDK (atm, only one such example: the discovery/selection popup)

Goals:

• Develop modular UI components as a library, import where needed
• Include CSS styles for consistent UI/UX across all platforms (defined once, styled everywhere)

On Frameworks:
For building out the core UI components, we've decided to trial out Phase 1 MVP of the Wallet Kernel with Web Components (zero-framework) rather than React. There may be a few benefits for us:

• Easier for 3rd party WK implementers (e.g. CCSP solutions) to reuse
• Simpler dev tooling (likely no need for bundlers or other complicated build configs)
• Smaller bundle sizes

The potential downsides here are less dev familiarity, and more work to implement basic functionality. After delivering Phase 1, we'll reexamine any specific pain points that arose and whether we'd want to switch to React (at this point, the idea is that we haven't implemented "too much" for a switch to be painful) or continue to production with WC.

Implementation approach:

1. Library
   1. Create core/wallet-ui-components to provide implementations of individual UI components
   2. Components should cleanly decouple logic from presentation. I.e. they should not make network requests directly, but receive data externally and display it.
2. Web frontend (for HTTP WK)
   1. Keep the UI implementation within the same package (something like clients/remote/src/frontend)
   2. Have a yarn script that compiles the TS to JS to some output dir, and then serve it statically in Express
3. Extension/desktop
   1. Can be developed with any framework, just import components as dependency and build normally
4. SDK
   1. The "discovery" popup: this popup window is not a page hosted by any server, but is generated dynamically. If using web components, we can just drop it in.

[meiersi-da]

The potential downsides here are less dev familiarity, and more work to implement basic functionality. After delivering Phase 1, we'll reexamine any specific pain points that arose and whether we'd want to switch to React (at this point, the idea is that we haven't implemented "too much" for a switch to be painful) or continue to production with WC.

@alexmatson-da @PHOL-DA : how strong is the need to use zero-framework over react? We are using react very widely across the company, so using react gives both high dev familiarity as well as a straightforward integration path; e.g., into Splice Wallet UI, Utility UI, and Splice SV UI -- where required.

From a distance it seems that using zero-framework introduces unnecessary technical risk and increases delivery risk. wdyt?

[PHOL-DA]

I believe the idea here is to enable any client web development, by using frameworkless web components it would allow CCSPs and other providers to build it using most frontend frameworks (and not force them to using react).

The transitions from react to a zero-framework setup is probably more costly timewise than vice versa, and i don't think we want to incur that technical debt so early on based on it forcing client into react or do some heavy workaround to integrate in the wallet kernel.

[meiersi-da]

I believe the idea here is to enable any client web development, by using frameworkless web components it would allow CCSPs and other providers to build it using most frontend frameworks (and not force them to using react).

OK, thanks. I misunderstood the meaning of zero-framework. It is really meant to refer to using web components, as for example explained here, https://www.sitepoint.com/frameworkless-web-components-introduction/, correct?

That makes sense to me to try under the assumption that the first integration partners use different web frameworks or it really is very low additional effort. Your call :)

[mjuchli-da]

@PHOL-DA is 100% correct. That is what @alexmatson-da and I discussed briefly last Friday. We concluded that it would be best to proceed this way for at least Phase 1 and then draw conclusions about whether it makes sense to continue this way or if we'd benefit from react going forward.

@meiersi-da yes correct, this is meant to use Web Components (e.g. your link posted or https://developer.mozilla.org/en-US/docs/Web/API/Web_components).

This approach gives us the flexibility so that after Phase 1 we can either:

• Continue using Web Components solely
• or do a cheap migration to a complete React stack
• (or potentially use a hybrid, where generic UI components remain as Web Components (for better reusability) but are used within the client that we'd port to React).

[meiersi-da]

Thanks for the explanations @mjuchli-da . Looking forward to hearing and learning from your experience reports over lunch.