Live data from Hacker News

React is holding me hostage

emnudge.dev

41–50 of 553 posts

Re: React is holding me hostage

#41
post #32
post #27

I've been working on a React side project for a few months now and looking at my company's apps plus posts like this I think people just miss the point. Stuff like this: >Things get more complicated when you start using React Context and start signalling updates in a parent component. The render cascades. Maybe one component fetches some data, some component remounts, and you run your state update again, delayed by a…

The example you highlighted as "doing it wrong" is pretty typical for an autosuggest component: Input updates trigger some request, which propagates to some list somewhere else in the dom. As it's loading, a spinner is shown, but when results are retrieved, they're updated again. Throw in apollo to the mix or some other request library, and context is used.

Think you're gonna have a bad time. Should be something like:

function handleChange(e){

  getAutoSuggestions()

  setLoadingState(true)
}

^ Side effects happen in response to user input

function getAutoSuggestionsCallback(resp){

  setSuggestions(resp)

  setLoadingState(false)
}

^ No side effects

Re: React is holding me hostage

#42

Earlier quoted context omitted.

You can often use route params or location hash for communicating state sideways if shared context is overkill, with the benefit of making the state bookmarkable or accessible in the history.

That's only sustainable for small pieces of state or some mechanism to exchange that small piece of state for a more complete piece of state.

Right, the problem with React is it has no global answer for application state, instead it provides a toolbox with which it is possible to set up your own state handling but frequently you face structural instability where a small change in your app’s functionality require large architectural changes.

Re: React is holding me hostage

#44
post #33
post #27

I've been working on a React side project for a few months now and looking at my company's apps plus posts like this I think people just miss the point. Stuff like this: >Things get more complicated when you start using React Context and start signalling updates in a parent component. The render cascades. Maybe one component fetches some data, some component remounts, and you run your state update again, delayed by a…

> Ultimately, React is f(newState) => UI. If that function isn't pure you're gonna have a bad time. React is not that at all. Unless your UI is very simple, React is not f(newState) => UI. React isn't functional. More on that here: https://mckoder.medium.com/why-react-is-not-functional-b1ed1...

The linked article doesn’t convince me, instead it shows a misunderstanding of react and hooks.

> But then they added hooks and useState and useEffect and so on, which made the functions impure. The problem with hooks is that they “hook into” React state and lifecycle features, which means it is modifying global state.

React components don’t update the dom every time they run, they update the fiber tree / virtual DOM.

Only in the commit phase is the DOM updated and side-effects are run.

My rough understanding is that:

Hooks, excepting useEffect, all run in the render phase.

UseState hooks store data in the component in the fiber tree, and capture a sequential list of updates when you call setState.

Algebraic effects can seem a bit odd at first, but it’s really like a generalised try/catch. Instead of storing state in the function itself, you reach out up the stack to the component and store it there. And every hook you call from your hook stores it there too.

It’s why call order is important, because it’s how they know which is which.

You don’t modify any global state though.

The actual component function needs to be able to be called multiple times in the render phase (which just updates the vdom), and must have the same output each time, if the inputs/props are the same.

Every now and then, the tender phase can be interrupted to run the commit phase, which synchronously brakes a snapshot of the vdom and applies all the needed updates to the outside world.

Perhaps it’s better to think of as

render: f(props) -> descriptionOfUI commit: apply(descriptionOfUI)

I would absolutely say components and hooks are functional, with algebraic effects. And that the resulting data struct from those components, is what’s used to produce side effects.

Even useEffect, is a description of a side effect to run, it doesn’t run in your hook, it runs on commit with all the other side effects.

There’s a ton of optimisations under the hood but that’s roughly my understanding of how it works.

Re: React is holding me hostage

#46

Earlier quoted context omitted.

You can often use route params or location hash for communicating state sideways if shared context is overkill, with the benefit of making the state bookmarkable or accessible in the history.

That's only sustainable for small pieces of state or some mechanism to exchange that small piece of state for a more complete piece of state.

> or some mechanism to exchange that small piece of state for a more complete piece of state

using links to refer to information is, like, not a totally foreign concept to the web (and certainly granted: in some cases this issue of signaling via url can get quite ugly; but often it's not).

Re: React is holding me hostage

#47
post #44
post #33

Earlier quoted context omitted.

> Ultimately, React is f(newState) => UI. If that function isn't pure you're gonna have a bad time. React is not that at all. Unless your UI is very simple, React is not f(newState) => UI. React isn't functional. More on that here: https://mckoder.medium.com/why-react-is-not-functional-b1ed1...

The linked article doesn’t convince me, instead it shows a misunderstanding of react and hooks. > But then they added hooks and useState and useEffect and so on, which made the functions impure. The problem with hooks is that they “hook into” React state and lifecycle features, which means it is modifying global state. React components don’t update the dom every time they run, they update the fiber tree / virtual DOM…

> ...and capture a sequential list of updates when you call setState.

In functional programming, functions are not allowed to do that. The only thing a function is allowed to do is return a value.

> ...you reach out up the stack to the component and store it there.

FP functions are not allowed to do that. In FP functions can only rely on the parameters passed to it (it cannot refer to anything outside) and it should not do anything beyond return a value.

> It’s why call order is important, because it’s how they know which is which

In FP, functions can be called in any order (unless one function needs the return value of another), and the final result is not affected by the order.

> You don’t modify any global state though.

If you have state it is not FP, whether it is global or not.

Re: React is holding me hostage

#48
post #27

I've been working on a React side project for a few months now and looking at my company's apps plus posts like this I think people just miss the point. Stuff like this: >Things get more complicated when you start using React Context and start signalling updates in a parent component. The render cascades. Maybe one component fetches some data, some component remounts, and you run your state update again, delayed by a…

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.

Re: React is holding me hostage

#49
post #4

It's exciting & unsurprising to me that state is such an unsolved problem. For the longest time React was kind of in denial to a large degree about what they were. They called themselves a View library. Hooks have definitely noticeably changed that relationship, & how people integrate app state with React, but the problem here of updating hasn't really changed all that much. It's not a new thing either. A lot of the…

There is context which wages a war against debugging and testing, for one thing. React has no real answer to state going sideways. Then there is controlled/uncontrolled component which is an example of structural instability (what looks like a tiny change to your boss is a bigger deal than it should be) unless you ride the crazy train and use “plain ordinary javascript” to build a parallel system to move (some of) th…

If you are having trouble testing context, you are _definitely_ doing context wrong.

To test the context itself: pass as children of the context components to render the context state.

To test the components within the context: create a context with mock functions/values.

React has no answer to state going sideways because React manages a tree of components, and you are not supposed to connect random branches of a tree. That would completely break the concept of tree, container/contained, and just convert everything into a graph, and graphs are much harder to deal with. BTW, HTML is a tree, not a graph.

Controlled vs uncontrolled and the boss demanding a tiny change is just another case of bosses not knowing about how it works the system and imagining things and then demanding reality to conform to their imagination. Not an issue with React.

Re: React is holding me hostage

#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?
Post reply on HN