Included sender information in action information #41
Conversation
It can be helpful to know about who sent the message/action. An example of why this might be helpful is when using a content script to perform something tab specific. Without the tab information you won't be able to get the Tab ID or other useful information about where the action came from.
|
For each of my content scripts, I do the same dance and request the tabID from the background script via message passing and then pass it down as a prop through my entire app. Even though this kinda takes a step outside of the concerns of this library, I think it's enough of a common use case in developing a Chrome extension to be added. Enhancing actions also seems to be the way to do it. Thoughts @tshaddix? |
|
I think this is a great idea @durandj, and I've run into the same problem myself. I even started a branch and started working on this addition a few months ago. I'm personally not against the API change proposed in this thread. @vhmth what are your thoughts on the proposed API change? The public API doesn't change really, but the action side effect does (adding a @durandj Thanks for working on this! |
|
@tshaddix, what are your thoughts on a way to do this without a side effect? I agree that a side effect like this one isn't ideal but it was simpler to implement without a ton of changes and should be relatively transparent to the end user. |
|
@durandj Sorry if I wasn't clear in my response. I like your solution quite a bit. I just wanted a second opinion before moving forward. |
|
No problem just making sure :) |
|
@durandj To answer your question: I really don't see a good automatic way to do this without some side effect. We could include some interface/handler that allows message interception before dispatch and include some implementation of this interface that includes the sender, but that seems like overkill for the problem we are trying to solve. I think your solution does a good job of being simple and complete while making use of existing APIs and expectations. We should make sure to update the documentation in the README when we move forward. :) |
| @@ -44,7 +44,11 @@ export default (store, { | |||
| */ | |||
| chrome.runtime.onMessage.addListener((request, sender, sendResponse) => { | |||
| if (request.type === DISPATCH_TYPE) { | |||
| dispatchResponder(store.dispatch(request.payload), sendResponse); | |||
| const action = Object.assign({}, request.payload, { | |||
| _sender: sender, | |||
There was a problem hiding this comment.
Can we remove the trailing comma here?
There was a problem hiding this comment.
Sure no problem! Force of habit from my works style guide.
There was a problem hiding this comment.
I hear you! I'm not against it in principle! Just want to stay consistent within the package :)
|
Yep I'm 100% cool with this. We can add to the README when we bump the version @tshaddix |
|
👍 |
It can be helpful to know about who sent the message/action. An example
of why this might be helpful is when using a content script to perform
something tab specific. Without the tab information you won't be able
to get the Tab ID or other useful information about where the action
came from.
The exact use case I have is I'm creating a Chrome extension that has
a page action. The page action should only be available based on the
availability of a script being on the page (it's a work thing). Chrome
allows for this on a per tab basis but you need the tab ID to be able
to do this. My content script can't access this information except by
sending a message. I'm already sending a message when I dispatch
an action. It would be helpful to get this information from the action
on the background side of the extension.