Hacker News Reader

Comment by conmigo | Hacker News Reader

Hooks are just a dirty hack, but sold very well. Internally in React the state of a hook is being kept and updated when you call the set function, kinda similar to vtables and context in OOP. There is no other way to do this AFAIK. It only mimics functional programming, and that's why you see the restrictions about hooks, you cannot use them outside React, cannot nest, etc..

What's maybe the most stupid thing about hooks is that it's overruling the const type declaration:

  const [count, setCount] = useState(0);

You think count is a const? Not with hooks, because hooks are f!@#ng with your core language rules! And all those React + Hooks + Typescript fanatics that live in their type safe bubble fail to even notice it! Even Typescript doesn't complain about it.. Hooks make React a f'ing joke, they've given Dan way too much freedom at FB, IMAO.

View on HN

Hooks don't change the meaning of const. The whole render function is re-run each time something is modified. There is ZERO internal mutation going on in render functions.

I suggest researching and learning how something actually works before calling someone else's work a "dirty hack" or "f'ing joke".

(And afaik hooks were Sebastian Markbage's idea... f'ing genius if you ask me)

Wow, posts like these provide real counterweight to my desire to write open source software.

const is for assuring that the variable is never reassigned. It's not for assuring that variable cannot change.

const is not "constant".

In any case, in the useState hooks, if the value is changed via the set function, the component will be diffed and re-rendered. There is no value change happening while it is running in that scope.

> It's not for assuring that variable cannot change.

Please tell me how you'd change a to 1 in this example:

  const a = 0;

You can't do that. Just like you can't do:

    const [count, setCount] = useState(0); 
    count = 1;

In both cases, const is const.

The fact that `setState` modifies state outside of the local scope does not mean that a local variable is not const. This is really basic programming, it doesn't have anything to do with React.

Here's the exact same scenario without React to show why you're wrong in your original comment:

    const foo = () => {
      const bar = getBarFromDatabase();
    }

Imagine that this is a typical database where values can change, so that every time `foo()` is called, `bar` can have a different value. Do you think that this is a dirty hack that is overruling the const type declaration as well?

> This is really basic programming

No, it's not. React is iterating that piece of code of your function internally to modify the value of the const, there is no other way to do it. And it is especially confusing because you can use that const 'variable' in the scope representing a changing value. And the change is magically made by its 'setState' method.

If you do this yourself in a loop then it is of course totally clear what's going on, but now we're writing functions where parts of it are being iterated by React, and that's not functional at all, IMAO it's a hack.

React does not "iterate over parts" of your functions, it simply calls the entire function. There is no magic happening.

You've already received a lot of responses explaining how both const works (which you still seem to misunderstand) and how React works, I hope you can take this as an opportunity to learn and perhaps not be so confident in the future when criticizing something that you clearly haven't taken time to even understand at a basic level.

I really recommend learning more about what you're complaining about before arguing with people about how you think something works.

Your jargon doesn't even make sense. "iterating that piece of code in your function"?

Put a console.log() at the top of your function and you'll see that it's simply being called many times.

You don't. The closure ends, the stack is popped, `a` is disposed, and then, in another closure, you have this line:

    const a = 1;

`a` was never re-assigned, but the value of the variable we call `a` changed. I think the key here is knowing that if you have the following:

    function Foo() {
      const [a, setA] = useState(0);
      return <span>{a}</span>
    }

`Foo()` will be called on every render, `useState` will only use its argument the first time it's called (and then after that just remember its value), and `a` will be a "new `a`" every time, after which, like all variables declared in a function, it's discarded when the function returns.

Your example is a bad one.

  const a = { prop: "value" };
  a.prop = "different";

Reply on news.ycombinator.com