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

Hooks: React’s Do-Notation

devanshj.me

Post reply on HN
Print view View original

51–60 of 80 posts

Re: Hooks: React’s Do-Notation

#51

Post by pennaMan »

captainmuon wrote: post #47

I really don't like hooks, because they are so magic. The old class based way of doing things was much more explicit. At least, hooks should take some kind of "context" and "name" parameters so that they are in spirit a pure function. Then you could also call them in loops and if blocks without problems. Actually, class-based components have some annoying magic, too. The type of the object you create when you write `…

The old class based way of doing things was a slap in the face for anyone expecting a "reactive functional ui library" and it put me off react until they did the proper hooks implementation.

Re: Hooks: React’s Do-Notation

#52

Post by onion2k »

captainmuon wrote: post #47

I really don't like hooks, because they are so magic. The old class based way of doing things was much more explicit. At least, hooks should take some kind of "context" and "name" parameters so that they are in spirit a pure function. Then you could also call them in loops and if blocks without problems. Actually, class-based components have some annoying magic, too. The type of the object you create when you write `…

The old class based way of doing things was much more explicit.

They weren't though. They looked explicit, but what was actually happening wasn't what appeared to be happening. Dn Abramov wrote a good blog post about the subtle bugs that can sneak into class components - https://overreacted.io/how-are-function-components-different...

At least, hooks should take some kind of "context" and "name" parameters so that they are in spirit a pure function. Then you could also call them in loops and if blocks without problems.

Dan also addressed a lot of the 'why are hooks like that?' questions in another post that goes into some of the designs the React team rejected. https://overreacted.io/why-do-hooks-rely-on-call-order/

Hooks can be hard to reason about but they make code a bit less error prone because when they don't work they fail completely. Classes don't. Classes work most of the time. That is so much worse.

Re: Hooks: React’s Do-Notation

#53

Post by alserio »

captainmuon wrote: post #47

I really don't like hooks, because they are so magic. The old class based way of doing things was much more explicit. At least, hooks should take some kind of "context" and "name" parameters so that they are in spirit a pure function. Then you could also call them in loops and if blocks without problems. Actually, class-based components have some annoying magic, too. The type of the object you create when you write `…

There are a lot of similar feeling alternatives beyond react. For example SolidJs is jsx based and ditches also the reconciler (modulo lists). It has a lot of cleverness in what it does with that jsx, but the result is way more straight forward and composable.

Re: Hooks: React’s Do-Notation

#54

Post by Cthulhu_ »

mdoms wrote: post #9

Sometimes I look at what's going on in React land and just want to ask these developers, do you really need all this to make a UI? Really? Are you sure? Are you making things better?

At the moment yes, given that things I'm improving is an old (2012) Dojo application where the closest thing to a component is a function call that concatenates HTML, CSS and JS together. Yes that's JS-in-a-JS-string, it's er, interesting.

I'm dealing with thousands of fields with hundreds of different validations (usually min/max values or regular expressions), React is not the only one that can solve this, but at the moment I don't regret my decision. And with hooks and functional components, they're really compact - compared to e.g. Angular, which is more aimed at Java/C# developers I believe in terms of formality and verbosity.

Re: Hooks: React’s Do-Notation

#55

Post by Scarblac »

mdoms wrote: post #9

Sometimes I look at what's going on in React land and just want to ask these developers, do you really need all this to make a UI? Really? Are you sure? Are you making things better?

I'd consider that a strange question since these development means the amount of code required is getting less and less each year. React code is really concise now IMO.

Re: Hooks: React’s Do-Notation

#56

Post by Scarblac »

westoncb wrote: post #49
aaronbrethorst wrote: post #48

Earlier quoted context omitted.

Whatever makes you happy, my dude

I mean, am I mistaken? Is the UI more complex than it looks or something? I'm just basing my comment off what I've been able to find through your reference. If there is some new system that's a genuine improvement over React and kin I'd love to know about it.

Generally speaking, simple UI sounds like something to aim for. If your UI is "intrinsically difficult", there's a high risk the user will conclude the same thing.

Re: Hooks: React’s Do-Notation

#57

Post by playpause »

xixixao wrote: post #4

Interesting take, but I find it much more insightful to think about how you’d simply implement a hook (not any of the React specific ones). MobX uses similar mechanism. user declares foo with a call to “useState” function useState(…) { useStateCalls.push(…) } useStateCalls = [] foo() // do something with useStateCalls It’s a neat syntax sugar, it explains why they can’t be called conditionally, it allows for a clean…

For me the issue is whether the magic is fully acknowledged and explained by the project, bringing me in on the details of the compromise.

I tried to get into MobX years ago but found it impossible to get along with. I don’t know what it’s like now, but the documentation back then failed to explain the magic. It was just like “Hey, look how convenient this is, just follow our instructions and you’ll be fine (and don’t think about how it works)”.

Then some time later React came out with hooks, and they took the time to introduce the concept carefully, to explain how it’s actually really weird and non-idiomatic and principle-breaking but leads to all these ergonomic benefits, just make sure you understand the weirdness and keep it contained. They give you the information you need to change it in your head from ‘magic’ to ‘smart compromise’.

Re: Hooks: React’s Do-Notation

#58

Post by eru »

jitl wrote: post #13
eru wrote: post #11

Earlier quoted context omitted.

You can have a look at functional reactive programming for ideas. The article even links to more material about FRP.

FRP systems like RXJava, Combine, etc to me seems like an enormous and extremely convoluted kitchen sink of abstractions that I’d much prefer to avoid dealing with. From the outside it looks like a Turing tar-pit dressed up with fancy suspenders and a top-hat. It does not feel declarative to me; instead of declaring that function X needs data Y (and should recompute whoever Y changes), I instead need to set up a pipe…

I don't think RXJava has the 'F' component of Functional Reactive Programming?

I've worked with some rather nice FRP-like systems in Haskell. I doubt you could make this work in Java without losing your mind?

Re: Hooks: React’s Do-Notation

#59

Post by joeberon »

aaronbrethorst wrote: post #42
blindseer wrote: post #3

I'm not well versed in React so only clicked into this article out of mild curiosity. If anyone is interested in discussing the non-technical aspects of this submission, please continue reading this comment :) What do people think of the foray of these blog posts with embedded javascript components? It appears that this a nice way to provide interactive explanation on subjects. I think this post does a nice job. That…

I’d be much happier if that blog post’s text wasn’t a low contrast yellow on a black background. I switched over to reader view and didn’t see any JS components.

No post body was provided.

Re: Hooks: React’s Do-Notation

#60

Post by dgb23 »

freindk wrote: post #50

React breaks down because state comes in from multiple different directions and at different times - the history API has its own state, the query to the server has its own state, and the view has its own state, and they all happen at different times. When a page changes in the history, the state of the view must change to reflect the history state, but when the user changes the state like going forward in pagination,…

I don’t argue with the performance and bloat issues, but the state management problems you describe are not react specific at all. In fact react helps you to manage these things nicely.
Post reply on HN