Your thoughts on React Hooks

I haven't tried react hooks yet but I don't think it's a good idea. simplicity is better than complexity. Introducing a second way of doing something only makes it harder to decide which way to go. I think having one standard way of doing something is better than 2, let alone the increase in the library size. I never had any issues with the class components, in fact, it's much easier to pick up. These frameworks never standardize they keep on changing, for no good reason. I think I'm going to either switch to Polymer because it's very small and simple or leave web dev completely. What do you suggest?

Comments

[Dan Abramov]

simplicity is better than complexity.

I don't think anyone is arguing with that.

I think having one standard way of doing something is better than 2

Agree! If Hooks prove to be better, in the longer term we'd like to deemphasize class components until they can be out of sight, out of mind.

let alone the increase in the library size

The increase in library size is not very significant — something like 3%. However, in practice your app eventually might actually become smaller because code using Hooks minifies much better. This example is a bit extreme but gives you an idea: twitter.com/jamiebuilds/status/105...

I never had any issues with the class components, in fact, it's much easier to pick up.

It's not just class components, but also patterns like render props, higher-order components, etc. I don't think all of them together are very easy to pick up.

These frameworks never standardize they keep on changing, for no good reason.

Hooks solve real problems. It’s a pretty bold accusation that we change things for no reason — could you elaborate on which motivations you disagree with? We think there are very good reasons, and we have shared them both in the documentation, the talk, and an article. More concrete arguments would be helpful.

I think I'm going to either switch to Polymer because it's very small and simple or leave web dev completely. What do you suggest?

I would suggest to get familiar with motivations for solutions when criticizing them. Criticism is extremely valuable. But it’s hard to provide good criticism when you’re not familiar with the problems.

[Minja Davidović]

Experimenting is what gave us all the technologies that we have/use today :)

Changes are usually driven by:

• community feedback - keeping the devs happy
• reducing the amount of repetitive code
• reducing the chances of devs using a library/framework in an unintended way (you can often hear or read in the docs that even though something can be used, doesn't mean it should for every scenario)

With "breaking" changes like that, a transition period is needed - suddenly discontinuing support for one of the basic concepts would be considered highly unpopular. We'll see if sticks.
However, I do agree that learning new syntactic sugar often can be a bit tiresome...

[Darkø Tasevski]

Polymer ... small and simple

I hope you are not serious 😐

leave web dev completely

I kinda understand you, but if you are in this job you never stop learning, so if you have a problem with that I don't know what to say 😕Frameworks and libs come and go on yearly basis.

On the other hand React team said that hooks are optional and that classes will stay as the main method of instantiating components, there were a few really long posts about this on dev.to. Also, there is not a noticeable increase in the lib size because of hooks.

[Jamal Al]

I have no problem with learning new things but i have a problem with being forced or having to learn uninteresting, unnecessary things.

[sajjanbalar]

Hi,

Recently, I was writing a new electron app with react. I decided to write it using Hooks. From my experience, I found that hooks are great for the most part. There are however some issues with using it in certain cases. In such cases, I find using classes more useful.

The one pattern that I found very painful to code in Hooks is when I want to write a custom hook that is passed a callback which it needs to call on certain conditions. I have found that if this callback uses a state variable or more. For every update of the state of this variable, I will have to pass my new callback to the hook.

This causes two issues.

1. I have to remember every prop and state change that will be used by a function and write a useEffect hook to change the callback.

2. The callback might be used in a complicated way inside the hook and it might be a pain to update it again and again.

I don't know if that makes sense, so let me give you an example.

I have written a hook that is responsible for handling an eventsource and invoking a callback whenever it receives a message. Let's call this useEventSourceManager.
I like the idea of useEventSourceManager because it gives me the ability to refactor all eventSource management into one hook.
Now, useEventSoucreManager is passed a callback "handleMessage" which is used to render ui for the new messages received.

My problem with hooks is basically that the following code won't work:

const someFunction = props => {
  const [condition, setCondition] = useState(false);
  useEventSoureManager(...someProps, ...someStateVariable, handleMessage);

  some other code that will change state of condition variable

  function handleMessage(){
    if(condition){ do something...}
    else{ do something else...}
  }
}

The above code doesn't work because the handleMessage instance passed to useEventSourceManager always has the state variable "condition" set to false.

Also, I get why this happens. And the way to get around is to refresh the callback function. What I trying to point out is that that same code is much easier to write in classes.

[harkinj]

One other thing that springs to mind with hooks is that they feel 'circular' e.g SetwidthHook - when user changes the width the handler runs inside the hook (so some code of the hook is executing), state is updated, the component re-renders and the whole hook is executed.