Electron-react-boilerplate: Roadmap for Release 1.0.0

[amilajack]

Release 0.11.0

• [x] Fix debugger statement devtools integration
• [x] Babli and babel-preset-env support
• [x] Migration to Jest
• [x] Webpack DLL support
• [x] Document configuration
• [x] react-router-4 migration
• [x] Route based code splitting
• [x] webpack-bundle-analyzer

Release 0.11.1

• [x] Support debugging packaged app

Release 0.12.0

• [x] Folder refactoring, add ./internals dir

Release 1.0.0

• [x] Complementary website
• [x] Auto Updater
• [x] Artifact support
• [x] Add electron-redux support
• [ ] Debugging main/renderer processes
• [ ] Video Tutorial Series

Please comment if you want to discuss the addition/removal of features.

[ChinW]

Hot reload main process would be cool and useful for me.

[dustintownsend]

What about adding some of these:

• Redux Saga (instead of thunk)
• Redux Persist
• Redux Sauce (to reduce Redux boilerplate)
• ImmutableJs or Seamless Immutable
• Reactotron (not sure if it would provide more than current dev tools or not)

Not sure if those types of things would be out of scope for this boilerplate or not?

[amilajack]

@dustintownsend I think we should use Reactotron and redux persist. I'm not very familiar with redux and its ecosystem so I'm not sure about redux-saga. What does it do? Does it require the user to know about it for them to use the boilerplate? I've read that its a middleware so I assume that the user of the boilerplate doesnt have to worry about it

[tsemerad]

redux-saga is a good solution for handling async logic, or any other side-effects (such as dispatching redux actions in response to other actions). It is often used instead of redux-thunk, which is also used for the same purposes. I prefer redux-saga to redux-thunk because it provides many high-level tools and patterns for managing async logic, but it does come at a significant learning overhead compared to redux-thunk.

Does it require the user to know about it for them to use the boilerplate?

It is definitely significantly more complex than using redux-thunk. It requires learning about generator functions and redux-saga's "effects" system, which has great documentation, but is significant.

As for whether it should be included in the boilerplate, that's a good question. I'm on the fence.

[rsaccon]

I use electron-redux for store sync between renderer and main, it works perfect, easy to use and customizable, and for async actions I use redux-promise-middleware, which enables optimistic state upgrades (fires pending, fulfillled and rejected actions). Saga seems way more complicated (to me, at least)

[jhen0409]

Redux Saga (instead of thunk)

I still want to keep this boilerplate simple, there are too many options for side effects (like I used redux-observable instead of saga), I think it would be better if it could be in another boilerplate.

Reactotron (not sure if it would provide more than current dev tools or not)

Attention to https://github.com/reactotron/reactotron/issues/239 if we want use it and redux-devtools-extension together.

[amilajack]

I still want to keep this boilerplate simple

Agreed

[dustintownsend]

@amilajack @jhen0409 what do you think about putting the core pieces of this boilerplate into something like CreateReactApp? (thinking mainly just the module aspect and not necessarily the CLI).

My goal of this would be to just include the module in my project and hide away the boilerplate. This would make keeping apps in the wild up to date easier than upstream merging.
Also, people could create specific modules for things like redux-saga and redux-observable.

Then this boilerplate project would just reference the modules that are considered the defaults, but when someone cloned it they could switch out modules as they needed.

Reading back through this, I guess what I've described is a framework and not a boilerplate haha.

[amilajack]

I think this idea is promising and should be the direction forward. Concerned about the complexity this would bring. How can we do this elegantly?

What if users could check off what they wanted support for? Ex:

- [ ] Flow         - [ ] Typescript
- [ ] SASS         - [ ] Less
- [ ] Redux        - [ ] Mobx
- [ ] redux-saga   - [ ] redux-overvable

Reminds me of a 'yeoman' kind of experience. How would we go about updating specific parts of the application, based on what was selected?

[dustintownsend]

I think we would need to create multiple packages and use Lernajs for that. There would be a package for each feature or whatever is deemed necessary to be in a separate package. The packages that are selected will be included in the package.json, so that will handle updates.

I'm not sure about how someone would go about selecting packages. I think at first it would just be npm install package-name. Then if needed we could look at using something like yeoman or creating a cli to make the dev experience better.

I think at the very least we could consider splitting out just the core of the boilerplate into a package and go from there.

[dustintownsend]

@amilajack What are you thinking for Auto Updater?
I have implemented the new AutoUpdater from ElectronBuilder/NSIS for Windows. I know last I checked they didn't have a non squirrel updater for Mac yet. The app I'm working on is an enterprise app and is only targeted for Windows, so i didn't look too much into the updater for Mac.

My implementation uses IPC and Redux Saga, because I wanted to display feedback to the user and thought keeping the status of the check in Redux made sense for my case.

But, maybe for the boilerplate a simple main process implementation would be better. Also, the ElectronBuilder NSIS AutoUpdater API matches the Squirrel API. I assume that we will need to make it switch between Squirrel and NSIS.

[dustintownsend]

@chentsulin @jhen0409 @amilajack what do you all think about putting these items into the Projects feature of GitHub? I haven't tried it yet on GitHub, but I am a fan of KanBan.
https://github.com/chentsulin/electron-react-boilerplate/projects

[dustintownsend]

@amilajack I think that our discussion of splitting things up should be done in a 1.x release. Since that would be a breaking change. Assuming we are following semantic versioning.

