Thunk support? about reduxtron

[goosewobbler]

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]

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:

• reducer
• hook
• usage for http
• usage for file-system

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]

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

[vitordino]

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