Comment by wruza | Hacker News Reader

Comment by wruza | Hacker News Reader

Parent Full thread

I hate it because when I take it, instead of UI programming I now have to satisfy some absurd ideas about how functional async meta higher effect bullshit should work. All I need is to process events and update MY model (not some convoluted async representation of it smeared across visual elements and their lifetimes), from which something would update control values and text blocks. That's not literally all I need, obviously, but I don't need react nonsense in my way. In case anyone curious what I'm using, see mithril.js.

Also react uses (or promotes) web-hostile anti-features like document level event handling and virtual scrolling, which are PITA from a devtools tinkerer perspective.

useActionState: is a new hook to order Actions inside of a Transition with access to the state of the action, and the pending state. It accepts a reducer that can call Actions, and the initial state used for first render. It also accepts an optional string that is used if the action is passed to a form action prop to support progressive enhancement in forms.

Delusional gobbledygook.

> I now have to satisfy some absurd ideas about how functional async meta higher effect bullshit should work. All I need is to process events and update MY model (not some convoluted async representation of it smeared across visual elements and their lifetimes), from which something would update control values and text blocks

Could you elaborate on this? I'm not sure what an "async meta higher effect" is.

Reading in between the lines though, I suspect you're talking about state management. You might benefit from one of many state management solutions out there - redux, mobx, legend-state etc. Keeping and passing around local state spread out across lots of components can get unwieldy pretty quickly.

State solutions solve a self-imposed problem. With mithril I just do whatever I want cause it doesn't dictate shape or behavior to my data. I don't have to pass it around (except naturally) and event-ize up-and-down, cause it's easily accessible and lives outside of a vnode/element tree. Although data can be put into vnode, if it really belongs to its graphical state which would make no sense in its absence, e.g. current 'uncommitted' value in an input.

benefit from ... Redux

>_< had a good laugh, thanks! I imagine writing a hierarchical reducer every time I have to update x in {a:{b:[...,x,...],c:{{{...}}}}}-like structure. Mobx is close, but in the same "unengineering of overengineering" category.

(Edit: I don't think that parent comment deserves graying out, I'm always happy to elaborate on subj)

There's a whole thing between global state and local states and that usually comes with doing frontend routing on something that should have been an MPA (and maybe powered by something like liveview). React should have been what it was initially designed for, just a UI library for when you need lots of interaction on a single page. But the whole ecosystem is a mess right now.

FWIW, with modern Redux Toolkit you _don't_ write handwritten nested immutable update logic - you write normal "mutating" code in a reducer and it becomes an immutable update thanks to the Immer library:

- https://redux.js.org/tutorials/essentials/part-2-app-structu...

Reply on news.ycombinator.com