What I wish I knew about React
bitsofco.de
What I wish I knew about React
1–10 of 301 posts
Re: What I wish I knew about React
#2Aren’t hooks more confusing than the class components? In a class, you write your initialization code in the constructor - no infinite loop if you fetch something. And anyone who has used classes in Java or other languages would feel at home.
Re: What I wish I knew about React
#3Aren’t hooks more confusing than the class components? In a class, you write your initialization code in the constructor - no infinite loop if you fetch something. And anyone who has used classes in Java or other languages would feel at home.
Imo, hooks present an API that is much less difficult to internalize, but maybe holds your hand less? I used react for a few months on a sideish project and had trouble knowing which component method I needed for something, whereas with react now it's all covered by hooks.
Re: What I wish I knew about React
#4tldr; React is a view renderer. It renders views. Getting data to and from those views not included. Navigation? Not included. Persistence? Not included. Styling? Not included. Why? It's just a view renderer, that is to say, it renders templates.
When the only thing your application shares with its dependencies is its view renderer, you're going to feel a lot of pain. This is one of the big reasons why I use Ember.js for complex web-frontends (though holla to phoenix live views). It's a framework-- it has all them pieces you need included in a sane way that's consistent.
Just my two cents...
P.S. If you write JavaScript UI code, and you want to like be better at it, go write native UI code. You'll learn soooo god damn much, write better JS, and understand a lot more about what the fuck all these pieces (like react) are actually doing (rendering UI, managing state, networking etc) in a sane curated (thanks Googs, Microsofties, and Apples) way.
Re: What I wish I knew about React
#5Aren’t hooks more confusing than the class components? In a class, you write your initialization code in the constructor - no infinite loop if you fetch something. And anyone who has used classes in Java or other languages would feel at home.
No, you use componentDidMount etc, spreading out the logic that could go into a single hook into multiple lifecycle methods, spaghettied with other logic. Hooks are much cleaner.
Re: What I wish I knew about React
#6Aren’t hooks more confusing than the class components? In a class, you write your initialization code in the constructor - no infinite loop if you fetch something. And anyone who has used classes in Java or other languages would feel at home.
My superficial understanding is that React components as classes are far more complicated than they might seem at first. You're not in control of creating the class instances, rendering them or destroying them. React is in control of that.
The constructor is the wrong place for data fetching in React class components as far as I remember anyway. I don't remember the exact reason, but it always has been somewhat non-obvious and you always needed to understand the React lifecycle to avoid bugs in that kind of code.
Re: What I wish I knew about React
#7Aren’t hooks more confusing than the class components? In a class, you write your initialization code in the constructor - no infinite loop if you fetch something. And anyone who has used classes in Java or other languages would feel at home.
> And anyone who has used classes in Java or other languages would feel at home.
Not really because there's nothing object oriented about React.Component. It's just a wrapper for a function implemented as a class.
Re: What I wish I knew about React
#8(Opinionated post ahead...) React is, imo, garbage, but alas it's here to stay -- you know, kind of like Spring or Swing. In 10 years we're going to be wondering how the hell we ever used React 8 hours a day way back then. These kinds of markup frameworks/libraries were touted as jQuery's successor, but, from an architectural point of view, jQuery is by far their superior.
"Everything an HTML tag" is an insane mantra to have. As author points out, what in the world does a tag even do? It might make sense to us because we're used to it now, but the semantics of a tag is completely lost in this "new way" of using them (don't call it declarative because that's not what it technically is; it's markup). These days I'm creating HOCs on top of HOCs to support different behavior (from redux stores, to authentication HOCs, to "don't render this thing on the server" async components). It's, simply put, a terrible idea. And everyone just bought into it because the guys at Facebook must be really smart.
The lifecycle hooks are just confusing and unnecessary. They are side-effects of over-engineering. And to add insult to injury, they change every few versions (so old code will inevitably break on new React versions).
SSR. I've brought this point up on HN before, but doing server-side rendering in React is absolutely ridiculous. Every time I need to implement it, I'm constantly battling async stuff, state management, webpack/babel, hot module reloading issues, shimming `window` or `document` on the server side, etc. Boy do I miss the days when I was building stuff in PHP and HTML was simply rendered when I ran the damn thing.
It's crazy to me that it's normal now to have like 3-4 compilation/transpilation steps when working on a simple JS-based app.
Re: What I wish I knew about React
#9To understand React, it is important to understand the difference between imperative and declarative coding. [0] React is a way to write declarative code that use life cycle hooks or effects to do imperative "stuff".
The best explanation oh how useEffect works is by Dan Abramov [1] It is also worth reading his article on React as a UI Runtime as it is a good explanation of React conceptually under the hood.
[0] https://courses.reacttraining.com/courses/250055/lectures/38... (Can sign in for free to watch this one video.)
Re: What I wish I knew about React
#10Aren’t hooks more confusing than the class components? In a class, you write your initialization code in the constructor - no infinite loop if you fetch something. And anyone who has used classes in Java or other languages would feel at home.
I've worked with both extensively, hooks are way easier to grasp, they allow you to avoid numerous ifs and comparing manually to previous states, you can separate actions according to what properties you're listening changes on, which would be cobbled together in a traditional life-cycle method, and the best part? They can be reused between components