1. What does panel mean? Should we just call that a div? What html element would a panel equate to?

It's essentially just a container around other elements. It could be a div, depending on the platform. I don't think we should name it div, because on mobile it's likely not an actual <div /> element.

2. Should we have a mapping file and choose what components from the extension we want to use?

I think that's an implementation detail, and not something we should specify in the SIP?

3. How do we control the CSS of components? You mentioned that we can render children vertically or horizontally? (This refers to your comments made in the notion UI proposal)

In the actual implementation we'll have to do a mapping from SIP-7 component to React component. We can put any CSS needed to render stuff horizontally or vertically there. Horizontal rendering is something we'll likely implement somewhere in the future though, as for now it's easier to just render things vertically.

3.1 Can't we define a set of CSS rulesets?
3.2 Instead of mode maybe we should have a CSS key

I'm not sure what you mean by that.

4. Do we want snaps UI to be an RPC request? What if some snaps want to have UI that lives permanently in some place in the extension? i.e. headless snaps?
   4.1 With the wallet.request method it seems that we will be reconstructing the UI only ever when a snap runs?

The main purpose for the RPC request is to let Snaps show a custom confirmation, popup, etc., similar to the snap_confirm JSON-RPC method. "Permanent" UI can be implemented differently, like how the SIP describes implementing UI for transaction insights. For headless Snaps we could expose a new entry point.

4.2 Might be a stupid question, but isn’t the ButtonClickEvent interface circular with extending UserInputEvent? (as UserInputEvent is just equal to ButtonClickEvent)

Good point. ButtonClickEvent is meant to extend a generic Event type, i.e.:

interface Event {
 type: string;
}

And UserInputEvent should be a union of all the supported events. I'll update the SIP to clarify this.

5. Is the idea that the UI key-value in snap_showInterface is an object with the top level component and then any other components nested inside children and so on and so forth?
   5.1 If so, I think this lends itself well to my idea of having a CSS key.

The idea is that each UI consists of a single root element, similar to how in React you can't render an array of elements directly, without wrapping it inside another element.

The ui property of the snap_showInterface specifies the root element, which can have children, depending on the component you're using. Right now, we only have the Panel component for that, but in the future there could be other components that accept children.

6. I think snap UI should be an endowment, maybe something like "endowment:user-interface"
   6.1 We can then use snap_showInterface to render UI for certain APIs like tx-insights

I think this adds a bunch of complexity, like handling a JSON-RPC method differently for different entry points (onRpcRequest versus onTransaction, ...). With the current implementation, Snaps can just return the UI in the onTransaction entry point, meaning that they need the endowment:transaction-insights permission to make use of the custom UI in the first place.

Snaps could for example show a button which opens a new pop up using snap_showInterface, from within the transaction insights.

6.1.1 The issue with that is that what if you render some sort of UI for the tx-insight tab that needs to stay there as long as the user is on the tab? Seems like something that shouldn’t be defined in the UI api but something that is just handled on the front-end. This would work for static user interfaces, for dynamic interfaces maybe we can have some state-machine mechanism defined for different components? I.e. a form would always end up to a certain state (perhaps displaying a result from the form action (be it some success or error state).

I'm not sure if I understand the problem?

3.1 Can't we define a set of CSS rulesets?
3.2 Instead of mode maybe we should have a CSS key

I'm not sure what you mean by that.

As far as CSS rulesets, I meant maybe we should have a pre-defined set of CSS rules that we allow for the components. I.e. display, flex related rules, font, etc. In order to avoid anything funky we can impose restrictions on those rules and completely disallow certain rules? I thought only having rendering children horizontally or vertically might be l limiting?

I think this adds a bunch of complexity, like handling a JSON-RPC method differently for different entry points (onRpcRequest versus onTransaction, ...)

I don't think that's too bad to implement technically, we already have handler types. I suppose I don't disagree with your method, especially for v1.

6.1.1 The issue with that is that what if you render some sort of UI for the tx-insight tab that needs to stay there as long as the user is on the tab? Seems like something that shouldn’t be defined in the UI api but something that is just handled on the front-end. This would work for static user interfaces, for dynamic interfaces maybe we can have some state-machine mechanism defined for different components? I.e. a form would always end up to a certain state (perhaps displaying a result from the form action (be it some success or error state).

I'm not sure if I understand the problem?

Sorry! Disregard this paragraph, I think I had some concerns based on the notion doc and didn't realize they were addressed here.

Solving the snap_dialog edge case, example from internal conversation:

exports.onRpc = async () => {
 const continue = await wallet.request({method: 'snap_dialog', params: { ui:
 { type: "section", children: [
 "Do you want to continue?",
 { type: "button", id: "shouldContinue", value: true, text: "Yes" },
 { type: "button", id: "shouldContinue", value: false, text: "No" }
 ]
 }}});
 assert(continue === true);
}
exports.ui.onPress = ({ location, action: { id, value } }) => {
 assert(location === 'dialog');
 assert(id === 'shouldContinue');
 return { action: 'close', value };
}

As you can see, snap_dialog is the only place where you can inject UI outside of returning it from exports.ui methods. There are some unsolved questions with that approach - would that call the exports.ui.onEntry as well?

Another solution would be to have the flow consistent:

exports.onRpc = async () => {
 const continue = await wallet.request({method: 'snap_dialog', params: { id: "confirmation" });
 assert(continue === true);
}
exports.ui = {
 onEntry: ({ location, action: { id }) => {
 assert(location === "dialog");
 assert(id === "confirmation");
 return { ui:
 { type: "section", children: [
 "Do you want to continue?",
 { type: "button", id: "shouldContinue", value: true, text: "Yes" },
 { type: "button", id: "shouldContinue", value: false, text: "No" }
 ]}
 };
 },
 onPress: ({ location, action: { id, value } }) => {
 assert(location === 'dialog');
 assert(id === 'shouldContinue');
 return { action: 'close', value };
 }
}

And a third one, would be a hybrid, in which onEntry would be called if no ui was provided in snap_dialog call, and not be called if the ui was injected in the call itself.

We're planning to add form components in the future, likely as part of another SIP. The aim of this SIP is to define an initial version of the UI API.

I'll keep this in mind when working on the next SIP!