Closed goosewobbler closed 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 (:
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
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.
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
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 withreduxtron
. 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
?