Learn Electron, Eslint and Mocha

Electron is a framework that makes it easy to create cross-platform desktop apps with JavaScript, HTML, and CSS. Electron and open-source tools give you everything you need to create a compelling desktop app--native user interface elements like menus and dialogs, installers, auto-updates, and more. 

This course will teach you the core concepts of Electron so that you can leverage it to create your own desktop application for macOS and Windows. 

We'll go over:
- Creating user interfaces in Electron (both HTML based and native)
- Understanding Electron's multi-process architecture 
- Shipping your app to users

Electron is a framework for creating native applications with web technologies like JavaScript, HTML, and CSS.

electron

Build a desktop application with Electron

React is one of the web’s most popular frameworks for building JavaScript applications. 

If you know what you’re doing, React can drastically simplify how you build, use, and maintain code.

Whether you’re a React newbie or you’re ready for advanced techniques, you can level-up with egghead. Explore our in-depth courses, lessons, and community resources to build more powerful applications and crack open your career.

react

Our first layer of defense when building accessible React applications is to add some auditing tools to our development workflow. This should include adding static analysis checking for common accessibility standards and best practices. We can get this with the latest eslint plugin: "eslint-plugin-jsx-a11y". If you are already linting your projects adding this plugin should fit very smoothly into your workflow.

## Resources
1. [List of all the rules supported by eslint-plugin-jsx-a11y](https://github.com/evcohen/eslint-plugin-jsx-a11y#supported-rules)
2. [Comparison of the difference in rules between recommended and strict mode](https://github.com/evcohen/eslint-plugin-jsx-a11y#difference-between-recommended-and-strict-mode)
3. [Background on how the Accessibility API implemented by browsers interfaces with Assistive Technologies](https://github.com/evcohen/eslint-plugin-jsx-a11y#some-background-on-wai-aria-the-ax-tree-and-browsers)

Set up ESLint to Audit Accessibility Issues in React

The pluggable linting utility for JavaScript and JSX.

eslint

We have a number of options to use when testing for accessibility issues concerning alternative text for images.  The react-axe library and axe browser extension will both report when an image is missing alternative text.  The tota11y browser extension will annotate any images that are missing alternative text.  Running eslint with the eslint-plugin-jsx-a11y plugin installed will report on any `<img>` elements missing an `alt` attribute.  Finally, we can use a screen reader to actually hear what is read when an image has focus.

Test for Image Alternative Text Accessibility Issues

Images must have text alternatives that describe the information or function 
represented by them so they can be read and understood by those using screen readers.

## Alternative text for images
* All `<img>` elements should have an `alt` attribute provided
    * When not provided many screen readers will fallback to reading the file name instead
* The `alt` value should not include words like _“image”_, _“picture”_ or _“icon”_
    * Screen readers are already announcing that the element is an image
* Images that are decorative only and provide no information or function to the page should be hidden from Assistive Technologies by providing an empty `alt` attribute (`alt=””`)

## References
* https://www.w3.org/WAI/tutorials/images/
* https://www.w3.org/WAI/tutorials/images/decision-tree/
* https://www.w3.org/WAI/tutorials/images/tips/
* https://www.w3.org/WAI/tutorials/images/informative/
* https://www.w3.org/WAI/tutorials/images/functional/
* https://www.w3.org/WAI/tutorials/images/textual/

Define Images with Appropriate Text Alternatives

Our accessibility auditing toolkit makes it very easy for us to test for any form controls that are missing labels or are not correctly associated with their labels.  Running Eslint with the eslint-plugin-jsx-a11y installed will show us any form controls with missing or unassociated labels.  Running react-axe or using axe to audit a web page will similarly list any of these findings.  Finally using tota11y we can annotate any form controls on a page that are missing labels.  This is definitely some of the lower hanging fruit that we can easily find and fix when making our applications accessible!

Test for Form Control Label Accessibility Issues

Labeling inputs, elements, and widgets add context and clarity for assistive technology such as screen readers.  Elements of a `<form>` such as `<input>` or `<textarea>` or `<select>` should be labelled by using a `<label>` element.  Placeholder text can be used in addition to a label but should not be used in place of a label as not all assistive technologies respect placeholder text.

Ensure Form Controls have Accessible Labels

JavaScript® (often shortened to JS) is a lightweight, interpreted, object-oriented language with first-class functions, most known as the scripting language for Web pages, but used in many non-browser environments as well such as node.js or Apache CouchDB. It is a prototype-based, multi-paradigm scripting language that is dynamic, and supports object-oriented, imperative, and functional programming styles.

javascript

In this lesson you will learn how to use the eslint yeoman generator to scaffold a new plugin to provide custom rules for your project. 
You will also be able to check the basic skeleton for an eslint ruleand a working example rule to apply a naming convention for async functions.

Scaffold an eslint Plugin with Yeoman

Nx already comes with a default TypeScript setup. Although you can opt-out of that and generate plain JS based components, especially in a large setup TypeScript can be beneficial in uncovering potential issues early. To add an extra level, Nx also comes with preconfigured eslint for all the apps and libraries. In this lesson we're going to explore the lint setup and how it can be used.

Linting a React app with Nx

In this lesson we’ll load javascript into the BrowserWindow and display the Electron version on the page. Loading javascript into Electron is almost exactly the same as loading it into the browser, however it is a best practice to use the `require` syntax.

Load JavaScript in an Electron BrowserWindow

A main menu is a hallmark of native desktop applications. Electron makes it easy to create native menus and menu items in JavaScript.

We’ll go over creating a menu template using `Menu.buildFromTemplate` and then setting it as the main application menu via `Menu.setApplicationMenu`. 

Create a native desktop system menu with the Electron Menu module

In this lesson we'll learn about `dialog.showMessageBox` . This is the most basic Electron dialog but it offers lots of customization options, such as `type`, `icon`, `title`, and `buttons`. Some of these options vary by platform, so we'll also look at how things differ between Windows and Mac. 

Display native desktop dialog windows with Electron

In this video, we'll learn how to save and open a file using native dialogs in Electron. First, we'll use `dialog.showSaveDialog` to display a native save dialog and use `dialog.showErrorBox` to display an error message if the save failed. Then, we'll open the file we saved using `dialog.showOpenDialog`. Finally, we'll look at how these dialogs look on Windows vs Mac.

Save/Open a file with an Electron dialog window

Dealing with multiple processes in an application is new for many JavaScript developers. We’ll go over what exactly a process is and what the primary responsibilities of the main and renderer processes are. The main process is primarily responsible for creating native UI elements and managing the application lifecycle, while the renderer process runs the HTML based UI. Accordingly, different APIs are available in each process. 

Understand Electron’s main and renderer process architecture

In Electron, we often need to coordinate actions between multiple processes. For example, if a user clicks a button in a renderer process that makes a new `browserWindow` open, we need to be able to send a message to the main process that triggers this action. We’ll look at how to do just that using the `ipcRenderer` and `ipcMain` modules.

Communicate between Electron processes using IPC

`remote` allows you to seamlessly interact with main process modules as if they were in the renderer process. It’s a super useful abstraction over IPC. We’ll learn how to use it and how to avoid some potential gotchas it has. 

[Devtron](https://electron.atom.io/devtron/) is a devtools extension that the Electron team has made. We’ll be using it to view all of the IPC that happens in our application. In this lesson we’ll learn how to include and use it in our code. 

Communicate between Electron processes using the remote module

Every Electron application needs a custom icon. Mac needs an `icns` file and Windows needs an `ico` file. We'll learn how to use a npm module, `electron-icon-maker`, that takes a 1024x1024 PNG and then outputs all the files we need. 

Create an icon for your Electron app

We’ve been running our app in a development environment using the Electron executable. Now let’s learn how to package our app into a `.app` or `.exe` file so that we can distribute it to other users. Electron doesn't provide this functionality out of the box, so we'll use a popular and easy-to-use npm package called [electron-builder](https://github.com/electron-userland/electron-builder) to handle the details. electron-builder will automatically grab our `.ico` or `.icns` file and use that as our app's icon. 

Package your Electron application into a executable file with electron-builder

Code signing ensures that your app was created and distributed by you or your company and has not been modified since it was built. It is done via a special code signing certificate issued by a trusted authority. While you can distribute your Electron app without signing it; code signing is a security best practice and is a prerequisite to implementing auto-updates in your app. We’ll walkthrough how to integrate code signing into your electron-builder build process, what happens when you don't sign your application, and how to verify it's been signed correctly. 

This lesson assumes that you have already purchased code signing certificates from Apple and one of Microsoft's trusted vendors and have exported the certificate as a `p12` or `pfx` file. 

Code sign your Electron application with electron-builder

Once users are using your app, you need a way to ship new features and fixes to them. In this lesson, we’ll learn how to implement auto-updates in your app, which allows you to distribute updates to your application seamlessly. We'll go over how to integrate with Electron's `autoUpdater` module to check for an update and display a prompt to update once it's been downloaded. For our server side implementation we'll just use a plain file server to keep things simple. 


Ship updates to your Electron app with `autoUpdater` (Mac)

In this lesson, we'll go over a few differences in implementing auto-updates on Windows like handling `Squirrel.Windows` startup events and configuring `electron-builder` to build for a `Squirrel.Windows` target.

Ship updates to your Electron app with `autoUpdater` (Windows)

Take the first step in learning how to create native desktop applications with Electron. We'll set up a package.json, create an npm start script to launch our app in development, and create a browser window and load a local HTML file into it.

An important concept to understand about Electron is it's multi-process architecture. The main process creates web pages by creating `BrowserWindow` instances, manages application lifecycle events, and more. Each `BrowserWindow` instance runs the web page in its own renderer process. 

Topics

Instructors

Content Type