Replies: 3 comments 4 replies
-
|
Beta Was this translation helpful? Give feedback.
-
It's essentially just a container around other elements. It could be a
I think that's an implementation detail, and not something we should specify in the SIP?
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.
I'm not sure what you mean by that.
The main purpose for the RPC request is to let Snaps show a custom confirmation, popup, etc., similar to the
Good point. interface Event {
type: string;
}And
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
I think this adds a bunch of complexity, like handling a JSON-RPC method differently for different entry points ( Snaps could for example show a button which opens a new pop up using
I'm not sure if I understand the problem? |
Beta Was this translation helpful? Give feedback.
-
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 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.
Sorry! Disregard this paragraph, I think I had some concerns based on the notion doc and didn't realize they were addressed here. |
Beta Was this translation helpful? Give feedback.
-
Components
RPC
GeneralI feel the gist I've written some time ago is more comfortable way to write UIs. Not only it is more similar to other features we have, such as keyrings, it also skips many implementation details not needed to be known by the user, such as maintaining the knowledge of which UI corresponds to which id. It exposes 3 methods:
All of the above return an object which can contain an action such as close the ui, or update the ui in question with new content. It's based on BlockingResponse api which also returns actions object. |
Beta Was this translation helpful? Give feedback.
-
|
Solving the 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, 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 |
Beta Was this translation helpful? Give feedback.
-
|
Hey, Another handy feature for us is "popups" that open a small popup that looks like an "Edit gas priority" popup and shows some text (or even describes an object similar to sign_typedData). In our case, this would be called from the "MultiSelect list" ("show more" button?) to display more details about the object user is selecting. Should a component like this be included in the SIP, or is this something we can build ourselves later on? And would something like that even make sense to be a part of Snaps UI? |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
SIP-7: Snaps UI can be discussed here.
Beta Was this translation helpful? Give feedback.
All reactions