Hi all, I’ve updated the aurelia-store-examples with an Electron app.
Now it seems that showing native Notifications is causing issues on Win10 creators fall update. So I had to fall back to using the tray icon balloons.
I wonder if there are issue with other versions or OS / Linux, so I’d like to ask for trying out the sample found over here. As noted in the readme, just navigate to the electron subfolder, hit npm install and afterwards au run --watch which should launch the devserver and the electron app.
If you’re on windows try removing the os check and using the notifications as well.
Thanks in advance
Hello @zewa666 (kako ide?)
As you may have noted, I am trying to resurrect the confidence in Aurelia staying power, by acting as a Community Organizer (see Get Aurelia Great (GAG - call for action)), so I am very interested in knowing about any ongoing projects that could fit in the list of tasks that this Aurelia Community driven project should / could be aware of.
Let me use this opportunity to also ask you whether you might accept the invitation to this group’s Editorial Board, entity that should ensure the needed synchronization between the Community group and Core developers tasks.
A poc a poc how the catalans would say 
I’ve noticed said information, much like other core devs did, and frankly we are waiting to see what happens. I personally wouldnt want to jump into the discussion but wait and see what the Independent community mind comes up with. As soon as we are in tons of other ideas could fall just because of too premature directions. So lets see what happens. And also lets keep those discussions limited to your linked topics otherwise Info gets spread too much around.
Back to this topic, Id just like to come up with several examples so that people who try out Aurelia Store get a better understanding of its capabilities and intended use cases. As such having solid example apps is imperative.
@zewa666 Electron notifications work perfectly from the renderer process. We’re using the HTML5 notification API from the renderer and have it working perfectly on all platforms.
For most single page applications there is very little need to send any state back to the main process as all its really used for is opening windows and few other things. If you’ve got multiple windows there is a case for it but there are some better alternatives to IPC via the main process which can cause choppiness in the renderers.
Better alternatives for sending data/state between renderers is any technology which is currently used to send data between browser tabs. LocalForage and localForage-observable work well at doing this.
Well true this example is a bit contrived since you could use html5 notifications. But depending on the App there might be good reasons for more communication. Im working on an e2e Testing Code Editor where file changes have to be synced and code generation happens in the main process due to a custom CLI.
I just wanted to build a simple App demonstrating the usage of middlewares to trigger sideeffects across the Apps boundaries. Im happy If you could come up with a better example for electron.
I would still question if the code generation should be called from the main process. The custom CLI could just be called from a renderer couldn’t it?
We’ve got a large Electron + Aurelia app which calls into native libraries, does compression, file handling, you name it, all from renderer process(es). The main process is only about 150 lines of code which handles lifecycle stuff and some of the few Electron APIs which only work from the main process. This is the recommended way to create Electron apps because anything blocking the main process event loop can actually block renderers, or communication with their GPU processes.
For executing long running tasks, the recommendation is to either use a WebWorker (where possible and they’re pretty limiting), or actually load up another renderer process (ie. a non-visible BrowserWindow) and do the long running calls from there where they won’t interfere with any other execution of the app. Sounds convoluted and complicated but goes a long way to explain the vscode process tree!
I can often be found in the Electron Slack channel asking people why they’re doing stuff in the main process…
Hehe. All fair arguments. Maybe I didnt expressed the cli clearly. The app comes either with a UI or can be started as a CLI for integration into CI envs. Besides there is a custom language server running for Java which does its job in the main in a separate spawn. So again there are always exceptions for the rule true though that they should be async as possible with minimal CPU cycles. Its just a nice way though to handle all the state via a single Store.
But knowing that there is an expert with Electron in here is great for knowing whom to ask some nasty things via PM 
Hi @timfish, since you have a noticeable experience on electron I’d like to ask you a tip. In the coming days I’ll try to test if it’s feasible to read and write messages over a can bus. I’ll connect the client to the bus using an USB dongle. Do you think it’s feasible and reliable to do that in electron with typescript?
I’d like to reuse web skills on this project (with Aurelia of course), otherwise I have to go for a classic Wpf windows app.
@enrico-padovani Yes, I’d definitely recommend it over Wpf. We communicate with proprietary USB hardware and although there can be quite a lot to consider, its no more than for the Wpf alternative. You’ll also end up with a cross platform app for free. Post on the Electron Slack channel or PM me if you get stuck.
@zewa666 There are always exceptions to any rule 
. Would you use aurelia-store to store all the applications settings? If so, there might be a case for doing the persistence in the main process. If you’re storing the window positions/state, the main process would need to access to these before any localstorage becomes accessible in the renderers. I’m guessing this might be why redux-electron went with their rather complex setup?
Exactly, allthough personally I would always try to keep the Store in the renderer. One exception might be multiple renderers or hidden ones, but even than as you suggested there are alternativ workflows.
A complete and safe coordination between the “chaos” I am instigating in the community and the benefits for aurelia as a movement is my highest priority and at the moment, I am sharing everything with @EisenbergEffect (note that I am describing a uni-directional flow of data here 
). As explained in my introduction of GAG, having the direct experience with similar processes at a few larger compaanies (Auth0, DigitalOcean, Mailgun and IBM), I am driven by the firm belief that enthusiastic participation of the large section of the community is the key to a healthy growth of any open source project. To say it differently, I am acting in the role of the Community Organizer - which is likely my strongest assed (boy, I am sounding as Trump, for God’s sake). This work is not easy even for someone with the natural “talent”, so while I would much prefer to continue acting as a Geek and hack someting in the privacy of my home (automating the heck of my home with microservices, task with includes mucking with hardware), I am very dedicated to see this through as the initial comments I am getting are encouraging.
Important note: I am trying to propose tasks that are in the first concentric ring outside the domain of the core team activities, with the intent to minimize unnecessary disturbances and scheduling conflicts with the core team.
Hello @timfish @enrico-padovani @zewa666
I am responding to Tim’s post starting with
I would still question if the code generation should be called from the main process. The custom CLI could just be called from a renderer couldn’t it?
(unrelated to my community organizer tasks) to indicate strong alignment with Tim’s views. As you all might recall, I built significant electron experience, and am working on a new scaled down version, which is best described as Visual CLI. Original Monterey was designed to be a lot more than app generator, and it was a bit ahead of its time. The project Aurelia CLI Guides I am proposing as one the activities for our community, consists ot my experiments, run as help to @JeroenVinke, for his future extensions on Aurelia CLI, as well as the base for Visual CLI.
After establishing some minimal credentials in the Electron based apps, I wanted to support Tim’s explanation not do do much in the main process by pointing to the similar constraint that we all apply to Aurelia application’s main:
import 'bootstrap';
import {Aurelia} from 'aurelia-framework';
export function configure(aurelia: Aurelia) {
aurelia.use
.standardConfiguration()
.developmentLogging();
// Uncomment the line below to enable animation.
// aurelia.use.plugin('aurelia-animator-css');
// Anyone wanting to use HTMLImports to load views, will need to install the following plugin.
// aurelia.use.plugin('aurelia-html-import-template-loader')
aurelia.start().then(() => aurelia.setRoot());
}
ok actually it was just my fault using the wrong API. Didn’t think that the html5 notification and native notification api do different things 