Bi-directional widget postMessaging API (stickerpacks) [WIP] #1672
Conversation
…nt. iframe needs to initiate. Postmessage data up the stack.
package.json
Outdated
| @@ -58,6 +58,7 @@ | |||
| "classnames": "^2.1.2", | |||
| "commonmark": "^0.27.0", | |||
| "counterpart": "^0.18.0", | |||
| "dom-to-image": "^2.6.0", | |||
There was a problem hiding this comment.
This isn't actually used at this level btw
There was a problem hiding this comment.
Thanks. Yep, cruft that needs to be removed.
src/WidgetMessaging.js
Outdated
| - No additional fields. | ||
| Response: | ||
| { | ||
| screenshot: {data...} |
There was a problem hiding this comment.
Yup, a blob. I'll update the comment to reflect this.
rxl881
changed the title
Stop listening and cleanup endpoints correctly.
rxl881
changed the title
|
this looks fairly sane to me from a high level review - although it also looks as if this is separate from the scalar-facing postmessage API for integrations, rather than widgets? I assumed that by creating a base class for postmessage APIs it'd be extended both for widgets & integs? |
…sdk into rxl881/snapshot
Add comments for clarity.
|
@dbkr -- I think that I have now addressed everything from your review. Can you please have another quick check. Hopefully this is now ready to go? |
|
@dbkr -- One other thing (as discussed last week, I think), I'm assuming that the build errors from travis-ci can be ignored in this instance, right? |
|
i'm not seeing any build errors any more, so i think you're okay on that score... i assume it was the CI building against the wrong branches of the various projs. |
Extend the widget postMessaging API to allow bi-directional communication with widgets.
In part this adds the ability for widgets to pass their capabilities to matrix clients, so that client-side UI elements can be rendered appropriately.
@ara4n, @turt2live - This should be ready for (further) review now.