vitordino / reduxtron

:electron: end-to-end electron state management
http://npmjs.com/package/reduxtron
23 stars 2 forks source link

Thunk support? #1

Closed goosewobbler closed 6 months ago

goosewobbler commented 7 months ago

This is a cool project, I'm suprised there's not more interest in it. I have an old app which uses a custom version of electron-redux, I'm looking to see if I can replace the state management with reduxtron. My app uses RTK heavily and thunks in particular don't seem to be supported currently -- dispatch in the boilerplate and demo packages only accepts an action.

Is this a planned feature, or is there another way to use thunks with reduxtron?

vitordino commented 6 months ago

Hey again @goosewobbler,

thanks for the kind words (: i never publicized much this library (i still believe on much of it’s value tho) if i ever find the time to polish it, i will try to find some energy to properly publish it


reduxtron rely on a ipc "bridge" that can only pass serializable values between processes.

as thunks have promises — not easily serializable — and as the redux store lives in the main process: we can’t send thunks from the renderer process (inside the frontend) to the store.

i haven’t used RTK much, but i believe it export hooks that fire those thunks.. a possibility to overcome this would be to keep RTK only on the main process, and write hooks (if you use react) that fire simple (serializable) actions and return the result of the specific selector.


i sketched something similar (but inspired by swr) on the demo app, where i could fetch both URLs and the user’s filesystem:

it was more of a long-running exploration tho on a production app i’d probably rely on a maintained/well tested library for doing this request/caching bit (like RTK)

so i believe it might be possible to use much of RTK, but tweak the consumption (dispatch/reducer) part on the frontend to be "reduxtron friendly"


spoiler: different than electron-redux on reduxtron the frontend doesn’t need redux (:

vitordino commented 6 months ago

additional investigation needed: maybe there’s a way of serializing promises across ipc? 🤔

i see some libs (and some issues) regarding this possibility..

i’ve still haven’t had the need, but might be possible and help with your issue


if we ever accomplish this feat, it would likely be an reduxtron option. as it would add extra layers of serialization/deserialization because electron’s ipc demands html’s structured clone algorithm

goosewobbler commented 6 months ago

Thanks a lot for the information, it's an interesting set of problems for sure. As for my specific use case I have been considering some ideas about how to handle these thunks, now looking at implementing a completely different approach to the state management. I'll close this now as my questions have been answered.

vitordino commented 6 months ago

it’s interesting for sure! if you only use redux for RTK and consume directly using the hooks on the frontend maybe it makes sense to just send the saved state (request cache) to the main process — eg.: using a middleware on the frontend to call the reduxtron’s setState function 🤔 (having 2 redux stores)

it really depends on how/what you use, the ergonomics you need etc