Let’s set the scene. You are in charge of developing a Chrome extension for your company. You have a colleague (let’s call her a QA expert) who is responsible for testing the extension before it goes live.

In the beginning you would always build the extension on your machine, zip it and send it to her when you finished some unit of work. In time this gets annoying for both you and her. Time to automate.

Does this sound familiar in any way? Read on. :)

The standard approach

There’s this excellent blog post about how to do continuous integration of Chrome extensions written by the guys at CircleCI.

So why bother with another blog post? I had a constraint which prevented me from using that solution. Thing is, if you use the said solution you end up giving the CI process full rights to publish any Chrome extension in the name of the Google account that you use.

I see two problems if I use my own account:

• I have the right to publish to both staging and production. I do not want a staging CI process to have the rights to publish to production.
• What if my account is deleted for some reason? The dependency of CI on my account’s existence and access rights is absolutely hidden here.

Okay, there’s an easy fix — create a new Google account that will be dedicated only to this purpose and will only have the rights which it needs. But each account costs something. Is there perhaps another way?

The alternative

You don’t need the Chrome Web Store to distribute extensions. You just pack the extension, send it to the other person (our QA expert) and they drag’n’drop it into Chrome.

The problematic part is, naturally, updating. Luckily for us, there’s a property update_url in the extension’s manifest.json which we can use. In the URL you specify where Chrome expects an XML file with some info about the newest version of the extension. The file looks like this (let’s call it update2.xml):

There are three things in this file:

• appid — ID of your extension. You can see it when you install it in Chrome. It will stay static.
• codebase — The location of the newest CRX file.
• version — The version of the extension in that location.

The CI configuration

Here are the things your CI needs to do:

1. Generate a new version number so that Chrome knows it needs to update. For the staging environment, I use the 4th version number and bump it by one on each deployment. E.g. 1.0.0.0 , 1.0.0.1 , 1.0.0.2 and so on. I always have a script download the current update2.xml , check the current version and bump it.
2. Set the correct version in the manifest.xml and pack your code into a CRX file. You can use this amazing crx utility and the command crx pack . For this, you’ll need to generate an RSA private key first. You can use this snippet: openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem . Put the key in some secured environment variable of your CI service.
3. Upload a new update2.xml (where you updated the version number) and the generated CRX file onto the locations you specified (in manifest.xml and update2.xml respectively).

And that’s all there is to it.

When all these steps are complete, Chrome should automatically update the extension. If you don’t want to wait for Chrome to realize there’s a new version out, you can open the details of the extension in the browser and click the “Update” button.

Was this article helpful? Or did you find it a bit too brief and would like me to go into more detail? Let me know in the comments.

Chrome Extensions and Continuous Integration was originally published in Slido developers blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

A very common requirement when writing single page applications is making an asynchronous HTTP request to some kind of an API. You might want to fetch some data from the server. Or you might want to perform some action on the server (think RPC).

Either way, it is an asynchronous action. And if you are just starting with Redux and/or front-end development, you google how other developers across the internet do these async things. And you come across redux-observable, redux-saga, redux-thunk, or some other “side-effects” library for Redux.

Redux-observable uses reactive programming, redux-saga uses generators. Both are extremely fascinating and useful concepts. But do you need to learn either of these to do that API request?

In a word, no.

To make my point, let us briefly get to the very essence of what we use Redux for.

I love Redux, because it allows me to abstract from the visual UI and lets me represent the state of my application in a simple (JavaScript) object. The UI is then for the most part just a visual projection of this object. It is as simple as that.

So, need to perform an asynchronous request? Ask yourself this question first: Does the request even affect the global state of the application at all?

1. No it doesn’t. This is a perfectly valid use case. Forget about Redux and just call that axios (or the HTTP client of your choosing).
2. Yes it does. Then why not just update the state yourself? One dispatch before the request and one dispatch after the request.

Anyone with even basic knowledge of Javascript and Redux will understand how the code above works. Don’t put a middleman in there until you see that it will bring you more than it costs you.

Another beauty of this “JavaScript 101” approach is that you get a Promise back (or an Observable if you wish)! Ever wanted to show a spinning wheel after clicking a button without a neck-breaking loop through dispatcher, reducer, selector, connect and props? Well now you can! :)

By the way, if you are a more seasoned Redux user, you might notice that this is not very different from redux-thunk at all. The main difference is dependency injection. Redux-thunk injects dispatch and getState for you — but since you have to pass the action to a dispatch first anyway, it saves you almost no keystrokes. On the other hand, it makes things a little less transparent and even changes the signature of the dispatch method to return a Promise (try explaining this to TypeScript).

Wrap up

My personal struggle with these side effects libraries was that they were adding a lot of complexity to something that, by itself, does not need to be complex at all.

I didn’t realize that what makes Redux really valuable for me, are not conventions or “using modern web technologies”. It is the fact that I can reason about the application without the burden of UI. And that I can easily write tests which do not have to rely on some crazy framework mocks.

So at the end of the day, my end goal is that I want to be able to update the state whenever I need to, to whatever state I need to. If a 3rd party library can help me with this, great! If not, why bother with it?

Whether this model works for you is entirely up to you to decide. But it has for me so far.

Why you need no Redux Saga was originally published in Slido developers blog on Medium, where people are continuing the conversation by highlighting and responding to this story.