I always considered hooks to be a poor-man's immediate-mode GUI, rather than some kind of pure FP thing. It's not immediate-mode at all, but there are similar benefits to just being able to produce UI in the middle of the interactive loop.
Hooks: React’s Do-Notation
41–50 of 80 posts
Re: Hooks: React’s Do-Notation
#42I'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.
Re: Hooks: React’s Do-Notation
#43Sometimes 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?
> do you really need all this to make a UI This only makes sense for a very narrow conception of the range of UI problems. If your UI is just a basic form or trivially reflecting database structure in a CRUD app, then you would have little to no need for React. If you were to try building e.g. the full Gmail UI and make the attempt with e.g. document.querySelector (or jquery) and again with React you would have a pai…
Nah, disagree. Case in point is Basecamp’s Hey product. Rails monolith. Server side rendered. JavaScript ‘sprinkles’ with Hotwire. https://twitter.com/dhh/status/1275901955995385856?s=21
Re: Hooks: React’s Do-Notation
#44React 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 [hooks] in a large React codebase for years now, I still can't stand them.
useEffect forcing you to clean up after yourself reminds me of RAII from C++. IMO, any "ugly" functional component with hooks is even worse when written as a class component.
Re: Hooks: React’s Do-Notation
#45Earlier quoted context omitted.
> do you really need all this to make a UI This only makes sense for a very narrow conception of the range of UI problems. If your UI is just a basic form or trivially reflecting database structure in a CRUD app, then you would have little to no need for React. If you were to try building e.g. the full Gmail UI and make the attempt with e.g. document.querySelector (or jquery) and again with React you would have a pai…
Nah, disagree. Case in point is Basecamp’s Hey product. Rails monolith. Server side rendered. JavaScript ‘sprinkles’ with Hotwire. https://twitter.com/dhh/status/1275901955995385856?s=21
What I can find on "Hey" so far looks extremely basic as far as UI goes.
And by all means, if what you're building only requires a very basic UI—absolutely go for it.
My argument is that when you're faced with is an intrinsically difficult UI problem, React (or similar FRP-inspired frameworks which the community has stabilized around) is a huge improvement over the "simpler" past way of doing it. And the only way to really understand that is to try building non-trivial applications with both.
Re: Hooks: React’s Do-Notation
#46Earlier 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…
Same. Every Rx codebase I’ve seen has been nightmarish to contemplate. I’d rather program in brainfuck.
Re: Hooks: React’s Do-Notation
#47I 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 `` in JSX is different from the component class you write. There is some wrapper around it IIRC.
I wonder what React would look like if you get rid of all the cleverness and hidden state, and keep JSX and the reconciler as only magic?
Re: Hooks: React’s Do-Notation
#48Earlier quoted context omitted.
Nah, disagree. Case in point is Basecamp’s Hey product. Rails monolith. Server side rendered. JavaScript ‘sprinkles’ with Hotwire. https://twitter.com/dhh/status/1275901955995385856?s=21
What I can find on "Hey" so far looks extremely basic as far as UI goes. And by all means, if what you're building only requires a very basic UI—absolutely go for it. My argument is that when you're faced with is an intrinsically difficult UI problem, React (or similar FRP-inspired frameworks which the community has stabilized around) is a huge improvement over the "simpler" past way of doing it. And the only way to…
Whatever makes you happy, my dude
Re: Hooks: React’s Do-Notation
#49Earlier quoted context omitted.
What I can find on "Hey" so far looks extremely basic as far as UI goes. And by all means, if what you're building only requires a very basic UI—absolutely go for it. My argument is that when you're faced with is an intrinsically difficult UI problem, React (or similar FRP-inspired frameworks which the community has stabilized around) is a huge improvement over the "simpler" past way of doing it. And the only way to…
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.
Re: Hooks: React’s Do-Notation
#50React 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, the state in JavaScript is changed first, then the history state must be changed, then you have to figure out which state caused the change so not to get stuck in an infinite loop.
When a user initiates a new query, the query state changes, which triggers the request to the server, and then the results come back, but the query state may change when the results come back, which would trigger another infinite loop. Eg, when total_count is unknown, and then it becomes known with a query and must be included in the query state for optimisation, etc (don't try to get total_count second time, etc).
That is the problem with React - state has timing issues. I hate it and don't use it anymore. I just use pure JavaScript github.com/thebinarysearchtree/artwork. Half the code of react with orders of magnitude more performance just by using standard JavaScript stuff. It is hard to argue with that, but people will try until it can't be denied.