React JS : Tables in the browser

A good exersize while learning React JS was building a re-usable component that produces HTML tables given an arbitrary JSON array of objects in the form:

[{'col1_name':'col1_value','col2_name':'col2_value'} ,

So a practical example of the above would be:


With the resulting table being:


Here’s the reusable code (feel free to improve/include in your projects):

A couple of lessons from the above:

  • Concatenating React JSX objects: JSX objects are usually used in the “render” function, in the case of the table it was necessary to concatenate JSX object in lines 31-36.  This is relatively easy by storing the object in an array with the javascript push array function. It’s noteworthy that only complete objects will be parsed correctly. In other words, this is not valid:

    But this is valid:


    Which is why we need to nest JSX objects as per lines 41-44.

  • “Exporting” react components when working in the browser: in the last line you see the code:
    window.__ReactTable__ = ReactTable

    Which allows you simply copy the javascript file in your project folder, and reference it normally using a <script> tag. To use the react component you simply need a single line as follows:

    var ReactTable = window.__ReactTable__

    which then allows you to use the component along these lines, using react props to pass the data to the table component:




Notes on Google Firebase Cloud Messaging

I’m a huge fan of Firebase, so I’m very excited that Google Cloud Messaging [GCM] has been re-branded Firebase Cloud Messaging [FCM], which can be used for cross platform messaging.


It’s actually very simple to set this up on Android and IOS, but what’s more interesting is the web client. I was really hoping things got eaier in this department. Unfortunately, right off the bat when checking out FCM web messaging nothing much has changed yet, the FCM site provides a link to the older (but excellent) codelab which details how to implement this using service workers and the HTML5 Push API. 


The problem is the Push API is a very quickly evolving standard with plenty of activity revolving around it, and the above article does an excellent job of describing the nuts and bolts of it all, but leaves out some important information that would drive more widespread Push API adoption IMHO:


  • Which libraries are available to simplify the process?

I’m not discouraging anyone from trying this, it’s actually pretty easy, but there are quite a number of steps involved, as we can see below, not counting encrypting and sending Push API payloads:


Surely there must be some libraries to help us out?

Let me try to address these two issues with some notes from research I’ve done so far (suggestions for avenues of research are welcome!! see my contact page to contact me).

Frontend libraries

There isn’t too much to write about here. The most promising one I’ve found that automates registering the service worker and handles a lot of the background work for the Push API is Google’s own “Propel” library. It’s very simple to implement as you can see from the readme, and only requires some minimal manual work like getting an FCM/GCM key, adding a manifest and a minimal service worker file.

While the library does handle the service worker registration and subscription side of things, it doesn’t do anything (yet) to help with actually displaying the notifications. I suspect this is going to change very soon, it just needs to be documented properly. That being said, adding notifications manually to the service worker file is trivial.

All in all, the library definitely helps in getting you on your feet quickly and with less trouble

Custom Push data payloads and associated backend libraries

Ok, so we have push notifications working, but we want to send custom Push data payloads. As we previously mentioned, the payload needs to be encrypted before it’s sent to the client, meaning not even FCM would know what data is being passed through the data payload.

There are some excellent examples of how to achieve this in Mozilla’s service worker cookbook:

In those examples they use Marco’s web-push npm library for NodeJS. This works across Chrome and Firefox. There’a similar NPM library provided by Google themselves (web-push-encryption):

For the python lovers, we can use Mozilla’s pywebpush library:

Here’s a troubleshooting tip: almost all the libraries require you to send the endpoint subscription details to your server. The aforementioned Propel library shows an example of how to do this on their README. The above mentioned backend databases then use this information (which is basically a URL describing which endpoint to send the Push to, and two public keys that are used to encrypt the data). But, with the exception of Google’s we-push-encryption library, I was being returned with an HTTP 400 error: Unauthorized Registration. 

Weird, especially when the data I passed into all libraries was the same. Looking at the code from the web-push-encryption library, it seems that google is in a transition phase and while Chrome returns an endpoint similar to this:


We actually need to change the endpoint URL to something like:


Note the difference in URLs. In the web-push-encryption library they simply replace the string, so until Chrome starts returning the new endpoint you need to do this manually.

Once this is done, you can send custom payloads via Push and read that custom data via a call to:


In the service worker file, under the ‘push‘ event listener.

UPDATE: regarding the above idiosyncrasy, got an update from a Chrome dev:



Get every new post delivered to your Inbox.

Join 319 other followers

%d bloggers like this: