-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Messenger for sidebar bricks #1642
Conversation
registerActionFrame: getMethod("REGISTER_ACTION_FRAME"), | ||
forwardFrameNotification: getMethod("FORWARD_FRAME_NOTIFICATION", { | ||
isNotification: true, | ||
}), | ||
showActionFrame: getMethod("SHOW_ACTION_FRAME"), | ||
hideActionFrame: getMethod("HIDE_ACTION_FRAME"), | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test report
Working
- REGISTER_ACTION_FRAME
- SHOW_ACTION_FRAME
- HIDE_ACTION_FRAME
Untested
- FORWARD_FRAME_NOTIFICATION
Can you tell me what I should set up to test this? I have not ported it messenger yet because a couple of key components might be missing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FORWARD_FRAME_NOTIFICATION is used to pass information from the content script on the main page to the sidebar panel. It's used in many of the methods in actionPanel/native.tsx
via calls to renderPanels
The way to test would be:
- Create a sidebar panel using the page editor: e.g., https://docs.pixiebrix.com/tutorial-trello-status-sidebar
- Save it
- Toggle the side bar on/off
- Go to a different page and toggle it on/off
If the messages aren't working you won't see the header for the panel and won't see any panel content on pages where the panel should appear
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good to merge once we switch the effect method definitions back to keep the stack trace/for consitency
Test report updateWorking
|
Here I replaced sendMessage-based handlers (not
liftBackground
)Pretty straightforward, except that it made me question a few things:
Particularly around something I have not touched yet:
forwardWhenReady
/RENDER_PANELS_MESSAGE