My short career was filled with React.

Before graduation, I started to learn the framework from Vue 2.x. I entered the company in a state that I thought was ok at that time but now I can’t. React class components to functional components, from Redux to Recoil, from Antd to MUI…

Not long ago, a project that I had been working on for more than 2 years ended successfully. Now I have to work on a new project that uses Angular, so I bid farewell to React, which I have been using since graduation, and began to learn this framework that is rarely mentioned.

Have to

Looking back over the years, if there’s one thing React has brought me the most, I think it’s an idea, a programming paradigm. I went to study FP to understand React’s new functional components, but I’m not a fundamentalist, so I certainly don’t buy the argument that you have to learn Lisp to learn FP.

During this time, I found that Kyle Simpson, author of the Dirty Books, had also written a book about FP for JSer, and I was impressed by the introduction:

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 purpose of programming paradigms is to make code better organized and understood, and programming paradigms should serve the people who write the code, not the people who follow every rule and understand every arcane concept of the programming paradigm.

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 is about people, and so is writing code. What we need to do is to understand the programming paradigm itself and what it does behind it, and maybe one day you’ll discover that the thing I’ve been using for so long has an interesting name, or maybe you’ll never be able to explain what the concept is:

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

A monoid is nothing more than a monoid on a category of self-functors.

Does that mean I can’t play FP if I don’t understand? And then I have to stand at the bottom of the contempt chain, being pointed at by Haskell and Lisp players: look at that guy, he doesn’t know anything, he’s called FP?

I don’t have an answer to that, but maybe I’ll leave it to you. But now I understand why React Hooks are called “Hooks”; Why there is a hook called “useEffect”; I also understand why people say not to hook class component lifecycles.

In addition to writing React itself, I also tried pure functions, partial functions, Currization, composition, and point-free style code, which did bring some benefits and some inconvenience.

Maybe these thoughts are the biggest side effect I got from learning React.

loss

In contrast to React preparing for all in FP, my brief experience with Angular found it to embrace OOP fully. Just like when React switched from class to functional components, you need to completely change your programming paradigm to understand Angular. This forced me to revisit a lot of OOP ideas THAT I had discarded for a long time.

I can’t help but think of a TDD training camp in the company. After finishing the homework, I went to Coach to explain to him. During the explanation, Coach talked about abstract ability, isolation layer and anti-corrosion layer. At that time I found myself OO abstraction ability and together with the back-end of a small partner is really poor to no, only college ability. After reflection, they seem to have been “used” by React and have almost lost this part of their ability.

To be honest, I haven’t been working with React Class components for a long time. My first project was just a few months. The next two projects were written in Java, but the first one was tinkered with, more DevOps, and the next one was written in Java BFF, no abstraction at all, all data mapping. Then came a project that implemented “technical excellence” and was one of the early adopters of functional components.

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

Then when I look at dependency injection in the Angular documentation, I can only think of a few concepts: SOLID, decoupling. Don’t go into details. I don’t even know if these things I’m popping up are right. So I had to rely on my memory to search through the mail for relevant blog contest articles.

I seem to have gotten rid of OOP.

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

enlightenment

I’ve learned that the world isn’t black and white. Full embrace of OOP, but you can easily see FP in Angular — pipes for data and Rx for requests.

Since they are people-oriented, programming paradigms are not supposed to be antagonistic; they can complement each other and do what they are good at, even on the same project. Used to seeing the scene of two camps fighting, it seems that this scene is what I want.

Then I recalled a discussion I had on the project the other day about project subcontracting and concluded that OOP subcontracting by object and domain was better than FP alone most of the time. It makes features more focused and makes it easier for people to find what they’re looking for.

But on reflection, I will learn OOP well, but I will most likely not go into the relevant modeling methods for now. Because in my current work environment, I don’t see scenarios where front-end students need to have a deep understanding of modeling methods, and most of them are just a scratch.

From my own experience, I have seen and participated in DDD training, and also practiced from zero to one with my project back-end partners in building projects. But in the absence of practice, the whole process can’t escape the curse of learning and forgetting to learn. Probably the only thing that’s useful is that when I get caught working on the back end I can see why they’re organizing the code the way they do, and as for the modeling process, I’m probably not going to be involved. (Of course, if you have relevant experience, please remind me, for example, as a small partner of the front end, you need to master modeling methods, or the work will not continue)

Do not be limited by the technology stack, in fact, I have always had a half-understanding of this sentence, although maybe now do not have a strong understanding. But when you step out of a frame and think about the person in the frame, you might get a different perspective. Learning a new framework or language might not be a problem for Thoughtworkers, but can we take it a step further and think about something that seems “ethereal”?

Don’t let your frame frame you.

A small station to check out 🙂 teobler.com