Hacker News Reader

Comment by Spivak | Hacker News Reader

Ehh it really doesn't change the semantics of your code, hooks are just iterables and you access them by calling next(). In an alternative world they would be a mapping that you give unique names like useState("mystate", ...) and then order and if statements would be irrelevant.

Also you're just just passing a callback function to React and then giving it some pointers to data used as part of the conditional on when it should run.

Like it's janky and reaches through layers but it's not up and rewriting your code.

View on HN

> hooks are just iterables and you access them by calling next()

In Javascript, "just iterables" can be put in conditional statements, and they don't cause the outer function to be called again.

> Also you're just just

Ah yes. That "just" again

Edit:

> just passing a callback function to React and then giving it some pointers to data

Thing is, in plain JavaScript if it was a callback function, it could be called anything and live anywhere. However, these functions have to be named with a `use` prefix and have limitations on how they can be called.

And you can put hooks in if statements too, but like iterables it won't have the effect you probably want.

    it = ["hello", "world", "foo", "bar"]

    shouldbehello = next(it)
    shouldbeworld = next(it)

    if sometimes_true_sometimes_false:
       shouldbefoo = next(it)

    # if the conditional is false this will be foo, oops.
    shouldbebar = next(it)

Hooks aren't callback functions, they're functions that take callback functions. apparently this is breaking python. The naming convention is just so the linter can identify hooks, they're not magic.

    def react_to_stuff(func, var):
       orig = var.copy()

       def monitor():
          while True:
              sleep 2
              if var != orig:
                  orig = var.copy()
                  func(var)

       t = Thread(target=monitor)
       t.start()

     stuff = "Hello"
     react_to_stuff(lambda x: print(x), stuff)

No idea why you're giving examples in Python code when we're talking about Javascript and React.

On "it's iterators actually", I have a response to a sibling comment here: https://news.ycombinator.com/item?id=30799543

Because it’s better pseduocode and the concept isn’t language dependent.

Nothing is stopping you from putting useState in an if statement. You just have to be careful since it's an "iterator." For example if you put it in an if branch you will want to also use it in the else branch so "next" is called the same number of times.

In my experience I get a React error if the number of hooks changes between renders, meaning you can't have hooks in a conditional.

So, let me get this straight.

- These are "just function calls"

- Except they are "iterators"

- Except if you have them in a conditional, you must provide an `else` branch so that `next` is called the same number of times

None of this is in the semantics of the language where I don't have to provide an else branch to an iterator, and function calls are not iterators ;)

Like I really don’t know how to explain this any clearer.

* React stores the state for your hooks in a list which is iterable.

* useBlah is just a normal function that internally calls next() on that list to get the next hook state which is why order matters.

* React checks that the iteratior on the list is at the end to see if you’ve consumed all the hooks and throws an error if not because it’s indicative of a bug in your code.

Like at this point the only thing I can recommend is try writing a toy implementation of hooks and see that they’re not magic, they’re just normal JS, and that the restrictions flow naturally from the implementation.

Like why do you want so bad for hooks to be weird?

> is just a normal function that

you keep showing isn't a normal function :)

> Like why do you want so bad for hooks to be weird?

I don't want them to be weird. They are weird already. https://news.ycombinator.com/item?id=30801466

I guess we have very different definitions of "semantics" then. Rspec is wild but it's still plain Ruby. I'll give you that it's not idiomatic and it comes with some unusual restrictions on its use but libraries have been doing forever, I guess I'm just used to "you have to call this function to init the lib", "this function has to come after this", "you must call the cleanup macro here", "importing this lib monkey-patches these classes."

Reply on news.ycombinator.com