3 ms·

You think ‘const [count, setCount] = useState()’ is normal javascript? It runs completely counter to the way functions and variables normally work, using some

You think ‘const [count, setCount] = useState()’ is normal javascript? It runs completely counter to the way functions and variables normally work, using some global store behind your back. The idea that react is “just javascript” has gone out the window with hooks.

yladiz 5y ago
The code you just put is vanilla JS, so yes it's normal, it doesn't require any compilation step to work. If you made a React component that returns something that didn't require a compilation step, like Hyperscript, then it too would be normal Javascript. You can argue that having a function perform a side effect in this way isn't a good design decision but it is supported in the language and "normal".
WorldMaker 5y ago
All of that is vanilla JS as of ES2015. The destructuring assignment is new enough that it maybe doesn't feel that normal to you depending on your current projects, but it's not really that unnormal: const [x, y] = [0, 0] // point destructuring If you really wanted to, you could always feel more at home by doing it the old pre-ES2015 way: var countState = useState() var count = countState[0] var setCount = countState[1] That's the same code. It's not even that different from how JS functions have always worked. const [x, y] = getPoint() No one would accuse a function named "getPoint()" of using a global store "behind their back", they assume it is "getting" the "point" from somewhere, certainly, but wouldn't necessarily know where (or care where in most cases if you are just using someone else's library or component). It could be using a window.point global, it could be making an XHR/fetch request to an API somewhere, it could be creating random points, it could be trying `this.point` and depending on any nearby Object.bind() or Object.apply() that `this` could be nearly any object (including window, but not necessarily). (JS's objects have always been that weird. That's JS's normal.) There are so many options and that's the nature of function calls you have no idea without seeing its implementation. The useState implementation is particularly a black box in React, but it's no more a "black box" than the the average "normal" function. Also all the spooky "Rules" about using hooks (maintaining their order, making sure they are never used in branches, etc) exist because it is not just using a global store! It is essentially using a curiously bound `this`, which again is very normal JS OOP going way back to the beginning of the language. It doesn't look like a normal object and React's developers don't want to call hooks "objects" to avoid confusion and because they are easier to program if you don't call them "normal weird JS objects" and use some fancier functional programming abstractions, but they very much are "normal weird JS objects". You don't see the weird Object.bind (equivalents) because the framework is taking care of those for you, but it's not the first (and it will not be the last) JS framework to give developers a black box API that looks confusing from the outside and asks you to trust it is doing the right thing inside.

yladiz 5y ago

The code you just put is vanilla JS, so yes it's normal, it doesn't require any compilation step to work. If you made a React component that returns something that didn't require a compilation step, like Hyperscript, then it too would be normal Javascript. You can argue that having a function perform a side effect in this way isn't a good design decision but it is supported in the language and "normal".

WorldMaker 5y ago

All of that is vanilla JS as of ES2015. The destructuring assignment is new enough that it maybe doesn't feel that normal to you depending on your current projects, but it's not really that unnormal: const [x, y] = [0, 0] // point destructuring If you really wanted to, you could always feel more at home by doing it the old pre-ES2015 way: var countState = useState() var count = countState[0] var setCount = countState[1] That's the same code. It's not even that different from how JS functions have always worked. const [x, y] = getPoint() No one would accuse a function named "getPoint()" of using a global store "behind their back", they assume it is "getting" the "point" from somewhere, certainly, but wouldn't necessarily know where (or care where in most cases if you are just using someone else's library or component). It could be using a window.point global, it could be making an XHR/fetch request to an API somewhere, it could be creating random points, it could be trying `this.point` and depending on any nearby Object.bind() or Object.apply() that `this` could be nearly any object (including window, but not necessarily). (JS's objects have always been that weird. That's JS's normal.) There are so many options and that's the nature of function calls you have no idea without seeing its implementation. The useState implementation is particularly a black box in React, but it's no more a "black box" than the the average "normal" function. Also all the spooky "Rules" about using hooks (maintaining their order, making sure they are never used in branches, etc) exist because it is not just using a global store! It is essentially using a curiously bound `this`, which again is very normal JS OOP going way back to the beginning of the language. It doesn't look like a normal object and React's developers don't want to call hooks "objects" to avoid confusion and because they are easier to program if you don't call them "normal weird JS objects" and use some fancier functional programming abstractions, but they very much are "normal weird JS objects". You don't see the weird Object.bind (equivalents) because the framework is taking care of those for you, but it's not the first (and it will not be the last) JS framework to give developers a black box API that looks confusing from the outside and asks you to trust it is doing the right thing inside.