We have just a published a basic Chrome Extension to subscribe to articles and get notified when new comments are published.
Motivation
We all are readers and consumers of digital information on the internet.
Many people read Hacker News in a daily basis.
HN is a reference in many aspects, we wouldn’t say leader over the rest, but at least an important asset when it comes to read news regarding tech & science world.
But, when reading articles, what people comment might be crucial to disrupt a thought and start thinking on new ideas, continue browsing or researching more info.
So, why not building a simple extension that allows users to subscribe articles so they can get notifications when new comments are published?
Get to work
We didn’t know how to build a Chrome Extension at first.
We did find this great article of Lessons Learned developing a Chrome Extension.
But we wouldn’t care, because we are used to face new challenges every day, so it’s just a matter of investing a few hours reading resources and building.
The Google Platform Developer’s Guide is marvelous, but it does not cover well all problems we faced.
The best plugin development workflow
The development workflow we followed requires the dev person to go updating the extension (in development mode) every time you wanted to load a newer version of the source code.
How to auto-reload extensions when developing them? That’s a question we didn’t invest time on researching. But there surely such be a solution for that (maybe this one).
Messaging system cross Content and Background scripts
It wasn’t so clear to us how the post messaging system needed to work across content and background scripts.
There is a lot of doubts on gists, stackoverflow and other platforms, and we do think it’s a problem of the documentation.
We needed the simple one-time requests, but we didn’t know it would silently fail if you made a mistaken using the spec.
Also notice that when communicating a background script with a content script, you have this line here that specifies what to use on this scenario.
We do think it’s needed a repo with clear examples of each case, just for the sake of the newbie. And when you do read the samples you quickly see how outdated some are.
Chrome Web Store listings aren’t free
As per in the Preach article, each developer must pay $5 USD to start publishing extensions to the Web Store.
Note that if you want to publish at your company gapps name only to try out before officially releasing to the Web Store, you can do it for free.
However, it’s worth to mention we couldn’t set up the rights and accesses to be two developers publishing new versions of the extension. So the one who initially uploaded the extension is the only one who had access to see and update it.
How we did see this? We did setup a job to automatically publish newer versions to the store, but we couldn’t figure out how to grant access to an extra developer.
Update: It’s just a matter of time. It takes a few hours until the right accesses get properly setup.
Time effort
17 hours in total (2 people), including:
- Learning how to proceed developing Chrome Extensions.
- Studying how to perform scrapping and consume the HN API to provide the functionality we wanted.
- Developing the extension.
- Publishing the extension.
- Writing down this article.
Suggestions or change requests
We didn’t want to expose the source code publicly, but we did enable a public Github repo so that the users could raise questions, issues or suggest improvements.
If we see the usage of this plugin it’s somehow extended, we are open to consider releasing the source code to create even more complex tools on top of it.
