Book Image

Cross-platform Desktop Application Development: Electron, Node, NW.js, and React

By : Dmitry Sheiko
Book Image

Cross-platform Desktop Application Development: Electron, Node, NW.js, and React

By: Dmitry Sheiko

Overview of this book

Building and maintaining cross-platform desktop applications with native languages isn’t a trivial task. Since it’s hard to simulate on a foreign platform, packaging and distribution can be quite platform-specific and testing cross-platform apps is pretty complicated.In such scenarios, web technologies such as HTML5 and JavaScript can be your lifesaver. HTML5 desktop applications can be distributed across different platforms (Window, MacOS, and Linux) without any modifications to the code. The book starts with a walk-through on building a simple file explorer from scratch powered by NW.JS. So you will practice the most exciting features of bleeding edge CSS and JavaScript. In addition you will learn to use the desktop environment integration API, source code protection, packaging, and auto-updating with NW.JS. As the second application you will build a chat-system example implemented with Electron and React. While developing the chat app, you will get Photonkit. Next, you will create a screen capturer with NW.JS, React, and Redux. Finally, you will examine an RSS-reader built with TypeScript, React, Redux, and Electron. Generic UI components will be reused from the React MDL library. By the end of the book, you will have built four desktop apps. You will have covered everything from planning, designing, and development to the enhancement, testing, and delivery of these apps.
Table of Contents (9 chapters)

Writing view modules

Well, we have the service, so we can implement the view modules consuming it. However, first we have to mark the bounding boxes for the view in the HTML:

./index.html

<span class="titlebar__path" data-bind="path"></span> 
..
<aside class="l-main__dir-list dir-list">
<nav>
<ul data-bind="dirList"></ul>
</nav>
</aside>
<main class="l-main__file-list file-list">
<nav>
<ul data-bind="fileList"></ul>
</nav>
</main>

The DirList module

What are our requirements for the DirList view? It renders the list of directories in the current path. When a user selects a directory from the list, it changes the current path. Subsequently, it updates the list to match the content of the new location:

./js/View/DirList.js

class DirListView { 

constructor( boundingEl, dirService ){
this.el = boundingEl;
this.dir = dirService;
// Subscribe on DirService updates
dirService.on( "update", () => this.update( dirService.getDirList() ) );
}

onOpenDir( e ){
e.preventDefault();
this.dir.setDir( e.target.dataset.file );
}

update( collection ) {
this.el.innerHTML = "";
collection.forEach(( fInfo ) => {
this.el.insertAdjacentHTML( "beforeend",
`<li class="dir-list__li" data-file="${fInfo.fileName}">
<i class="icon">folder</i> ${fInfo.fileName}</li>` );
});
this.bindUi();
}

bindUi(){
const liArr = Array.from( this.el.querySelectorAll( "li[data-file]" ) );
liArr.forEach(( el ) => {
el.addEventListener( "click", e => this.onOpenDir( e ), false );
});
}
}

exports.DirListView = DirListView;

In the class constructor, we subscribe for the DirService "update" event. So, the view gets updated every time the event fired. Method update performs view update. It populates the bounding box with list items built of data received from DirService . As it is done, it calls the bindUi method to subscribe the openDir handler for click events on newly created items. As you may know, Element.querySelectorAll returns not an array, but a non-live NodeList collection. It can be iterated in a for..of loop, but I prefer the forEach array method. That is why I convert the NodeList collection into an array.

The onOpenDir handler method extracts target directory name from the data-file attribute and passes it to DirList in order to change the current path.

Now, we have new modules, so we need to initialize them in app.js:

./js/app.js

const { DirService } = require( "./js/Service/Dir" ), 
{ DirListView } = require( "./js/View/DirList" ),
dirService = new DirService();

new DirListView( document.querySelector( "[data-bind=dirList]" ), dirService );

dirService.notify();

Here, we require new acting classes, create an instance of service, and pass it to the DirListView constructor together with a view bounding box element. At the end of the script, we call dirService.notify() to make all available views update for the current path.

Now, we can run the application and observe as the directory list updates as we navigate through the filesystem:

npm start 

Unit-testing a view module

Seemingly, we are expected to write unit test, not just for services, but for other modules as well. When testing a view we have to check whether it renders correctly in response to specified events:

./js/View/DirList.spec.js

