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

61–70 of 80 posts

Re: Hooks: React’s Do-Notation

#61

Post by JoeyJoJoJr »

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?

Coming to React, after working with OOP for UI, was pretty mind blowing for me. It is so much better than anything I was working on 5 years ago. React has dramatically improved the landscape as a whole.

That said, I think React is fatally flawed in its necessity to treat state in immutable structures. I wish React could be more like an immediate mode UI library, or a “thin” rendering layer as it was originally advertised. I want to be able to structure and handle my state however I please. I think such a library is bound to come along and topple React.

Re: Hooks: React’s Do-Notation

#62

Post by rat9988 »

jaredcwhite wrote: post #26

React has hooks because React's "classes" were pretty crappy…partially due to crappy OOP in general in previous eras of ECMAScript. But instead of actually making their syntactical sugar better as JS' native OOP paradigm improved, they went the opposite direction. After having to use them in a large React codebase for years now, I still can't stand them. For a look at a UI library that actually rocks precisely becaus…

What would classes have brought to the table with syntactical sugar? Especially that themselves are syntatical sugar on functions.

Re: Hooks: React’s Do-Notation

#63

Post by rat9988 »

jackblemming wrote: post #35

The functional programmers always sound like wannabe mathematicians to me, with their fancy category theory words. And the OOP guys always sound like wannabe engineers, with their fancy AbstractFactoryFactory. Nice article though.

> The functional programmers always sound like wannabe mathematicians to me, with their fancy category theory words. And the OOP guys always sound like wannabe engineers, with their fancy AbstractFactoryFactory.

Nicely put, I'll steal it.

Re: Hooks: React’s Do-Notation

#64

Post by rat9988 »

Scarblac wrote: post #56
westoncb wrote: post #49

Earlier quoted context omitted.

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.

Usually the difficulty of a user to conceptualize something has nothing to do with the complexity of the code.

Re: Hooks: React’s Do-Notation

#65

Post by the_gipsy »

jackblemming wrote: post #35

The functional programmers always sound like wannabe mathematicians to me, with their fancy category theory words. And the OOP guys always sound like wannabe engineers, with their fancy AbstractFactoryFactory. Nice article though.

Way to troll everybody

Re: Hooks: React’s Do-Notation

#66

Post by IshKebab »

akdor1154 wrote: post #20

My first boss had an often repeated mantra in code reviews: "akdor, don't fight the damn language!" If you're using Python, write with Python concepts. In C#, write C#. In F#, write F#. Etc etc. React has many many great ideas. But they are perpetually fighting the language. Here we have a great demonstration of stuff that is built in to any ml-legacy language being hacked into js in a way that the transformation hap…

Reasonable advice to an extent, but sometimes the language is crap and you should fight it. If everyone had followed your boss's advice we'd still all be using `var` and `for in`.

Re: Hooks: React’s Do-Notation

#67

Post by deckard1 »

westoncb wrote: post #16
bigyikes wrote: post #2

The author discusses the sequential leaps towards functional programming: from mixins, to HOCs, to render props, and finally to hooks. I’m very comfortable with hooks, but I’m not much of a functional programmer beyond that. So my question is: what is the next step in this progression? What is after hooks?

> from mixins, to HOCs, to render props, and finally to hooks. While each item in the series is "more functional" in some sense, the progression itself is not something reflective of some kind of standard progression of concepts or techniques within functional programming. I'd say mixins have nothing to do with it; HOCs do in the sense that they're similar to higher-order functions (I suppose they literally are if th…

> I've heard described as "similar to" algebraic effects

I wonder if there is an equivalent of the Turing tarpit, but for languages that aspire to confuse with ever-increasing relationships to tangentially-related mathematical concepts. The Church tarpit? Or would that be the Lambda tarpit...

It sounds like continuations to me. Or Common Lisp conditions/restarts. But that would be an implementation detail when talking about React hooks. And if I'm brutally honest, that all sounds like a retroactive analogy to move hooks into the territory of functional purity or relevance to FP. Better than having people realize it's all a pile of ad hoc design choices on top of JavaScript.

> So I don't think there is any logical next step.

We're already transpiling everywhere. Just get rid of JavaScript! Svelte did it. TypeScript did it. Instead of brutalizing functions, React could instead be forging a new path in language design.

Re: Hooks: React’s Do-Notation

#68

Post by westoncb »

Scarblac wrote: post #56
westoncb wrote: post #49

Earlier quoted context omitted.

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.

Not intrinsically difficult to use, I mean that the problems involved in implementing some ui concept may be intrinsically difficult or not (this can happen even when from the user's perspective the UI is simple/elegant). When they are, then you need appropriate tools.

And yes absolutely as I’ve said, if it’s possible to for some domain to have a basic ui do that.

Re: Hooks: React’s Do-Notation

#69

Post by lewispollard »

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 way hooks are handled when invoked in functional components is magic, as all stateful things in react are, but hooks themselves are very straightforward. Once you've written a custom hook, it's obvious that they're basically just (yes, this is an oversimplification) react components without the render step. You use the React API just like any other component, including using hooks, and then return some piece of state or whatever is needed. Like functional components, they're just functions that run top to bottom when the props change.

Re: Hooks: React’s Do-Notation

#70

Post by KronisLV »

jaredcwhite wrote: post #26

React has hooks because React's "classes" were pretty crappy…partially due to crappy OOP in general in previous eras of ECMAScript. But instead of actually making their syntactical sugar better as JS' native OOP paradigm improved, they went the opposite direction. After having to use them in a large React codebase for years now, I still can't stand them. For a look at a UI library that actually rocks precisely becaus…

> After having to use them in a large React codebase for years now, I still can't stand them.

I actually feel much the same way and have vented about some of my frustrations before: https://blog.kronis.dev/everything%20is%20broken/modern-reac...

However, that amounts to precisely nothing, because the industry has decided to use hooks moving forwards and they're basically inevitable, because even if you'd ever want to use something like class based components, the libraries that you'll try to use and integrate with will still make you use them sooner or later, because it's actually not easy to maintain support for a wide variety of ways to use your library.

In the past few years, i've increasingly felt like i should look at either Vue (which i already use at my day job) or Svelte, or even Angular for my personal projects.

Post reply on HN