Replace Everything With Pikachu Chrome Extension
By: Jackson Prince
Tags: Programming, Developer, Chrome Extension, Code, JavaScript

How To Code Extensions?

Extensions command an unnecessary aura of intimidating complexity. As if their code is somehow “different”. In truth, if you’ve made a webpage using JavaScript, HTML, and CSS, then you’ve won 90% of the battle.

There are only three foreign concepts to take special note of. Embed these in your brain and you’re good:

1. You’re working with three isolated webpages

I can’t emphasize this fact enough. My first eureka! moment building a Chrome extension was when I realized I was literally working with three separate webpages that know nothing about one another unless we instruct them to communicate.

Here are those pages for you now, the first of which you’re intimately familiar with already:

Our webpage:

Above is a regular old webpage. It could just as easily have been Amazon or Medium or Reddit.

Our popup:

That AdBlock popup you see is a whole webpage unto itself. It’s not part of the Google homepage. It knows nothing about B.B. King. Nor is it part of any other webpage. It is its own entity, containing HTML, CSS, and JavaScript, functioning in total independence.

In the same way that your browser loads the appropriate HTML, CSS, and JavaScript when you arrive at a new URL, the same occurs when you click the AdBlock icon and see a small page appear. Your browser loads HTML, CSS and JavaScript into that popup screen.

The difference is, instead of going and finding those files over a network request, your browser just carries those files with it at all times. When you load a new Chrome extension into your browser, that code is always and immediately available.

Note: AdBlock is, of course, aware of the current webpage, otherwise it wouldn’t be able to do its job. But it’s only aware of the webpage and B.B. King because there are JavaScript files instructing the two pages to communicate.

They’re not inherently linked. We’ll gain a deep understanding of this in time. For now, think about their interaction with one another as shouting over a fence, rather than sharing a home.

And our final page, the workhorse and my favorite of the three:

Our background page/script:

For which there is no picture, because it runs invisibly in the background.

We use this page to monitor events related to the browser itself like, for example, listening for when our extension’s icon is pressed or retrieving and storing information until the popup calls for it.

(Hint: We will use the background script to retrieve Pokemon.)

If you can wrap your head around the fact that there are three independent web pages at work in an extension, you’re nearly golden. You’re not required to use all three. If you only need one of these pages to get the job done, then hell yes. Use the one.

Over the course of this series, we will learn and work with all three. Which means we will be working in three separate developer consoles!

There is no better way to demonstrate the idea that these are three independent webpages than to bring up all three, independently run consoles. Here’s an in-action still-frame:

You’re looking at three different consoles, each one completely unaware of the other two. Left deals with background, right with popup, bottom with web page.

If this strikes you as odd and chaotic, be comforted by the fact that it does for me, too. But, good news is: you just made it through the hardest part.

The rest is gravy.

2. You direct conversation between your extension’s webpages

Again, the three pages of your extension (web, popup, background) are independently owned and operated. To get them communicating, you’ll use the Chrome API.

Let’s just ignore the fact that API is the worst acronym in all of programming (what can “Application Programming Interface” not mean?).

Think of the phrase Chrome API as: “functions Chrome provides to people who make extensions”. Or Chrome-Speak, which is how I’ll refer to it for the remainder of this article.

Here’s an example of some Chrome-Speak:

chrome.tabs.sendMessage()

Translation:

Within chrome ’s list of functions for extensions to use, let’s grab the one called tabs , pertaining to the current window’s tabs. Now, from the tabs root function, let’s use the one that “sends” a “message”.

What this function illustrates is that we have to go out of our way to send and receive information between our three pages. We will use this exact function later on to send a message from our background to our webpage.

The best tool you have to learn Chrome-Speak is Chrome’s documentation, which is good not great. But it gets the job done.

3. You need a manifest

The last and final oddity of extension building is you need something called a manifest. Manifest is another one of those words which is twice as long and obscure as it needs to be. And extension manifest is a list.

The list says two things:

Here are the key files in my extension.

Here are some default behaviors (i.e. “I want a popup page” or “I don’t want a popup page”).

That’s it.

Your browser requires that you include a manifest in your extension so it can better organize its thoughts and position itself to receive and implement your code.

Remember, your browser did not plan for whatever code you write in your extension. Therefore, the only way for your browser to play nice with your code is for you to tell your browser what’s in your code, and how you expect your browser to handle it.

In this example manifest, we’re telling our browser the absolute minimum: name and version numbers.

{

"name": "Everything Pikachu",

"version": "1.0",

"manifest_version": 2

}

Note: it must be written as “manifest_version”: 2 . No idea why. Just go with it.

As far as the browser knows, based on this manifest, our entire extension is just a name and a few version numbers. No JavaScript. No HTML. No CSS.

Regardless of how many wonderful scripts may actually be present in your extension’s folder, none of them will appear or function without first telling your browser of their existence.

Let’s do that now:

{

"name": "Everything Pikachu",

"version": "1.0",

"manifest_version": 2,

"browser_action": {

"default_popup": "popup.html"

}

}

Nice. Your browser now knows a few important bits of information it was previously without.

It knows about your extension, called “Everything Pikachu” , that it’s the first version of this extension; and when you click the extension’s icon (which your browser considers a “browser_action” , because it’s an action occurring directly in the browser), then the page in your extension’s file named “popup.html” will appear.

Fairly self-explanatory. So long as we let our browser know what’s going on, it will comply.

In terms of important overarching concepts to review, that’s it. We’re now in a good position to start building.