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:
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?
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 ...
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
orconst
if we can usevar
? they always usevar
, never usedconst
, only one time we have found alet
. - The code speaks better than words:
var YesNo = ['Yes', 'No'];
// the original version
var SiNo = ['Si', 'No'];
- this is so much better than a
filter
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.
Top comments (1)
This was an amusing read. I can only imagine how tough it was to go through that. I've had similar experiences from a backend development perspective but nothing as out there as this.