Still under development?

[Nantris]

The alpha version works fine for us, but I was wondering if this library is still under development since the alpha hasn't been updated in over a year.

Thanks for all the great work on this library!

[TheWashiba]

I think they have bigger concerns right now... https://news.ycombinator.com/item?id=32460342

[vitordino]

shameless plug here: i’ve wrote a really similar (and smaller) library if y’all are still interested..

it’s called reduxtron and i’ve just wrote a blog post about the journey and my motivations behind it

[Nantris]

I, for one, appreciate this shameless plug!

Is it the same as electron-redux in that each process has its own store locally? Or is it handled in some other way? Are there any other notable differences? And can state be segmented by process in any way? Eg if I have a big store but I only need to populate some portion of it in child windows, is there any way to avoid loading the big store in each process?

[vitordino]

hey there @Slapbox 👋

sorry for the delay, let me try answering some of your questions..

the tl;dr is that it might not suit all your needs as of now 😢

• Is it the same as electron-redux in that each process has its own store locally? Or is it handled in some other way?

  • reduxtron only enforces a single store, on the main process, other processes (renderer process, windows) have the 3 main functions (subscribe, getState, dispatch) on their global scope
  • that being said, you can definitely write your own logic for each process to "drop"/"select" just a bit of the store (eg.: by consuming the global subscribe but only appending the slice of the state that particular window is concerned). but, for now, the ipc messages underneath will likely contain the whole global store state.
  • i implemented this way to make it easier to ramp-up new applications that eventually share it’s whole state, but i see your use case as really relevant

• Are there any other notable differences?

  • the first one that comes to mind is that reduxtron doesn’t force or has opinions on what you have it on the browser windows, while on electron-redux you have a redux store on the main process + one for each window.
  • as some examples of this i’ve implemented:
  • couple boilerplates that the state change updates a frontend framework directly
  • a bridge between the redux store on the main process and zustand on the view layer, making type-safe hook selectors available on the frontend without a hassle (preventing unnecessary rerenders)

• If I have a big store but I only need to populate some portion of it in child windows, is there any way to avoid loading the big store in each process?

  • as stated above, you can avoid having a store per se, or cherry-picking only what you need on the consumer (browser window) side. i haven’t solved this “wholesale” where you would be able to limit the messages the main thread sends to each browser
  • for enabling this control i would need to figure a clean and flexible enough API — and i definitely haven’t thought about a specific one.
  • one idea would optionally leave all the message passing burden on a redux middleware when you want to have finer control on the main side, but i would see as an ”advanced usage” and not the standard configuration