Live data from Hacker News

React is holding me hostage

emnudge.dev

61–70 of 553 posts

Re: React is holding me hostage

#61

Earlier quoted context omitted.

The bit of react that is f ( newState ) => UI is the easy part. The bit that is g ( state , userInput ) => newState is the hard part. In particular managing the scope of that newState . Oh, and sometimes you need to handle h ( state , asynchronousData ) => newState too. And then comes the fact that even though your f is _pure_, it also has to be _fast_, because it's going to run every time you get a newState .

In my experience redux-toolkit + redux-saga for async stuff usually work really well. In case of performance problems one can go with profiling + targeted optimisations (e.g. a separate store, some locally managed state).

Glad to hear RTK is working well for you! FWIW, we actually specifically recommend _against_ using sagas in almost all cases. Instead, we recommend using our RTK Query API for data fetching and caching, and the RTK "listener" middleware for reactive logic:

- https://redux.js.org/usage/side-effects-approaches#recommend...

Re: React is holding me hostage

#62
post #56

Earlier quoted context omitted.

Don't call this functional programming. If you call setCount() then this is not functional because your function is doing something besides returning a value. In fact, it is setting state, which is against FP principles.

Okay. But is it against FP principles to write software that runs in web browsers then? Because web browsers exist, and they work in a nonfunctional way. So to interact with one we need to do a little bit of imperative code. And then react lets us figure out what to do when the web browser responds to that imperative code by letting us run a largely functional program . Which is pretty neat considering we’re doing so…

Why is it necessary to use FP to write software that runs in web browsers? To be sure, FP has benefits (such as, it is much more straightforward to reason about FP code), but those benefits are not applicable in React. So why pretend it is FP?

React is neither FP nor OOP. More on that here: https://medium.com/codex/can-we-all-just-admit-react-hooks-w...

Re: React is holding me hostage

#65
post #56

Earlier quoted context omitted.

I find it's best (if side effects and state mutation make you nervous) to think of hooks as essentially part of the function signature of a react component, both on the parameter side, as well as on the return side. They are not written as such, because of syntactic limitations of JavaScript, but essentially a react component that starts off like this: function MyComponent({}) { const [count, setCount] = useState(0);…

Don't call this functional programming. If you call setCount() then this is not functional because your function is doing something besides returning a value. In fact, it is setting state, which is against FP principles.

Most of the ideas at play here come from the functional programming world, which is why it’s often viewed from that lense.

React builds on functional reactive programming, something the FP world is known for[0]. I’m not saying it’s pure FP in the dogmatic sense, I just wanted to point out it’s closer to FP than the other paradigms.

Without the ability to interact with the outside world (side-effects), FP is not of much practical use. Not to say it’s bad or shouldn’t exist, just we need to add to it a bit to make it useful.

Why would we do that? Because the underlying ideas and principles provide a great foundation. Building on that to get FRP and algebraic effects, monads and so on, is very different to starting from OOP and brining FP ideas over.

React hooks are an interesting and tricky thing to put in a box, because they’re almost monads, almost thunks, almost algebraic effects. The interplay with fibers and components makes them hard to pin down, but they are much closer to functional than any other paradigm.

[0] https://wiki.haskell.org/Functional_Reactive_Programming

Re: React is holding me hostage

#66
post #59

Earlier quoted context omitted.

> In functional programming, functions are not allowed to do that. The only thing a function is allowed to do is return a value. Oh, yes, they are allowed to do that. You capture the effects into a list, and return the tuple of list and return value. If you feel like it, you wrap that into a monad to pretend you are only "returning" a single thing. > In FP functions can only rely on the parameters passed to it (it ca…

I think you may be missing the forest for the trees. The point of FP is that you can glance at a function and say 'this is obviously correct' without having to work out the state and context of every call.

But you can do that with algebraic effects. That’s kind of the point.

You keep the clarity of declaring what you want to happen, and abstract the how to the effect handler.

Re: React is holding me hostage

#67
post #40
post #37

Earlier quoted context omitted.

setState is a convoluted way of passing the newState to components. useEffect is a side effect and if you use it you're gonna have a bad time.

> useEffect is a side effect and if you use it you're gonna have a bad time. Right.. but then you can't really use React for building serious UI.

You can build serious UI’s without useEffect.

But it’s a powerful escape hatch like rust’s `unsafe` block. Rust can do amazing things to ensure safety of your program, but there’s still times where a human can do it better.

By signposting that, keeping it to limited blocks, and wrapping it up in a safe function you get the capability to do hard things, while exposing a safer API.

useEffect is similar, it lets you write the imperative synchronisation logic. For example if you need to interact with a DOM element that only has an imperative API, someone needs to do the work somewhere to wrap it in a declarative one. You can do that in a component with a useEffect hook, and then expose a declarative API.

Re: React is holding me hostage

#68
post #50

Not to start an unholy flame war, but if you were to start a new project and didn’t need to worry about the ecosystem or workforce, what framework would you choose? Vue? Svelte? Something else?

Honestly just use what you know. Unless your goal with the project is to learn new things or to have fun, than go with what is most interesting for you. Or if you are in a larger team, then talk to your teammates and try to get a consensus around what you are most comfortable with collectively.

I only advice against using a niche framework if you suspect the project is gonna be long-lived and managed by a medium to a large team, in that case pick the one of the big ones—React, Angular, Vue, or Svelte—which your teammates can agree with.

Re: React is holding me hostage

#69
React hooks could have been very different with very minor touches. But at this point, a structure has emerged where you need to make extra efforts to work steadily. It wasn't like that at the core of React. Class components had their own problems. But you know how to solve them. I don't think this applies to react hooks.

Re: React is holding me hostage

#70
post #66
post #59

Earlier quoted context omitted.

I think you may be missing the forest for the trees. The point of FP is that you can glance at a function and say 'this is obviously correct' without having to work out the state and context of every call.

But you can do that with algebraic effects. That’s kind of the point. You keep the clarity of declaring what you want to happen, and abstract the how to the effect handler.

None of that is true in React hooks. The negative sentiment towards hooks that you see here is because it is weird and complicated. Want to see how much simpler code can get when you code without React or any such fat frameworks?

Take a look: https://github.com/wisercoder/eureka/tree/master/webapp/Clie...

You just need to know JavaScript, HTML and CSS, not much else. The code is simple, and yet maintainable. No need for hooks, useEffect, useState, useMemo and all that crap.

Post reply on HN