Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RFC: Intent to Ship React 18

github.com

Post reply on HN
Print view View original

61–70 of 75 posts

Re: RFC: Intent to Ship React 18

#61

Post by dmitriid »

Spivak wrote: post #35
dmitriid wrote: post #31

Earlier quoted context omitted.

> 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 anyt…

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. apparentl…

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

Re: RFC: Intent to Ship React 18

#62

Post by richeyryan »

MuffinFlavored wrote: post #19
xiphias2 wrote: post #2

Rich Harriss, the author of Svelte talked about all the features that come to React to speed up virtual dom comparisions, but to me he's framework proved it that virtual dom is not necessary, and not the best solution for a scalable UI. At the same time there's a huge amount of React code at this point. It would be an interesting experiment to try to compile React code to really reactive code that doesn't need virtua…

Does anybody use https://preactjs.com/ seriously? I thought React and React-DOM were separate? https://www.npmjs.com/package/react https://www.npmjs.com/package/react-dom

I have used it on production projections and it's seamless. It works with third party React packages with no problems whatsoever and is much lighter. For a stock standard SPA with no need for the upcoming server rendering stuff in React, it's excellent!

Re: RFC: Intent to Ship React 18

#63

Post by richeyryan »

hn_ltl-ftc wrote: post #32

'useSyncExternalStore()' -- Gack! Now...that "little" it's-not-a-framework-it's-a-library whose scope is supposed to be confined to just the "view" part of MVC (by which I mean: "React") is inserting it's tentacles (along with a quirky architecture and proven to be error-prone coding patterns, cough, hooks) into the _model_. And it's already corrupted (at least partially) the "controller" part of MVC through React's…

React went from v0.14 to v15. The rationale was the library was stable at that point so they could switch to major versions. Why they went directly to version 15 rather than 1.0 is admittedly a bit odd. I guess it was marketing in the same vein of Java 1.4 to Java 5.

Re: RFC: Intent to Ship React 18

#64

Post by dmitriid »

brundolf wrote: post #47
dmitriid wrote: post #29

Earlier quoted context omitted.

> Using a compiler means that Svelte is essentially a dialect of EcmaScript So are hooks. The fact that you can't put regular function calls (which hooks look like) in an if statement, or have to provide custom "dependency lists" to some of them, or that data returned from them suddenly re-renders (aka calls again) the function they are in tells you that this is no longer regular Javascript.

Yes and no. They definitely push the boundaries, and the framework imposes certain extra restrictions on how it wants you to use them, and they warp your normal intuitions a bit. But at the end of the day they are just function calls. They don't compile down to some other sort of construct with totally different language semantics. There's a fundamental difference between a framework that takes your code and does wei…

Yes, they push the boundaries and essentially create a DSL with its own rules that do change semantics of the language. Not as drastically as a custom compiler, but they still do.

Re: RFC: Intent to Ship React 18

#65

Post by Spivak »

dmitriid wrote: post #61
Spivak wrote: post #35

Earlier quoted context omitted.

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. apparentl…

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.

Re: RFC: Intent to Ship React 18

#66

Post by Spivak »

dmitriid wrote: post #60
charcircuit wrote: post #34

Earlier quoted context omitted.

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.

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?

Re: RFC: Intent to Ship React 18

#67

Post by linkgoron »

chrisco255 wrote: post #58
linkgoron wrote: post #22

Earlier quoted context omitted.

Hooks are not simple at all, are very error prone, and definitely do not put the user in the "pit of success". JSX is terrific, but React has only gone backwards since classes IMO.

The main gotcha with hooks is declaring dependencies for re-renders. It does not take very long long to learn, and it certainly is simple to fix once the problem is realized. One of the nicest things about hooks + functional components is how much easier it is to refactor. With class based components, nested state and lifecycle behavior made it sometimes difficult to break down complex components. But I feel like wit…

I believe that React's hooks implementation is sub-par, not that "a" hooks implementation wouldn't work. Their current implementation badly needs a real compiler (the whole dependencies array stuff is atrocious, as well as some of the useMemo/useCallback performance issues), or a totally different approach that is actually reactive (e.g. SolidJS). IMO the burden of their implementation on the developer is too large.

Re: RFC: Intent to Ship React 18

#68

Post by dmitriid »

Spivak wrote: post #66
dmitriid wrote: post #60

Earlier quoted context omitted.

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…

> 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

Re: RFC: Intent to Ship React 18

#69

Post by Spivak »

dmitriid wrote: post #68
Spivak wrote: post #66

Earlier quoted context omitted.

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…

> 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."

Re: RFC: Intent to Ship React 18

#70

Post by brundolf »

dmitriid wrote: post #64
brundolf wrote: post #47

Earlier quoted context omitted.

Yes and no. They definitely push the boundaries, and the framework imposes certain extra restrictions on how it wants you to use them, and they warp your normal intuitions a bit. But at the end of the day they are just function calls. They don't compile down to some other sort of construct with totally different language semantics. There's a fundamental difference between a framework that takes your code and does wei…

Yes, they push the boundaries and essentially create a DSL with its own rules that do change semantics of the language. Not as drastically as a custom compiler, but they still do.

They specifically do not change the semantics of the language, they create a new abstraction on top of it that has unusual semantics.
Post reply on HN