It happened by chance

Recently I was asked to write a very small POC with these constraints:

  • two color pickers
  • show a gradient of the two chosen colors
  • show tints and shades for each color
  • use React as frontend framework

They gave me one week, and of course, this was to be done outside the normal working hours. I accepted mainly because I was waiting for the right opportunity to learn and use React in a small project.

Yes: I never used React up to now. I lost that train. Sorry.

Getting started

I left the assignment in some obscure corner of my brain for a couple of days, enjoying the weekend (they sent it to me on Friday). On Sunday evening, I took some paper and a pen and started prototyping a bit the UI: where to put the color picker? How to show the gradients? What would be a nice flow for the user?

Then I went to sleep.

On Monday, I looked around for a “React Quickstart” or a quick project template: as I told you, I never used React before, and coming from Angular (1 and 2) my main concern was the boilerplate’s time. It can really spoil any plan of releasing a small project fast.

I was lucky since I found the getting started page very useful, even if I didn’t use the app creator they are providing. Rather, I followed this nice tutorial from TutorialsPoint. I just had to fix some dependency issues upgrading Babel and Webpack, but I managed to have a working “Hello, world!” in less than one hour.

Starting from this point, I coded quite fast, and I was surprised by how easy React is: I was learning and developing my POC without studying intermediate tutorials (like I had to do with Angular, for instance).

Easy? Easier!

Let’s pick a real world example: resize the canvas to match the new viewport’s sizes. With Angular, I had to put a listener on the window object: managing several canvases, I had to centralize that handler with a directive publishing the event through a service… how much code!

With React, the whole lifecycle is already handled by the render() method: all I had to do was to act after the rendering process, using the ad-hoc handler, so to be able to get the actual canvas size and properly update the attributes.

I felt like I wasted part of my life developing and maintaining a whole 3D UI with Angular 1 in 2014/2015, while I could have used React.

Lesson learned.

Single responsibility

What amazes me is that React really adheres to the Single Responsibility principle: it does the view and does it well. I won’t be tired of repeating how easy is to build a UI with it.

At a certain point, I realized I needed a helper function to create a smaller component bound to a certain context. Where to put it? Just a simple JSX file exporting the function: no factory, provider, service, IOC container, DI, …forget it.

JSX? Yet another JS-like language?

This is the first thing I thought a couple of years ago when I first looked to React: do we need it? Another compile-to-wannabe-the-next-js? I definitely didn’t like the idea. But I didn’t know what JSX actually is.

From the official docs:

JSX is a XML-like syntax extension to ECMAScript without any defined semantics.

They are not replacing JS with a (supposedly) better *script: they are just getting rid of the ugly and error prone string manipulation which is still used to produce HTML from the JS code. XML literals. Just do it easier. All the rest is the same Javascript I always used.

Separation of concerns

And here’s the last, and most important issue I thought I had with React: it clearly violates the Separation of Concerns Principle. At least this holds if you consider the component’s HTML and the logic strictly related to it as two different domains just because they are written in two different languages.

Wait, what is the domain? The component, or the language(s)?

The component is a whole entity, the consumer shouldn’t even know what’s inside it: it just brings a functionality, and you consume it. Furthermore, if you have some business logic strictly related to that specific markup, splitting the code makes it harder to quickly compare and modify it,  not to mention the fact that to tie them together some Javascript in the HTML is still needed: and we can see it in the Angular and Aurelia approach, where the HTML is filled with Javascript code every three lines.

So, what are we talking about?

I definitely changed my mind, and I prefer the approach of React, Elm and Scala.JS, all of those have either XML literals (React, Scala) or functions which return HTML (Elm, Scala.js with Scalatags).

Of course, this is my own personal opinion.

The project

Just for the records, it took me 17 hours (roughly two working days) to finish and deliver the POC. Of this time, around 4 hours were used to sketch, polish the UI and write the CSS. No more than 3 went for setup, dependencies update and learning the basics. The rest of the time was the actual functionalities implementation while learning React through the official documentation, implementing also first a solution without canvas (check the branches).

Let me tell that I really enjoyed this task.

The small page I built using React is visible live here. It’s not rocket science, just a very simple page.

The source code is available here, as usual feel free to use it as you prefer since it’s released under MIT license. And if you see any mistake, anti-pattern or bad practice, please correct me.

Thanks.