📣 Tell me how you're using electron-react-boilerplate

As a maintainer it really helps to know how people are using this boilerplate. Getting an idea of how people are using the boilerplate can help me correctly prioritize features based how people are using the boilerplate. Answers to the following questions would be appreciated.

1. What kind of app are you making? (Optional)
2. What is the scale of the app (small, medium, large)?
3. What is the size of your team? Are you working on this by yourself?
4. Do you parts of the boilerplate do you find frustrating?
5. What parts of the stack (ex. react, electron, webpack) do you have the most troublesome or frustrating?

1. Several apps, meant to work in a closed local network (something that provides other functionalities besides a bigger, native desktop app) with a SQL server, WCF backend. (the horror...)
2. Small to medium
3. Working on this by myself, the rest of the team being on the native app
4. Not frustrating per se, just that as a boilerplate it feels as if it's been made to hold the minimum amount of starting code; now I can understand that, and it's a perfectly valid point of view, but usually I find myself adding all sorts of things at the start of dev (localization with i18n, electron-window-state, plopjs to facilitate the creation of new modules, immutablejs/seamless-immutable + redux-persist for snappy app resume), it would be perfect if you had branches as "flavors" to allow a more streamlined starting process, something like a branch with "material-ui + i18n + plopjs + immutablejs", or "blueprintjs + i18n + seamless-immutable", or better yet a branch with mobX instead of Redux for small projects, where Redux is just overkill. Although I understand that'd be a greater load of work for you, so I'm guessing you'd be reluctant. Other than that, I'll admit I kinda hate the separation of containers, actions and reducers, and this ever since I worked on a RN project with Pepperoni, I really liked both the file organisation (organizing in folders by module, and not by functionality) and the fact that they just jammed three files worth of code into one. Granted, the files can sometimes become a little bloated, but I liked it more overall.
5. Obviously Webpack; for all its benefits it's incredibly frustrating to tweak, the documentation being more than opaque doesn't help and the SO questions are... curious at best... but it's manageable and the benefits are too great so I don't think there's anything for you to do here.

I hope this helps :)

• What kind of app are you making? (Optional)

Mostly a "Learning experience" kind of app. The thing I was using for Pomodoros got killed, so I'm essentially remaking it. And I wanted to use Electron for it, to learn it. But I tend to get bogged down on the details so I usually "just do it" the first time around, and take more time to read more docs/etc the second time around.

• What is the scale of the app (small, medium, large)?

Small

• What is the size of your team? Are you working on this by yourself?

Myself, I might ~~coerce~~ invite a friend to maintain the OS X builds once this is done since I don't reboot to it often.

• Do you parts of the boilerplate do you find frustrating?

There's way too much of it all, I get you guys are trying to cover a lot of use-cases, but I wanted a kickstarter and I feel like I got a bit more of a "You wanted a banana but what you got was a gorilla holding the banana and the entire jungle".

I might've benefited from choosing a smaller solution, but since I don't know much about electron I wasn't too sure if they were somehow messing up, and this has a lot of stars so there's some degree of a popularity follows guarantee there.

Next time I make an electron application I'll definitely just roll my own, though. Even for a large enterprise application I wouldn't use this again.

• What parts of the stack (ex. react, redux, electron, webpack) do you have the most troublesome or frustrating?

Flux is throwing tons of errors, app veyor is crashing (On your PRs as well, for the same reasons), but all in all I'm adapting.

What kind of app are you making?

consumer apartment hunting app. works kinda like a web browser but gives users (and their groups) extra features to manage an apartment-hunt (plug: screencast)

What is the scale of the app (small, medium, large)?

small but growing!

What is the size of your team?

small, 3 ppl, 1 main dev

Which parts of the boilerplate do you find frustrating?

I had some (not too much) trouble customizing the build pipeline. electron-builder docs are great, but maybe some diff't examples w/ this boilerplate would've helped a bit.

the 2-json structure also had some 'gotchas,' but this was mainly b/c i wasn't familiar w/ native modules (as is the case, i would hazard to guess, for most folks coming from browser dev)

What parts of the stack (ex. react, redux, electron, webpack) do you have the most troublesome or frustrating?

'frustrating' is a strong word, but coming from all those same techs on the browser side, electron is def. the steepest learning curve. the build/deploy process felt especially daunting at first ("auto-update"? "artifact?" huh?). smart on it now but was an adventure.

What kind of app are you making?

