🔥 The road to electron-redux 2.0

[matmalkowski]

In this issue I would like to create a clean overview and expected features that would make up for the next major release, the 2.0.0

What should be part of v2?

• Typescript rewrite - given the current state of community and great adoption of Typescript in multiple projects, we would like to see native support for the Typescript
• Support for using Map and Set types in stores - serialize and deserialize Map and Set objects for initialising renderer state - please see Thoughts for 2.0 #171
• API simplification please see Thoughts for 2.0 #171
• Remove Electron's remote dependency - the Electron-exposed remote dependency is being deprecated and we should consider removing it
• Documentation website - for project like this, it would be great to have a nice, stand-alone website with complete documentation, API & examples baked in

When the v2 could be expected

We would like to start working on the new version in October 2020. It would also mean that some of the changes could be great opportunity to get your contributions during the Hacktoberfest!

Please use this issue to submit your feedback about expected feature set, ideas on what could be added as part of this major release, as well as interest in contributing to that huge change!

Tagging @partheseas since we would love to use your TS refactor from the fork 😄

[aslilac]

Go for it!

[Kupstas]

Any news. I can't migrate to 11 electron because of remote dependency

[matmalkowski]

@Kupstas , still doing some work on it, but the main thing is right now available as an alpha release - we still might change the API a bit, as we got some more tickets with TS to cover (& some features might not yet been ported). Feel free to take it for a spin, latest version is 2.0.0-alpha.5

The code is on alpha branch

[aslilac]

@Kupstas You can use Electron 11, you just need to add some config

new BrowserWindow({
	webPreferences: {
		enableRemoteModule: true,
		nodeIntegration: true,
	},
});

Or you can use my fork, "@mckayla/electron-redux", which is actually what this update is being rebased on.

[Nantris]

@matmalkowski is it planned to remove the Redux state from the global scope of the main process, since remote.getGlobal() will no longer be in use?

[matmalkowski]

@slapbox V2 doesn't expose redux state globally anywhere for main nor renderer

[linonetwo]

@partheseas

Do we still need enableRemoteModule: true, ? I can see latest v2 have removed it.

And I think nodeIntegration should be false, so we can keep our preloadScript.

[aslilac]

@linonetwo So to be clear, I'm the maintainer of "@mckayla/electron-redux". This repo is for the package "electron-redux".

For "electron-redux", enableRemoteModule is no longer needed, but nodeIntegration is still required in v2.
For @mckayla/electron-redux, in v3 I removed the nodeIntegration requirement in favor of using preload instead.

[aslilac]

@matmalkowski I've actually been meaning to reach out to you guys about that. I've updated my fork to no longer require nodeIntegration to be enabled, and you're more than welcome to look at my implementation and do the same!

[linonetwo]

Great work @partheseas , That will make it more secure for apps with dynamic content like the one I have.

[matmalkowski]

@partheseas Nice :) We will evaluate how to do this in v2 as well than 👍🏻 (And if anyone is eager to do it, we are happy to help with the pull request 😉)

[benjaffe]

One neat feature to consider is allowing configuration of what clients electron-redux forwards to. In my team's case, we have a desktop app with multiple separate stores, one for each file we're opening. And for each file, we have 1 or more associated renderers.

I haven't thought it through fully, but it might be simple to allow users to use electron-redux, passing in config which isolates the communication to a particular channel over ipc, allowing multiple instances to run independently without stepping on each other.

Just posting this here as food for thought. Thank you all for your work on electron-redux <3

[Nantris]

@benjaffe what's the use case for multiple independent stores?

[benjaffe]

Oh goodness, sorry the notif slipped by me. My electron app handles media project files (like Photoshop does with PSDs for example), and the app can have multiple project files open. These files can be very large, so while I could use a single store with each project file as an entry in a top-level map, it would only slow things way down for us (on things like revert operations for example, where every client would need to do a bunch of stuff, even though it only matters to a single client). The project files (and the associated windows we open for them) are entirely independent from each other.

It's much easier to reason about and more performant to have a store for each project file. Happy to provide more info if that'd help clarify this use case.

[Treverix]

The remote module was removed with Electron 14 which has just been released. electron-redux now needs to be updated to use @electron/remote instead, which is a full replacement.

[Nantris]

@Treverix please see the alpha branch for the new API. remote will not be included in electron-redux@2.x to my knowledge.

[binarybaron]

Is this planned to be released eventually?

[Nantris]

@binarybaron doubtful. Klarna suffered layoffs around the time things got quiet here. We've used the alpha versions of 2.0 in production for years without trouble though.