Abstraction is your friend

Recently I started building my dream-library of reusable components. Standalone article about my components library will surly follow soon, so stay tuned. Now just few notes…

Every time I’m creating a new component that is not in library yet, I will use abstraction to make it as general as possible

Take spacing as an example. Every developer is dealing with it all the time. You need to add 10 pixels above and 10 pixels below. Or 15 pixels above and 20 pixels below. Or 8 pixels to left and 3 pixels to the right. Doesn’t matter. The core issue here is that you need to add some spacing.

Forget about adding new line of CSS every time you need it. Create general configurable component for it. Create it only once and then just use it with pixels passed as the parameter. And use it not only in your current project. But in any future project.

Or toggling as another example. You need to toggle the menu. You want to expand or collapse some block of text. You would like to display tooltip when you hover over the link. Or switch between two states of some component. Do you see the pattern? The “Toggle” component or whatever you call it. Create simple general functional component for this. Add it to your components library and use easily every time you need to turn something on or off.

You can write even higher-order components (HOC) or function. They are components that return different component or function. They are super-powerful in terms of reusability and abstraction. Anyway, they might be a little difficult to reason about, so you can avoid them if you prefer less mind-challenging solutions.

Platform-independent components

I will stay with examples from React world. Because I’m biased :)

I bet you already heard about React Native. If you are React developer and want to provide native experience to your customers on mobile devices, JavaScript will help you also with this task.

Yes. The same JavaScript code that runs in browser, can be used also in native mobile applications. The same app for Android, iOS and for web. Even for desktop if you want. For example Skype is written like that, so it’s definitely possible even for more complex apps. Write once, use everywhere.

You don’t even need to know different languages for server side of you app. JavaScript became universal language thanks to node.js. But it’s another story…

Performance matters

The less third-party packages you pack into your app, the less size of the released bundle will have. And it’s also very important.

I remember situation when one of my colleagues added moment.js into our dev stack. It’s library for easier date and time manipulation. We found out after release that more then 1 MB of translations files for almost any existing language were included into build. And we needed just English. What a shame.

Always check the size of third-party packages before you add them into your package.json. Tree-shaking might be happy to help. And try to keep size of the resulting build files under reasonable limit. Always ask yourself if you couldn’t write your own small code for given problem.

Or take a look into you components library, if you already haven’t written it before. The more repetitive patterns you transform into reusable components and functions, the less code you push into user browsers.

Performance topic would be for standalone article. Actually Addy Osmani wrote a good one already.

In case you need to create simple page displaying data in the table of few rows with some basic user interactions, consider if it makes sense to setup all the Babel, Webpack, Less and React stuff. What if writing small script in plain old ES5 JavaScript will result in the same functionality? The only difference will be 5 kilobytes instead of 50. Or 500. And that really matters.