Do Not Be Limited By Your Tech Stack

My short career has been filled with React.

Before I graduated I started learning the framework with Vue 2.x and joined the company in a state where I thought it was okay at the time but now I look back and see that it's not. Then I started to work with React, from class components to functional components, from Redux to Recoil, from Antd to MUI...

Not long ago a project I had been working on for over 2 years was successfully completed and I had to move on to a new project that would use Angular. So I started to say goodbye to React, which I had been using since I graduated, and started to learn about this framework that is rarely mentioned.

What I got

Looking back over the last few years, I think what React has brought to me the most is probably the idea, a programming paradigm. I went to learn FP in order to understand React's new functional components, but I'm not a fundamentalist, so I certainly don't agree that you need to learn Lisp if you want to learn FP.

In the meantime I discovered that Kyle Simpon, author of You Dont Know JS, has also written a book dedicated to introducing FP for JSers, the foreword of which I was deeply impressed by:

The way I see it, functional programming is at its heart about using patterns in your code that are well-known, understandable, and proven to keep away the mistakes that make code harder to understand.

Yes, the role of programming paradigms is to enable people to better organise and understand code. Programming paradigms should go to the service of the person writing the code, not the person following every rule of the programming paradigm in every detail and understanding every obscure concept.

I believe that programming is fundamentally about humans, not about code. I believe that code is first and foremost a means of human communication, and only as a side effect (hear my self-referential chuckle) does it instruct the computer.

Agile needs to be human-centred, and so does writing code. What we need to do is to understand the programming paradigm itself and what it does behind the scenes, and maybe one day you will suddenly realise that this thing I've been using for so long has such an interesting name, or maybe you will never be able to explain what the concept is:

A monad is just a monoid in the category of endofunctors.

Does that mean I can't write FP because I don't understand it? Then I have to stand at the bottom of the contempt chain and be pointed at by Haskell and Lisp players: look at that guy, he doesn't really know anything, he calls that FP?

I don't have an answer to this question, so maybe I can leave it to everyone else to discuss. But by this point I at least understand why React Hooks are called 'hooks'; why there is a hook called 'useEffect'; and I understand why everyone says not to use hooks to implement the lifecycle of class components.

As well as writing React itself well, I have also experimented with pure functions, partial functions, curry, compose and point-free style code, which did give some benefits and did cause some inconvenience.

Maybe these ideas are the biggest side effect that learning React has had on me (laughs).

what I missed

In contrast to React's readiness to be all in FP, my brief encounter with Angular revealed its full embrace of OOP, and as with React's switch from class components to functional components, you first have to make a complete shift in programming paradigm to understand Angular well, which in turn forced me to review a lot of OOP ideas that I had long discarded.

I couldn't help but think of an in-company TDD bootcamp where I went to a coach after completing my homework and during the presentation the coach talked about abstraction, isolation layers... It was then that I realized that my OO abstraction skills were not as good as those of my back-end buddies, only capable at university. After reflecting on it, I felt that I had been spoiled by React and had almost lost this part of my ability.

To be honest, I haven't been working with React class components for very long, my first project was just a few months. I went on to write Java for the next two projects, but the first one was a bit of tinkering, more like DevOps, and the later one was a Java BFF with no abstraction, all data mapping. Then I went on to become one of the first people to use functional components in a project where "technical excellence" was the norm.

So my exposure to class components was only a few short months as a graduate.

Then when I look at the Angular documentation on dependency injection, I can only sporadically conjure up a few concepts: SOLID, decoupling. Not to mention the details, I don't even know if what I popped up was right. So I had to go back to my memory and search for relevant blog competition articles in my email.

I seem to have lost the OOP.

The best time to plant a tree is ten years ago, followed by now.

Enlightenment

Stepping outside of all in FP React I discovered that the world is not black and white. It says it's all in OOP, but you can easily find shades of FP in Angular - using pipe for data and Rx for requests.

Since it's human-centric, programming paradigms are not supposed to be in opposition, they can clearly complement each other and deal with what they are good at in their own areas of expertise, even if it's the same project. I'm used to seeing the two camps arguing, and it seems like this is the scenario I want.

So I recalled a discussion I had one day on the project about how to organise project packages that the OOP strategy of organised by class and domain is most of the time better than the FP-only approach. It keeps the functionality more focused and makes it easier for people to find what they are looking for.

But reflecting calmly, while I will learn OOP seriously, I probably won't be learning the modelling methods in depth at the moment. In my current work environment, I don't see any scenarios where front-end developer need a deep understanding of modelling methods, but mostly just a superficial understanding.

From my own experience, I have learned and attended training on DDD, and I have also practiced a little with my project back-end partners in building projects from scratch. But with not much practice, the whole process can't escape the spell of learning and forgetting.

Probably the only use case is that when I am working on some back end story I can understand why they are organising the code in such a way, but as for the modelling process, I am not likely to be involved.

Of course, if you have any relevant experience, please wake me up, for example, as a front-end guy you need to be skilled in modelling methods, otherwise you won't be able to do your job.

Don't let the tech stack limit you. In fact, I always used to have a half-understanding of this phrase, although maybe now my understanding is not very strong either. But when you step out of a box and think about what the person who drew the box thought, you may be able to get some different thinking. It may not be a problem for you to learn a new framework or a new program language, but let's take it a step further and think about the things that seem 'nebulous'.

do not be limited by your tech stack.