Oh my React
Tags: adventure, chillingcode
Published: 2019-08-23 15:25:23

Hi Frontend developers and none,

I'm glad to present the **Chilling Adventures of an Italian Developer**, a dev series based on real-life events.

# Episode 1: Oh my React

## Prelude

A year ago I changed work, from a chilling IT consulting company (will talk about that in another episode) to a much better one.
The first project in the new company was a React/Spring micro-service and micro-frontend application with me working on the frontend part.

My team and my company weren't the only on the project, but also my ex-company (lucky me) and a very big -biG bIG **BIG**- global IT consulting company work, referred as **Lilith Company** from now on, works on it.

Thanks to the micro-frontend and micro-services architecture, my team don't have to work directly with Lilith's employees or my ex-company employees, but in some case, they ask for help to my team.

One of these time, asking for help on the frontend React part, Lilith's employees give us access to the codebase of their part of the project.

I have to make an introduction: no one of Lilith's employees have ever used React, or have worked with ES6, Typescript, Webpack (and so on), they were all legacy developer.

## No Saint to pray 

Before checkout their codebase I was aware that I would find some shit code. But the reality was so far from my imagination.

Anyone who has worked with React at least once in their life knows, it's also written into [React docs](https://en.reactjs.org/docs/composition-vs-inheritance.html):

> # So What About Inheritance?
At Facebook, we use React in thousands of components, and we haven’t found any use cases where we would recommend creating component inheritance hierarchies.

> Props and composition give you all the flexibility you need to customize a component’s look and behavior in an explicit and safe way. Remember that components may accept arbitrary props, including primitive values, React elements, or functions.

> If you want to reuse non-UI functionality between components, we suggest extracting it into a separate JavaScript module. The components may import it and use that function, object, or a class, without extending it.

And what they did instead?

```javascript
class BasePage extends Component { 
  // Hi every one,
  // 
  // i'm a fucking class with only one useless method,
  // but they like so much class extentions
}
class CrudBasePage extends BasePage { ... }
class CrudDialogBasePage extends CrudBasePage { ... }
```
And again ...
```javascript
class SearchBasePage extends BasePage { ... }
class SearchDialogBasePage extends SearchBasePage { ... }
```
And I can continue with hundred of this shit.

## Please, give me drugs or an explanation

After see they're codebase, in a call with Lilith's developers, we ask them why they have used inheritance when even React docs do not recommend to use it, and why they don't have used composition, or Context, or redux, or hooks (we already was using hooks) to share functionalities.

> We want to use inheritance.

They replied.

I and my team helped them with their problem and we went to drink to forget all the chilling code we have seen in their codebase.

## There is never a limit to the worst

Others chilling fact:

* why use `let` or `const` if we can use `var`? they always use `var`, never used `const`, only one time we have found a `let`.
* The code speaks better than words:
  ```javascript
    var YesNo = ['Yes', 'No'];
    // the original version
    var SiNo = ['Si', 'No'];
  ```
* this is so much better than a `filter`
  ```javascript
    let id = -1;
    let selected = this.state.dialog.selected;
    for (let i = 0; i < selected.length; i++) {
      if (BasicUtils.isEqual(selected[i], row)) {
        id = i;
        break;
      }
    }
  ```

***

Thanks for reading,
see you at the next episode.