const { DirListView } = require( "./DirList" ), 
{ DirService } = require( "../Service/Dir" );

describe( "View/DirList", function(){

beforeEach(() => {
this.sandbox = document.getElementById( "sandbox" );
this.sandbox.innerHTML = `<ul data-bind="dirList"></ul>`;
});

afterEach(() => {
this.sandbox.innerHTML = ``;
});

describe( "#update", function(){
it( "updates from a given collection", () => {
const dirService = new DirService(),
view = new DirListView( this.sandbox.querySelector( "[data-bind=dirList]" ), dirService );
view.update([
{ fileName: "foo" }, { fileName: "bar" }
]);
expect( this.sandbox.querySelectorAll( ".dir-list__li" ).length ).toBe( 2 );
});
});
});

If you might remember in the test runner HTML, we had a hidden div element with sandbox for id. Before every test, we populate that element with the HTML fragment the view expects. So, we can point the view to the bounding box with the sandbox.

After creating a view instance, we can call its methods, supplying them with an arbitrary input data (here, a collection to update from). At the end of a test, we assert whether the method produced the intended elements within the sandbox.

In the preceding test for simplicity's sake, I injected a fixture array straight to the update method of the view. In general, it would be better to stub getDirList of DirService using the Sinon library (http://sinonjs.org/). So, we could also test the view behavior by calling the notify method of DirService--the same as it happens in the application.

The FileList module

The module handling the file list works pretty similar to the one we have just examined previously:

./js/View/FileList.js

const filesize = require( "filesize" ); 

class FileListView {

constructor( boundingEl, dirService ){
this.dir = dirService;
this.el = boundingEl;
// Subscribe on DirService updates
dirService.on( "update", () => this.update(
dirService.getFileList() ) );
}

static formatTime( timeString ){
const date = new Date( Date.parse( timeString ) );
return date.toDateString();
}

update( collection ) {
this.el.innerHTML = `<li class="file-list__li file-list__head">
<span class="file-list__li__name">Name</span>
<span class="file-list__li__size">Size</span>
<span class="file-list__li__time">Modified</span>
</li>`;
collection.forEach(( fInfo ) => {
this.el.insertAdjacentHTML( "beforeend", `<li class="file-
list__li" data-file="${fInfo.fileName}">
<span class="file-list__li__name">${fInfo.fileName}</span>
<span class="file-list__li__size">${filesize(fInfo.stats.size)}</span>
<span class="file-list__li__time">${FileListView.formatTime(
fInfo.stats.mtime )}</span>
</li>` );
});
this.bindUi();
}

bindUi(){
Array.from( this.el.querySelectorAll( ".file-list__li" )
).forEach(( el ) => {
el.addEventListener( "click", ( e ) => {
e.preventDefault();
nw.Shell.openItem( this.dir.getFile( el.dataset.file ) );
}, false );
});
}

}

exports.FileListView = FileListView;

In the preceding code, in the constructor, we again subscribed the "update" event, and when it was captured, we run the update method on a collection received from the getFileList method of DirService. It renders the file table header first and then the rows with file information. The passed-in collection contains raw file sizes and modification times. So, we format these in a human-readable form. File size gets beautified with an external module--filesize (https://www.npmjs.com/package/filesize)--and the timestamp we shape up with the formatTime static method.

Certainly, we shall load and initialize the newly created module in the main script:

./js/app.js

const { FileListView } = require( "./js/View/FileList" ); 
new FileListView( document.querySelector( "[data-bind=fileList]" ), dirService );

The title bar path module

So we have a directory and file lists responding to the navigation event, but the current path in the title bar is still not affected. To fix it, we will make a small view class:

./js/View/TitleBarPathView.js

class TitleBarPathView { 

constructor( boundingEl, dirService ){
this.el = boundingEl;
dirService.on( "update", () => this.render( dirService.getDir() ) );
}

render( dir ) {
this.el.innerHTML = dir;
}
}

exports.TitleBarPathView = TitleBarPathView;

You can note that the class simply subscribes for an update event and modifies the current path accordingly to DirService.

To get it live, we will add the following lines to the main script:

./js/app.js

const { TitleBarPathView } = require( "./js/View/TitleBarPath" ); 
new TitleBarPathView( document.querySelector( "[data-bind=path]" ), dirService );