Extended return type of invokeAction() #561
Conversation
| <p> | ||
| The <dfn>error</dfn> property represents a possible error, initially `null`. | ||
| </p> | ||
| <p class="ednote" title="Should state be a function or an attribute only?"> |
There was a problem hiding this comment.
I started with a function but I start thinking an attribute should be sufficient..
There was a problem hiding this comment.
An action is supposed to be always polled? Or could a script subscribe just for changes in status?
There was a problem hiding this comment.
I think observing state changes would be nice but I am not sure whether that is actually necessary...
There was a problem hiding this comment.
Mhh, I tend to think now that a a function for reporting the status would be more powerful and useful. What do people think? Other ideas?
There was a problem hiding this comment.
Mhh, I tend to think now that a a function for reporting the status would be more powerful and useful. What do people think? Other ideas?
Hmm, if I see it correctly, we could also treat the attribute as a getter and add more logic to that if needed, right?
Or could a script subscribe just for changes in status?
If we wanted to that, what would be the best way to model that? Adding a way for registering a callback function?
There was a problem hiding this comment.
Mhh, maybe we should decide what we need/want from the status
- is it likely that requesting the status may take a while? (or put differently do we need a Promise)
- do we need a way to observe a status change (would be nice but adds complexity)
My take is that having a promise function for status() is fine while I am not 100% sure we should allow for listening status changes...
Are there opinions/proposals?
index.html
Outdated
| "success", /* Profile uses completed? */ | ||
| "error" /* Profile uses failed? */ |
There was a problem hiding this comment.
Should we coordinate in some way with the Profile TF to align the terms that are being used? Or is it no problem if they differ, since they are operating on a different level anyway?
There was a problem hiding this comment.
Good point. Once we feel comfortable with our choices we should definitely reach out. Most of the status terms are 1:1 matches. What seems different is pending.
There was a problem hiding this comment.
FYI: Profile has 4 terms
pending--> we don't have a corresponding term!running-> same ✅completed-> we usesuccessinsteadfailed-> we useerrorinstead
What can we do with aligning the terms? Use the ones from profile or talk to them? Any opinion?
There was a problem hiding this comment.
Hmm, their terminology actually sounds quite good to me, so from my side we could also adopt what they are using.
There was a problem hiding this comment.
I am fine withe the Profile terms also. The question remains if it is fine dropping "pending" then... (same same but different 🙃)
Other opinions?
|
We have some inline discussions which need some more feedback. Please chime in with your opinion! |
| <p> | ||
| The <dfn>error</dfn> property represents a possible error, initially `null`. | ||
| </p> | ||
| <p class="ednote" title="Should state be a function or an attribute only?"> |
There was a problem hiding this comment.
Mhh, I tend to think now that a a function for reporting the status would be more powerful and useful. What do people think? Other ideas?
Hmm, if I see it correctly, we could also treat the attribute as a getter and add more logic to that if needed, right?
Or could a script subscribe just for changes in status?
If we wanted to that, what would be the best way to model that? Adding a way for registering a callback function?
index.html
Outdated
| "success", /* Profile uses completed? */ | ||
| "error" /* Profile uses failed? */ |
There was a problem hiding this comment.
Hmm, their terminology actually sounds quite good to me, so from my side we could also adopt what they are using.
Co-authored-by: Jan Romann <[email protected]>
I started to work on a PR to show a possible solution how the extended return type
ActionInteractionOutputforinvokeAction()may look like.resolves #555
Preview | Diff