And I think that we could follow the model of React-Boilerplate. What I was considering the "Core" of the boilerplate is called "Internals" see: https://github.com/mxstbr/react-boilerplate/tree/master/internals

So if we want to continue in that direction I propose that it is moved to a 1.0 release. I think we should try to focus on some key improvements that won't break (at-least not too bad) people using 0.10. I'm thinking that Route based code splitting, Hot reload main process, and Webpack DLL support should be removed from the list to be done in a 1.0 release, since I think those changes would break current applications.

Thoughts on that direction?

[amilajack]

I'm still not sure if its worth the complexity. What if we could use react-boilerplate into the boilerplate and we could just add the electron integration?

[develar]

https://github.com/electron-userland/electron-builder/wiki/Auto-Update

Serverless auto-update on macOS will be implemented this week (https://github.com/electron-userland/electron-builder/issues/1089)

[derwaldgeist]

I'd like to chip in that flow adds unnecessary complexity to this boilerplate. For people like me who like to cherry-pick good practices from such boilerplates, it makes it unnecessarily complex to do the transformation to an own custom app. I would prefer if this boilerplates just focussed on what it says in its title: Electron, React and all necessary stuff (like Webpack) that is actually needed. Instead of blowing it up from the functional side, I would like to see more samples of advanced Electron functionality, like IPC communication and multi-windows support. Just my 2 cents.

[talha131]

I'd like to chip in that flow adds unnecessary complexity to this boilerplate.

On the other hand, I find addition of flow very useful. If it had been present from the beginning, I would not have wasted time in chasing few bugs that I am sure flow prevents.

User can always remove flow checking by removing // @flow from the file.

Judging by discussion in this thread, and few others asking for typescript support for example, it seems project needs to be divided into smaller starter projects that can be easily integrated with each other.

Check out this link Mega Boilerplate. It lets you select framework, libraries, database etc to auto generate a boilerplate for you.

With this, everyone would be able to a custom ERB for himself, like with or without flow, typescript, redux-saga etc.

Though personally, I prefer this present structure. I like how maintainers choose best available options and integrate it to boilerplate. For beginners it is essential that someone more experienced guide them towards better libraries and practices.

Experienced users can tweak the boilerplate to their liking easily.

Perhaps a better middle ground is to offer guides in Wiki on how to add or remove certain library from the project. This will be maintained by the community.

[amilajack]

I'd like to chip in that flow adds unnecessary complexity to this boilerplate

As @talha131 noted, its hard to strike a balance between finding an experience that caters well to everyone. I'm going to add guides on how to remove or replace certain parts of the stack (ex. replace flow with typescript, redux with mobx, etc).

@derwaldgeist Also I'd like to know what parts of flow you found complicated. Maybe I can make adjustments to the boilerplate based on your experiences. I'm sure others will experience something similar to what you have.

I would like to see more samples of advanced Electron functionality, like IPC communication and multi-windows support. Just my 2 cents.

I've been wanting to add complex examples for a while now. I'll get to this sometime over the summer.

[derwaldgeist]

@amilajack Thanks for your reply! Well, it was basically that I had to remove all these type annotations. If you have to do this, cherry-picking the boilerplate is a bit more work than just copy-pasting the code. Not a big deal, but I guess there's not that many flow users out there. I myself prefer to stick to stuff that's standardized and am quite reluctant with picking up frameworks that may vanish or become unmaintained quickly. So, for me ES6 is the way to go, even if I clearly see the benefits of strong typing.

Regarding the complex examples: That would be awesome, and I already saw that you're planning to provide a Redux sample. Awesome! This whole IPC stuff makes things quite complicated.

[johanetox]

morning @everyone I just made a boilerplate for my company out of this one refactored for stateless components, plus sagas, immutable and some other things please take a look and give some feedback I didn't pull request because is totally different, thank you!
https://github.com/Liftitapp/electron-react-sagas-starter

[Dmitry1007]

How far along are you with getting autoUpdater integrated? I'm having problems setting this up myself due to the lack of resources online :(

[amilajack]

@Dmitry1007 i havent messed around with auto updates in electron because I dont have a developer license with apple. I'll need to get one before i mess around with this in the boilerplate. Unfortunately developer licenses are pretty expensive 😢

[aguynamedben]

For release 1.0.0 it would be interesting to see a built-in way to push work to a background process. There are a lot of related issues in this repo with people figuring out the DIY solution, and this is a common gotcha in electron.

In my project I've followed the DIY approach. I have a background.html and app/background/index.js. It becomes tedious to send IPC messages between processes to initiate work because electron's built-in ipc isn't Promise based. I have a version that uses gRPC for ipc, so I can await the backend process from the renderer process. That works nice, but gRPC introduces some additional boilerplate.

The ultimate nice-to-have is an API like electron-userland/electron-remote. It dynamically spins up and down additional renderer BrowserWindow instances to do work.

import { requireTaskPool } from 'electron-remote';
const myCoolModule = requireTaskPool(require.resolve('./my-cool-module'));
// This method will run synchronously, but in a background BrowserWindow process
// so that your app will not block
let result = await myCoolModule.calculateDigitsOfPi(100000);

Unfortunately after days of trying I'm unable to get electron-remote working with the Webpack approach the boilerplate uses.

It would be great if electron-react-boilerplate came with a pre-canned solution for pushing work to a background process.

[amilajack]

Official roadmap moved to website