I must be the only person in the world who likes class components in React. Sure, it's often overkill and a functional component does the same thing with less code. Use a functional component in these cases. But if you're doing something more complicated then stop treating class components like the fucking devil. They have their place.
I overall agree. I use functional style programming a lot but for some reason hooks have always confused me. The component classes generally make sense to me and map onto other paradigms like flutter, vue, etc. Sure methods like componentDidMount are a mouthful but I found it much more explicit
React I love you, but you're bringing me down
161–170 of 574 posts
Re: React I love you, but you're bringing me down
#162Earlier quoted context omitted.
Nope, I'm with you. React inventing a half-baked, partial re-implementation of objects/classes (in a language that already has them!) with super-weird declaration syntax & runtime behavior, just to avoid telling their userbase "Ok you will have to use classes sometimes, for certain functionality", was when I started looking around, because they were clearly out of real problems to solve that were sufficiently good-lo…
Heh. Arguably JS itself "invented a half-baked, partial re-implementation of objects/classes"... _in their class implementation_. God it drives me nuts that the language will allow you to spread a class into an object and it will take the properties but not the methods.
Re: React I love you, but you're bringing me down
#163Earlier quoted context omitted.
I ditched React soon after they released hooks, mainly because I couldn't relate to the tradeoff React roadmap was taking from there. They went in a different direction from that point onwards, it seem like whatever code you write will become obsolete with the new set of best practices in the next release cycle. More importantly, I realized React is trying to tame Facebook level of problems and hence their design dec…
Step 1: The existing tooling is too clunky, big and a major PITA to work with, Developers spend most of their time fighting their framework and tooling to do simple things. Step 2: Someone gets fed up with this writes a framework that "does things right" and is designed for "simplicity" Step 3: People start loving the new tool because it is so much easier to work with. Step 4: People start to do things the tool wasn'…
For people like me who are new to JS and use these sorts of discussion to determine which technologies I should adopt first, it's really just pointless noise in the channel.
The little I know about JS so far, I definitely know this joke is tired and played out.
Step 2: Get a better joke please?
Re: React I love you, but you're bringing me down
#164I must be the only person in the world who likes class components in React. Sure, it's often overkill and a functional component does the same thing with less code. Use a functional component in these cases. But if you're doing something more complicated then stop treating class components like the fucking devil. They have their place.
Re: React I love you, but you're bringing me down
#165It may be due to the codebase I'm working on, but I doubt it since I assume I have decent colleagues (I'm in a FAANG), but I just fucking hate React. I spent years working on Angular before changing team, and there everything makes sense instantly. It's just normal programming, normal MVC, normal everything, and you basically only need to learn about the syntaxic sugar for data-binding and stuff like this. In React i…
Re: React I love you, but you're bringing me down
#1665yrs in progress, it’s still not documented let alone fixed. I tried to look at the code, and they make giant PRs and are experimenting with priority queues and bitmasks, which seemed pretty off in the weeds to me.
Re: React I love you, but you're bringing me down
#167Earlier quoted context omitted.
Step 1: The existing tooling is too clunky, big and a major PITA to work with, Developers spend most of their time fighting their framework and tooling to do simple things. Step 2: Someone gets fed up with this writes a framework that "does things right" and is designed for "simplicity" Step 3: People start loving the new tool because it is so much easier to work with. Step 4: People start to do things the tool wasn'…
This tired argument has been trotted out repeatedly, and isn't really funny anymore. It's just old and boring. For people like me who are new to JS and use these sorts of discussion to determine which technologies I should adopt first, it's really just pointless noise in the channel. The little I know about JS so far, I definitely know this joke is tired and played out. Step 2: Get a better joke please?
Re: React I love you, but you're bringing me down
#168Earlier quoted context omitted.
Context is useful for certain cases, but plain old useState/useReducers are the workhorses. I think the beta docs are pretty good about explaining the tradeoffs ( https://beta.reactjs.org/learn/passing-data-deeply-with-cont... ). To me one of the biggest issue is that almost everyone is deeply afraid of prop drilling. Passing props around and having some local state works very well for large parts of many application…
> To me one of the biggest issue is that almost everyone is deeply afraid of prop drilling. Prop Drilling is considered an anti-pattern for good reason. It very quickly turns your project into an absolute mess, making it impossible to determine where props are coming from and where data is actually set. Keeping that clean is one of the most important things you can do in a frontend codebase imo.
Re: React I love you, but you're bringing me down
#169Earlier quoted context omitted.
Step 1: The existing tooling is too clunky, big and a major PITA to work with, Developers spend most of their time fighting their framework and tooling to do simple things. Step 2: Someone gets fed up with this writes a framework that "does things right" and is designed for "simplicity" Step 3: People start loving the new tool because it is so much easier to work with. Step 4: People start to do things the tool wasn'…
This tired argument has been trotted out repeatedly, and isn't really funny anymore. It's just old and boring. For people like me who are new to JS and use these sorts of discussion to determine which technologies I should adopt first, it's really just pointless noise in the channel. The little I know about JS so far, I definitely know this joke is tired and played out. Step 2: Get a better joke please?
If you define yourself by the technology you work with you aren't an engineer you're a technician.
Re: React I love you, but you're bringing me down
#170Earlier quoted context omitted.
I'm definitely a novice when it comes to React, but I've shipped a beta version of an internal took using it. I never understood the emphasis on functional components. Everything I did using them was made more complicated and less obvious, especially for colleagues who are not familiar with React or JS in general. React is built on components which are objects (both in a programming and GUI sense). Using OOP to descr…
Functional components tend to be easier to compose. If your class component has very specific functionality that you won't need in other components it's fine but if you want functionality that will be shared across multiple components wrapping up that code into it's own hook is easier to share across components then trying to use wrappers, extending classes and HOCs.