Intive Blog



For those who are just beginning with frontend development, particularly with JS, it’s difficult to believe how things were done before. And it’s also difficult to understand what “before” means, how things were made in the “old fashion way”, even when this “before” is just a couple of years ago.

The reasons we can mention as the most likely drivers of those differences are:

  • ES6, without any doubt.
  • Our computers’ throughput.
  • Computers with several Gb of memory at arms’ length.

But, necessarily, one of the most important changes -and I dare to say it’s as a paradigm shift (it’s really interesting the emergence of the Reactive Manifesto, trends such as the reactive programming)-, was the coming out of JS frameworks, such as Angular, Ember or Knockout, which transformed the MVC usual model into something more similar to MV*. Then it would come the glamour and arrogance of the rest.

These frameworks added something very important: we can have a web spatially -as from its code- separated, divided into different components.

Web and components

These frameworks, with their commands, widgets and templates, defined the foundation of what we can call a “component-based web”.

A web where each piece, each component, is considered and developed separately. Each one of them with its own look and feel, its functionalities and, mainly, the ability to be reused in multiple scenarios, having been coded only once. In other words, code once use everywhere, or don’t repeat yourself or KISS.

Use of components

If we think about components as something to be reused, or to be exported and imported, we can also consider them as something to be shared, exhibited or displayed.

Why would we want to do this? For instance, to involve three actors (at least) in the development process: the customer, other devs and those who give the “ok” to finish the job. In these cases, some problems may arise, such as:

  • Customer: preparing demos for the customer. Thinking about sending a code snippet or a screenshot to the customer may be difficult, just like inviting them to join the development environment, which may be sometimes inoperative, thus running the risk that they could find only one button or part of a form.
  • Devs: working with distributed teams, with different time zones. Devs who are far away from us, with whom -due to the time difference- we cannot find a moment to work together.
  • QA: having to complete a QA of something to be tested in a “dirty” context, such as the development environment, where other factors may interfere with the tests.


In order to avoid all these troubles, we are implementing the Storybook for some projects.

You can find its definition in the repo: Storybook is a development environment for UI components. It allows you to browse a component library, view the different states of each component, and interactively develop and test components”.

Here you can check some examples:

As we can see, it’s about a safe space, like a Sandbox, where we can set up or display our components on a separate basis, interact with them, click on them, open popups, datepickers, write in an input, etc. and there is also the possibility to preview certain actions (for instance, when you click on a certain button) or see what will happen with an input when we enter many characters.

Story creation

The process begins by creating a story for a button and then sub-stories containing different configurations for the same button. For example: changing the color, size, text or functionality.

How do we do this? The installation and configuration steps are detailed in the repo, but we can summarize them as follows: Storybook connects to its own server and, in case we make changes to the code through hot reloading, we can see the result of their implementation and then test them.

And as if that weren’t enough (I don’t think so, but it takes all kinds to make a world), we can also install add-ons, which extend their functionality (and we can also code them as needed).


Some of the add-ons are:


These are useful for logging the interaction with the user through events.


This is useful for documenting our storybook.


This is my favorite. Storybook defines it as follows: “Storybook Add-on Knobs allow you to edit React props dynamically using the Storybook UI”.

With this add-on we can, as from the story itself, edit the props of our component and see how it behaves in real time.

Some examples

Use of Knobs

The use of Knobs is extremely simple. We will have 3 sections:

  1. Sidebar with the stories we had already created.
  2. One main section, where we can see our component set-up.
  3. Another section (secondary), where we will see the add-ons results. In this case, using Knobs we will see and edit the component’s props, as well as see the changes in the component immediately.

Screen Shot 2018-02-07 at 5.23.00 PM

In conclusion

Whether for sharing our work with others, offering the customer a demo without giving a bad impression if something fails, or developing our components without need of having the whole completed project, Storybook provides us with a strong, simple and customizable solution. And what’s more: this is all for free!


Pablo Hiyano

Pablo Hiyano is coordinator of technical teams at intive-FDV. A student of Biology at Universidad de Buenos Aires (UBA), since kid his great interest in programming made him a self-taught developer passionate for the Javascript world. In his free time, he enjoys playing with his child, watching british series and reading about philosophy, especially works by Michel Foucault.

Add comment