• Frontend app that works along with a REST or WebSocket backend.
• Stand alone self sufficient apps (no need for a backend or web requests).

What is the scale of the app (small, medium, large)?

• Small

What is the size of your team? Are you working on this by yourself?

• 1 dev (me)

Which parts of the boilerplate do you find frustrating?

• Nothing, so far i really enjoy this boilerplate. There is not too much dependencies and other useless stuff that i would like to remove before starting a new project. And most of the time it works as expected (when js dependency nightmare don't fuck this all up). I disagree with @Unforgiven-wanda who would like to have more dependencies, i believe this would create confusion for new users and will require time to get ride of deps you don't need. A boilerplate is meant to be simple, if it requires too much investment to remove all the things you don't need, there is no point in using it.

What parts of the stack (ex. react, redux, electron, webpack) do you have the most troublesome or frustrating?

• webpack : great tool, but still way too complicated to tweak. There is a hundred ways to do what you want, but also an oher thousand way to break the whole build. (IMHO)

What kind of app are you making?

CashNotify — monitor your Stripe accounts from your Mac's menu bar 💰.

What is the scale of the app (small, medium, large)?

Small-ish: 32 components, 56 actions, 20 dependencies.

What is the size of your team?

2 people — doing everything related to the business, so far from full-time developers.

Do you parts of the boilerplate do you find frustrating?

We really like what you've decided to include in the boilerplate and the default configuration. For us there is not too much, this is just right.

The latest releases do address several of our frustrations, for example the difficulty of debugging a production build. We will upgrade soon.

Suggestions:

• When we started, I had the wrong idea that if there was 2 package.json, I had to run npm install in both /app and /. This created issues. Maybe there could be a warning message when trying to npm install in /app?
• We’d like to publish the app to the Mac App Store. We would love some kind of tool / linter to detect which functions are not allowed on the MAS (e.g. auto-update, crash report, etc.), and give some warnings or better, best-practices to remove / migrate.

What parts of the stack (ex. react, redux, electron, webpack) do you have the most troublesome or frustrating?

• Webpack

Thank you @amilajack @chentsulin @jhen0409 for this amazing project!

What kind of app are you making? Multiple apps

What is the scale of the app (small, medium, large)? Medium (distributed internal business applications)

What is the size of your team? Are you working on this by yourself? Solo!

Do you parts of the boilerplate do you find frustrating? I would say the wiki is very weak. Very hard to troubleshoot other than by yourself by trial and error. Would love to have more information.

What parts of the stack (ex. react, redux, electron, webpack) do you have the most troublesome or frustrating? The stack is pretty straightforward. I have some problems with the packaging at the end though, mostly on how to use electron builder to package everything.

@Unforgiven-wanda Could you please tell me about using MobX. I try to put babel transform decorators legacy but didn't succeed. Using MobX without decorators is a pain.

@nantaphop Haven't used MobX with this particular boilerplate, instead with another one (I'm sorry, I can't remember its name) I'm away for a few days, but I'll give it a shot when I'm home and let you know.

Oh, I already succeeded on add decorators to this boilerplate. It just about babel plugin order. Thanks.

On Sat, 14 Oct 2017, 02:22 Unforgiven-wanda, [email protected] wrote:

@nantaphop https://github.com/nantaphop Haven't used MobX with this particular boilerplate, instead with another one (I'm sorry, I can't remember its name) I'm away for a few days, but I'll give it a shot when I'm home and let you know.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/chentsulin/electron-react-boilerplate/issues/1106#issuecomment-336544917, or mute the thread https://github.com/notifications/unsubscribe-auth/ABpToj6l670cOrmAVUbjndtP4hvwmjFiks5sr7h7gaJpZM4OI6Fe .

To make Recollectr (Notetaking/Knowledgebase)

Thanks very much to @chentsulin and especially to @amilajack who helped me figure out some of the toughest bugs I faced.

What kind of app are you making? (Optional)

Just an internal tool

What is the scale of the app (small, medium, large)?

small

What is the size of your team? Are you working on this by yourself? by myself Do you parts of the boilerplate do you find frustrating? Pretty much the entire thing, I've built a ground up electron app, and I've worked on a existing react app so i was hoping to bring the two together and learn more about react in the process.

Turns out the structure of this thing is just too confusing. Maybe if I was more experienced in react + redux it would make more sense but there seems to be a lot getting in my way.

Also the HMR readme pretty much says don't use it other than to experiment so I'm not sure why it's being used.

What parts of the stack (ex. react, redux, electron, webpack) do you have the most troublesome or frustrating?

Redux and webpack. I would like it to be more simple and straight forward and let the developer how and what they want implemented.

What kind of app are you making? Front-end app that calls a REST backend

What is the scale of the app (small, medium, large)? medium

What is the size of your team? Are you working on this by yourself? Team size of 3, but only 2 of us work on the front-end.

What parts of the stack (ex. react, redux, electron, webpack) do you have the most troublesome or frustrating? Webpack. I don't know much about webpack, and the inclusion of all of these different webpack.config files if pretty confusing. I currently cannot package my app, and I have no idea where to go to start troubleshooting in the webpack files. There's a lot to learn about Webpack already, without having all of these different config files to figure out. I've tried comparing all of my files to the repo on here, and still having trouble.

Hey @brian-sullivan, just to let you know that you can always open a new issue on this project about your issue, mentioning the steps you took, maybe some logs, etc. and someone will try to help you.

@brian-sullivan please do make an issue. There are several people here, myself included, who will be happy to help!

Thank you for the great project.

1. What kind of app are you making? (Optional)

I've built http://label.live with many, many of native modules: usb (on Mac and windows!), fonts, App Store integration, etc. It's for sale on both Mac App Store and Microsoft Store. 👏

2. What is the scale of the app (small, medium, large)?

Medium

3. What is the size of your team? Are you working on this by yourself?

Solo

4. Do you parts of the boilerplate do you find frustrating?

I started using back in August 2018 when the two package.json structure was in use. Now I'm struggling on how to migrate to the single package.json structure. It'd be helpful to have documentation on how main/renderer resolve native modules in both setups.

5. What parts of the stack (ex. react, redux, electron, webpack) do you have the most troublesome or frustrating?

I think counter is a good example, but you need at least one other piece of state for it to make sense to new users. That is, have another dimension such as text, or something else that shows how reducers/actions are segmented and can grow. I have found Immutable to be absolutely necessary for developing a large redux app.

1. Currently developing a Scrum Retrospective Board for my development team.

2. It's s small project, which will used every two weeks during the retrospective

3. It's only me, but it is used within my apartment

4. Well frustrating not at all, I guess my first problem was to get used to Redux. I worked with the other frameworks before but I have never touched Redux. So what maybe could help would be to have more than one action/reducer function. I mean, yes it's only a boilerplate and you need to have the knowledge but I think that it would help also other developers in the future. I also had some problems with the adaption of the toolbar. I needed to work with IpcRenderer Functions and maybe a small example how to trigger a redux action function from it would be awesome. But this is not mandatory I think.

5. For me, I have never touched the Webpack implementation and I would appreciate if there's a small documentation about it. Till yet, I never had troubleshootings with webpack (luckily :D) but I think if I will have some I don't how to fix them or at least where to start.

I hope this help you a little bit :)

