You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi!
Since the store in the background page is just a wrapped regular Redux store with additional features, it is straightforward that it will operate with any middleware the same a single store does.
What is not so obvious, though, is using middleware on the Proxy store side.
I guess every time someone considers adding new middleware, it requires experiments to make sure it is workable. While logically the behaviour is most often predictable, I suppose that:
The middleware behaviour may be perfectly logical and can be more or less predicted, but it may still be surprising. E.g. redux-observable does work on the Proxy Side... but the epics behave as expected just for the tab that actually issued the action, -- which again is not a great surprise given how Proxy Store works -- but you need to double-check if you have no experience with webext-redux yet.
I don't know of any practical problems with attaching middleware to the Proxy Store, but I can imagine the single difference in dispatch synchronicity ( Unable to import deep diff strategy #178, Add short documentation on migrating from regular Redux #205 ) can cause some middleware to malfunction, so I guess you can never be sure unless you know the Proxy Store source well enough or you have made some experiments. In either case, I guess you would still be relieved to know that someone successfully uses some middleware in their project.
So I'm thinking of a trivial way to enhance the documentation with information on Proxy Store middleware support.
I guess this could be very helpful for someone considering to use webext-redux. Since middlewares are actually major parts of any Redux application, any doubts considering their possible usage with webext-redux can discourage you from using this framework.
I, for one, considered it one real risk that when I decide to use some new middleware that I always took for granted, it does not function as expected (BTW the other risk I was thinking of was #200).
subtle enhancement
I suppose if the Proxy Store is really expected to work for any middleware, it could be made clear e.g. by inviting anyone to post issues if they find a middleware that technically does not work -- just an idea. Anything to make it more plausible that indeed any middleware should work also on the Proxy Store side. This is a very simple idea but slightly vague yet and not that satisfactory.
detailed list
The more comprehensive solution could take a form of either a very simple list of successful uses reported by developers so far, or a more elegant, maintained list of major middlewares that are expected to work. Possibly with additional notes to clarify what behaviour might come across as unexpected.
For example (based on the middlewares I have tried out):
Middleware
Supported
Additional
redux-logger
partially
It can be used for debugging actions dispatched within the debugged tab
redux-observable
partially
All actions can be listened to only in the background page. However, can be used in a narrow use case when actions are always dispatched in reaction to other actions dispatched on the same tab
general guide
I can also imagine a more general approach like "This middleware is safer to use on background page but you can consider using it in the proxy store when ...". I'm not sure if it's workable since I suppose everybody's use case is different. But I'm thinking of a way to provide some useful insights on the middleware use in background page VS content script, including more details on the most popular middlewares.
what do you think?
Have you ever had any negative experiences? Or, conversely, you successfully experimented with a number of middlewares?
Or perhaps it has always been clear to you what middleware can be safely used?
Or you seriously doubt there are any use cases when applying a middleware on the Proxy Store side is reasonable?
The text was updated successfully, but these errors were encountered:
Hi!
Since the store in the background page is just a wrapped regular Redux store with additional features, it is straightforward that it will operate with any middleware the same a single store does.
What is not so obvious, though, is using middleware on the Proxy store side.
I guess every time someone considers adding new middleware, it requires experiments to make sure it is workable. While logically the behaviour is most often predictable, I suppose that:
redux-observable
does work on the Proxy Side... but the epics behave as expected just for the tab that actually issued the action, -- which again is not a great surprise given how Proxy Store works -- but you need to double-check if you have no experience withwebext-redux
yet.So I'm thinking of a trivial way to enhance the documentation with information on Proxy Store middleware support.
I guess this could be very helpful for someone considering to use
webext-redux
. Since middlewares are actually major parts of any Redux application, any doubts considering their possible usage withwebext-redux
can discourage you from using this framework.I, for one, considered it one real risk that when I decide to use some new middleware that I always took for granted, it does not function as expected (BTW the other risk I was thinking of was #200).
subtle enhancement
I suppose if the Proxy Store is really expected to work for any middleware, it could be made clear e.g. by inviting anyone to post issues if they find a middleware that technically does not work -- just an idea. Anything to make it more plausible that indeed any middleware should work also on the Proxy Store side. This is a very simple idea but slightly vague yet and not that satisfactory.
detailed list
The more comprehensive solution could take a form of either a very simple list of successful uses reported by developers so far, or a more elegant, maintained list of major middlewares that are expected to work. Possibly with additional notes to clarify what behaviour might come across as unexpected.
For example (based on the middlewares I have tried out):
general guide
I can also imagine a more general approach like "This middleware is safer to use on background page but you can consider using it in the proxy store when ...". I'm not sure if it's workable since I suppose everybody's use case is different. But I'm thinking of a way to provide some useful insights on the middleware use in background page VS content script, including more details on the most popular middlewares.
what do you think?
Have you ever had any negative experiences? Or, conversely, you successfully experimented with a number of middlewares?
Or perhaps it has always been clear to you what middleware can be safely used?
Or you seriously doubt there are any use cases when applying a middleware on the Proxy Store side is reasonable?
The text was updated successfully, but these errors were encountered: