search

klarna / electron-redux

Use redux in the main and browser processes in electron
MIT License
743 stars 94 forks source link

How can stopForwarding be used with actions from third party packages in cross-platform code? #297

Closed Nantris closed 3 years ago

Nantris commented 3 years ago

I'm thinking we're supposed to wrap the action creator definition with stopForwarding, but that's made difficult for third party packages, and I'm not sure how it could work for cross-platform code (run in React-Native.)

It seems simple enough to just copy paste the code to remove it from being wrapped up in a package that requires Electron/node, but I don't view that as very maintainable.

The old method of blacklisting seemed more flexible, but we didn't actually need to scope any actions in the past. We now need to do that due to changes to Electron's IPC which makes at least one of our actions throw an error when Electron-Redux tries to transmit it across IPC.

Am I misunderstanding this helper function? What benefits does this new pattern have?

Can anyone provide an example of using stopForwarding?

matmalkowski commented 3 years ago

The idea behind stopForwarding is to scope some actions to single process => and the stopForwarding function just returns action that is decorated with additional meta scope. You don't have to use it, since you can also create scoped actions like this with manually added metadata (I can imaging some frameworks that are responsible for creating actions that its impossible to hook in the decorating function - but its simply a helper, no logic there at all.

It behaves in similar way as the blocklist (just different evaluation criteria -> meta filed instead of action name)

Sorry, but I don't understand the take on the dependency on node? Could you explain a bit?

Nantris commented 3 years ago

Yeah I gave it some more thought and I guess it's more maintainable than I originally thought to implement it by hand, by just adding the properties the helper would add.

But to explain a little more on the bit about node dependencies; we use our shared action creators on React Native, and if we imported the helper there React Native would explode because Electron Redux requires things like ipcRenderer. We'll just manually add the scope: local ourselves for now.

But it still seems to be the case that this method is less flexible than the blacklist method used in 1.x. I'm not sure if there are some other benefits to this new method though.

Feel free to close this whenever you feel the discussion has run its course.

matmalkowski commented 3 years ago

Version 1.x blacklist is still part of the API in version 2 though, it's behavior is similar and available via options as denyList.