I open sourced 3 modules from Airbnb

…and here is how it helped me

Background

As I was reading Adam Neary’s story of Rearchitecting Airbnb’s Frontend, I came across two React components, which have really aroused my interest as a rookie frontend developer.

To name them, they are called <HideAt/> and <ShowAt/>. I had several reasons, why I got interested in them so much:

• I wanted to create my very first NPM module, but I didn’t want to make it, just for having one. I’ve always wanted to give value to the community by creating it.
• <HideAt/> and <ShowAt/>, they solve a problem and I even think there are more potential in them.
• They seemed easy to replicate, although at first sight, I didn’t have a clue how I should start implementing them.

From the words of Adam, <HideAt/> and <ShowAt/> are:

They are responsive utilities, which allow us to dramatically alter what the user experiences at different screen sizes without having to hide and show using CSS. This leads to much leaner pages.

Implementation

As a starting point I went to airbnb.com, opened up the React Dev Tools and searched for either <HideAt/> or <ShowAt/>, I can’t remember now. 🙃
Soon I realised, I have to implement 3 modules and not 2, since they were wrapped into a HOC called, withBreakpoints. (Fun fact: When I first encountered them, I didn’t even know exactly what a HOC is.)

After this, I tried to copy the behaviour of the 3 modules from Airbnb’s website with the best of my knowledge and with the help of Google.

These three modules, taught me a few things:

• Reading the docs is always the shortest path
• Before you’re about to create a new npm module, it’s useful to look for competition on the market, don’t reinvent the wheel
• It pays off reading your competitor modules’ source code (if there is one of course)
• Don’t hesitate so much on the How?, just start doing it and eventually you’ll get there
• Use npms.io and take a look at how they are ranking your module, it can really provide you with some helpful insights

From the technical aspect:

• What HOCs are and why they are useful
• Configuring babel and eslint
• Getting familiar with test writing with jest, enzyme and Node‘s assert
• Using coverage with coverall and Travis CI

In the end, I was ready with all the 3 components featurewise. I was able to publish them, but I still didn’t have any unit tests written for them, nor a continuous integration service set up for the repos.

As I use quite a few npm modules from day to day, I tend to prefer those, which have tests written and own 💯 coverage percentages or rather 90% <.
So all in all, I had work to do, the hard work to do… at least I thought so.

Travis:
The ease of setting up Travis CI (the integration service I chose to use) was a pleasant surprise for me. I just had to create a .travis.yml with the following snippet:

# .travis.yml
language: node_js
node_js:
  - 6
  - 7
notifications:
  email:
    on_success: never

TIP: The notifications property is optional, but with declaring it, you can configure your notifications from Travis. In the above code snippet you can see that I prefer getting emails only about my failing builds.

Unit tests:

Read the docs, read the docs and read the docs. 😃

No, but seriously, I haven’t written any unit test before, I didn’t even know the concrete difference between jest and enzyme. So you can imagine how I started this challenge. 😱

And after I read the docs carefully, suddenly I realised that this was a pleasant surprise as well. You can pick up unit test writing really quickly — of course I’m talking here about some basic things like, “component is able to receive and change its props”, but my message just tries to suggest that test writing is totally not hard to learn. 😊

To sum it up, these two were the ones, which seemed to me the biggest painful points in the implementation. I just wanted to tell you, that how wrong I was.

More potential

In my opinion <HideAt/> and <ShowAt/> has more potential then just being responsive utilities. Combined with withBreakpoints and James Kyle’s react-loadable they could provide truly leaner webpages, by importing only the bundles the client-side needs.
For example, when you open a page on mobile, the tablet view bundle and the PC one could be left out, since they are unnecessary/redundant in that context. Those bundles could be imported in asynchronously, only when resize happens.

Final words

If you got interested about these components, you can reach them via the links and if you were there, feel free to open issues or fork them. 🙂

Last but not least, I’d like to thank Tamas Fodor for mentoring me on these projects, Jakub Juszczak for your medium post about how to publish npm modules, and Adam Neary for creating that medium post and sharing these components, now they are shared with the whole React community. 😉

Please hit or hold that little 👏 icon, if you liked my little story of my first 3 npm modules, and thank you for reading this!