Extensions – Practice

In the previous post you could read about the main parts of an extension. Short and just the definitions. Let’s see them in practice.

TypeScript

I used TypeScript for the development. We decided to choose this instead of the plain JavaScript because a lot of developer worked on the original project. There were a plenty of misspelling errors – figured out only in run-time and we had problems to keep everything in hand. We needed regulations a more structured and controlled environment for developing in JavaScript. That’s why we choose TypeScript to work with. I only get used to developing with it that’s why this project is in TypeScript as well.

Developing this way requires only a few extra thing to do.

  • You need to use typings (type definitions for JavaScript). The definition files of regular JavaScript libraries. But you don’t need to panic, because it is collector portal and you can find here a lot of typings for different libraries. – really a lot, I found typing for so small libraries I couldn’t believe it first. (:
  • You need to compile typescript files. But doing this is supported by gulp. You can easily add automation to do it with a single gulp library, called gulp-typescript.

Structure

Here is the structure for my source.

path

Well separated parts: Background, Content, UI, Manifest like the architectural parts of an extension + Common and Assets. Files in this structure will be explained in the following sections.

Other infrastructural elements of my solution.

path2

  • Gulpfile for automation
  • package.json for libraries installed with npm
  • tsd.json for type defintions installed with tsd
  • gitignore for github
  • and dist for gulp-generated, package-ready files.

Messaging

We have these parts: Background page, extension’s UI and content script.
What we have in common, they all communicate with each other.
Messaging connects all of them.

So for a good extension skeleton we need a good messaging system.

In my solution I built a base class for all my components that contains the mechanism of messaging. My implementation based on broadcasting.

From content scripts we send a message which one all the background scripts based on my baseClass will get but only the subscribed ones will handle it. One event could be important for more parts of the background components. Same from the extension’s UI.

Background scripts will broadcast their messages to the content scripts and UI scripts as well. UI scripts can’t communicate direct with the content scripts but through the background script they can. Sending the message from UI to the background script and forwarding from the background script to the content script that’s how it could work. 

Every base class have the same functionality.

msg1

In the constructor you pass the event handler of your actual component for the browsers event handler. Browser part will be explained in the next section – these are the common, browser independent parts.

You have this base class with two arrays for all your component’s classes. Listeners and pending responses. Storing them and checking them at every action will provide that you didn’t lost any message or reply in the extension’s messaging traffic.

As an example. I created the test file. It defines its event subscriptions in the constructor. Other classes extending the base class will have own arrays for all of that. Every component will know for which events they interested or for which ones not.

msg2

The actual ‘on’ subscribing method adds only this subscription to the array. Going through the array and checking which events to handle will happen if the browsers listener will get a message.

msg3

Sending a message will be the preparation of a well defined event package and the triggering of the event. Triggering is different in the different browsers that’s why it is only a method here, a method of the browser.

Browser & Component differences of messaging

As I mentioned all the base classes are only duplicates. In the code yes, but in every component we will use a different browser implementations. So we will have browser file for Background scripts, Content Scripts and UI scripts as well. First I will show you these differences. So the different browser implementations of the different components. After that I will show the actual browser differences, that are because of the two different browser, Chrome and Firefox.

Isn’t clear yet? – No problem. I will show everything in practice. I hope it will make things clear.

Background script:browser1

chrome.runtime.onMessage.addListener is the method of the chrome API to handle event subscriptions. If we get a message we will iterate through all of our subscribed class’s callback – remember base class passed in its constructor to the browser implementation – and call them with the actual event data.

Filling this array, the eventListeners array happens through the eventReceived method.

browser2

Sending a message from background scripts has two steps. Sending the actual message to the scripts in the UI and sending them to the content scripts. Both have different ways.

browser3

UI can communicate directly through the run-time with the background script so we can use it to deliver messages from one to other. But as I mentioned it in my previous post, Content scripts are not part of the extensions technically. They will get the messages through the actual page, into they are actually injected. We can get all the pages opened in the browser in our background script with the chrome.tabs.query and we can send the message to all of them. Only the page containing our injected logic with the event handlers will do something with the message the others will ignore it.

Content script & UI scripts (Popup):

Background need to use other method to send message to Content Scripts and UI scripts but they can get messages through the run-time and can use it to sending the messages as well in the same way.

cs1

cs2

The type in the sendMessage is for the browser. Extension communication go through  the type, message. In the payload we can define our type as well. Identifying our messages with our types/names.

UI scripts implementation is for popup types, not for panel types. It is differentiated in chrome. More about it you can find in my skeleton implementation.

 

Messaging in Firefox looks different. In background scripts you have to create a panel as the main component of your extension. It has a port, we can use for sending and getting messages.

In content scripts and UI scripts we have a ‘self‘ or ‘addon‘ object with the port or we can use the window object for sending and listening events. More about it you can find in my skeleton implementation.

Other browser differences

We need to hide more differences not just messaging. So little things like timeouts are different in the browser.

In Chrome:

br2

In Chrome background scripts you can use a fully featured window object, but in Firefox you don’t have the timeout functions on that. You have a timers SDK to use for that.

In Firefox:

br3

In Chrome you can use the chrome.* objects and methods.

In Firefox you need to use the underlying module handler – the built in CommonJs for getting the SDK’s libraries.

br1

More feature that needs different implementations according to the actual browser will come. In the skeleton I needed only these ones. I think in later posts there will be more about this differences. Don’t miss them.

Extension bootstrapping

Bootstrapping the extensions are very different in the two browsers.

Chrome uses the manifest.json for all the things.

manifest

It will bind the Ctrl + B key-combo to start our UI. The UI will be the default_popup’s html. We define the background scripts and the content scripts as well. Chrome will know what to do with them.

Firefox have a few details in the package.json file.

manifest3

It defines only the path of the background script and Firefox will use the background script and the browser’s SDK to create the parts of the extension.

manifest2

You define here the panel and it properties. The icon (= button) in the browser’s toolbar. It handles the show and hide of the extension’s UI. Injecting the content scripts happens also here with the pageMod SDK library.

In case of content scripts the * defines that we want our script injected into every opened tab, we define the path of the script and we want to load and run the script on document ready event.

In Chrome (previous picture) matches: <all_urls> is the same with the * in Firefox. Js defines the path. Run_at is the same as contentScriptWhen. In Chrome we have an extra option to include our script not just into the page but into all of the iframes the page contains. Firefox uses other option to do that.

aaaaa

All the sources mentioned in this article you can find in my repository in github. You can check it: https://github.com/FerencKun/extensionbase

If we are ready with the development we need a good automatized infrastructure to build the files and prepare them for packaging and publishing.

Automations with gulp

Developing an extension for both browsers. Chrome and Firefox. Without gulp could be very hard. Gulp task can help us make the right package for both browser with a little configuration and with parameterized tasks. Here I don’t have space to define what gulp is. Please let me speak about it so as if you would know the basics of this technology and if you didn’t, here are some good links to learn more about gulp.

One big difference is that in Chrome we can add more background scripts but in Firefox we can only define one file. So we need to concat all the background scripts into one.

gulp

Using TypeScript makes our work easier, but for packaging we need of course the compiled JavaScript. Gulp helps.

gulp1

We can add our different browser files with the gulp task in our copy task but we need different path settings in html files. (If we don’t want to rename our destination files.) There is an option to do it with gulp as well.

We can define string patterns (with custom prefixes) to replace with value in that place too. In html I will define //@@browserFilePath and gulp will replace it with chrome.js or with firefox.js according to the parameter.

Now we have the already ready files to package them for the browsers. About packaging and and publishing I will write about later. I hope this much content will be enough for this post. But more info in this theme will be coming soon.

To be continued…

Advertisements

2 thoughts on “Extensions – Practice

  1. Pingback: Extensions – Theory | My Journey InTo JavaScript
  2. Pingback: Browse Wisely – The Extension | My Journey InTo JavaScript

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s