1. What kind of app are you making? my budget
2. What is the scale of the app (small, medium, large)? Small-Medium
3. What is the size of your team? Are you working on this by yourself? By myself
4. Do you parts of the boilerplate do you find frustrating? Nothing after I learned the boilerplate; rather just issues with react, redux and packages - nothing specific to the boilerplate itself.
5. What parts of the stack (ex. react, redux, electron, webpack) do you have the most troublesome or frustrating? The boilerplate doesn't have secure practices baked in. Granted, when this boilerplate was built I don't think a lot of the vulnerabilities were discovered with electron, and we don't expect you to do all this work for free =). I've taken your work and am building a spiritual successor that I plan on using (as migrating is requiring a bunch of work as I'm finding out!)

@reZach That's awesome! I'd love if you could PR some of those changes back to the boilerplate. I'm sure they'd add a lot of value to a lot of people!

@amilajack great cool! I'll see if I can put in a PR in the coming days for ya.

What kind of app are you making? A mob programming timer, keeping track of whose turn it is to code.

What is the scale of the app (small, medium, large)? Small/medium 😄

What is the size of your team? Are you working on this by yourself? Only me at the moment, but open sourced it (on behalf of the national Swedish Educational Broadcasting Company).

Do you parts of the boilerplate do you find frustrating?

• No TypeScript support (although this looks promising 😍 )
• Too much stuff included in the initial setup - I had to tear away parts I didn't want/need. Maybe some sort of CLI tool for scaffolding would be nice, letting users to choose if they want Redux and such? Food for thought 🙂
• As @reZach stated, the security vulnerabilities

What parts of the stack (ex. react, redux, electron, webpack) do you have the most troublesome or frustrating? Luckily I hadn't had to deal with any of it 😄

Overall, great boilerplate and awesome work @amilajack! Would be nice with a guide on how to update to newer versions (like the one with all the TypeScript setup).

I had to tear away parts I didn't want/need

What parts did you tear away?

I guess if you don't want to use redux you'll have a lot to tear away. At Recollectr we've rewritten nearly everything by now, but nothing we needed to remove besides flow. And we only removed flow because it's the most resource hungry piece of software since Crysis.

Edit: Oh, we did remove react-router because it was so damn buggy back in 2017 - but we've added it back now so... We did abandon using connected-react-router though.

1. What kind of app are you making? (Optional)

Homura RSS Reader

2. What is the scale of the app (small, medium, large)?

Small

3. What is the size of your team? Are you working on this by yourself?

Myself

4. Do you parts of the boilerplate do you find frustrating?

When I upgrade to Typescript@4, the yarn tsc script broken, but the app builds success and works well.

5. What parts of the stack (ex. react, redux, electron, webpack) do you have the most troublesome or frustrating?

I love the current stack.

not able to see my changes when a change in the main.dev.ts file. using electron-react-boilerplate.

1. What kind of app are you making? arvis

2. What is the scale of the app (small, medium, large)? Medium

3. What is the size of your team? Are you working on this by yourself? Myself

4. Do you parts of the boilerplate do you find frustrating? No, but I think it'd be great to have an electron update (to 12 or 13)

5. What parts of the stack (ex. react, redux, electron, webpack) do you have the most troublesome or frustrating? There were some electron bugs that worked differently with expected. I could fix it by updating the version of electron. webpack took some effort too because I wasn't used to setting and tweaking webpack.

I appreciate very much creating this awesome boilerplate :)

1. What kind of app are you making? (Optional) internal system to make bash operation eaiser

2. What is the scale of the app (small, medium, large)? medium

3. What is the size of your team? Are you working on this by yourself? 3 people, but myself working on this project

4. Do you parts of the boilerplate do you find frustrating? easy to use, no need for me to configure more

5. What parts of the stack (ex. react, redux, electron, webpack) do you have the most troublesome or frustrating? not yet

Thanks for this boilerplate! 🙏

What kind of app are you making? (Optional)

I am refactoring https://autoedit.io to use this template, to see if bringing the "react client", and "electron blackened" together in this architecture has significant performance improvements.

Initially I had attempted to do a modular architecture, where with the same code base you could make a web app, desktop cross platform app for mac, windows, and pc, as well as an adobe CPE panel, but overtime it became apparent that the ecosystem doesn't quiet support this kind of setup.

What is the scale of the app (small, medium, large)?

I'd say medium, depending on how you'd define it.

What is the size of your team? Are you working on this by yourself?

Just myself, on an open source project.

Do you parts of the boilerplate do you find frustrating?

Having some trouble creating a build, and packaging the app with the github actions. And not sure where to turn to.

What parts of the stack (ex. react, redux, electron, webpack) do you have the most troublesome or frustrating?

I try to stay clear of redux.

As is, I don't think I wouldn't be able to modify or tweak the webpack configs. But I can use the current setup as a good foundation to architect the rest of the app.

I think I found a decent pattern to connect the render process with the main process, but is very verbose (I can share some code if it's of interest) and was also wondering if there are some better patterns. Eg let's say you have a series of functions on the "react client" that need to interact to the "electron backend" eg saving to a database, using ffmpeg for video and audio etc..

@amilajack when you find a minute it would be good to update the original post's text to update the stack text to reflect the changes in recent years (eg, no more Redux.)

I really like this boilerplate!

1. What kind of app are you making? (Optional)

I make several apps for hobby and works! (like serialPort Program)

2. What is the scale of the app (small, medium, large)?

I think 'small'

3. What is the size of your team? Are you working on this by yourself?

I am working alone and self-taught.

4. Do you parts of the boilerplate do you find frustrating?

I know it's hard, but it would be nice if it was better documented.

5. What parts of the stack (ex. react, electron, webpack) do you have the most troublesome or frustrating?

After all, I think the best is 'react'. Thanks to 'react', I was thinking about user-friendly documentation.

Having said that, I am one of those people who would like to see this project continue in the future. I really want to say thank you.

@BangHyeongSik thanks for the feedback! specifically, what parts would you like to be better documented?