Comment by verelo | Hacker News Reader

Comment by verelo | Hacker News Reader

Parent Full thread

Ok so this is topical for me right now. I somehow managed to avoid the world of react since it became a thing. All the code i was writing was pre react and we kept the old frameworks, and that’s was all good and well.

Fast forward to today, i took over a project that is full react. What a mental shift. Having said that, sometimes i love it, sometimes i hate it. A friend put it best when he said “i struggle to predict what might be trivial and what will take a full day or two”, and that’s my experience too.

I found myself just the other day wishing i could await the setting of a state variable, it was making saving a file in a complicated form a little difficult. I found a work around but i don’t love it and i know the next time i come back to work on it I’ll be scratching my head at what i was trying to achieve and why i did it this way. Naturally i over commented my rational here.

I do miss writing in basic js and server side code, it’s probably slower over all, but i do miss it for the simple things being predictably simply and the hard things typically being predictably hard.

You don't need any of it. You can write vanilla JS, using ES6 classes, as web components and be done with the whole front-end framework game. All you need for data-binding is an Observable of some kind that can loop through listeners for events and call their handler. Component classes all have a render function so that React kids feel at home. Those components are registered using CustomElementRegistry.define [1]. Tools like vite help roll up all that code and styles into a minified bundle but doesn't include all the crap that these "modern" frameworks add. Take this from someone who has been writing web sites since 1996. You don't need any of those frameworks unless you're looking to give away control of your product to the roadmap of the framework or need to hire a bunch of people to accomplish something quickly and all they know is React.

[1] https://developer.mozilla.org/en-US/docs/Web/API/CustomEleme...

I'm assuming that someone who "took over a React project" isn't trying to remove all the react from the project. They did mention they found both up and downsides compared to their old work.

Didn’t know about this API, very cool! Could you point me toward a repo that implements this style?

https://angular.io/guide/elements

someone should write up some documentation for the standard APIs and how to use them but then give the website a name. People would think of it as the next amazing and shiny JS framework but, in reality, it's no framework at all just a name. That would be good medicine for the front-end dev community.

er, so is the advice here to write your own framework instead of using a framework? because writing and maintaining your own framework is not a trivial exercise and is a massive project on its own, which is why a lot of people reach for a framework in the first place...

> You don't need any of those frameworks unless you're looking to give away control of your product to the roadmap of the framework

Have... Have you seen the roadmap for web components? 20 more specs just to barely patch holes in the original design: https://w3c.github.io/webcomponents-cg/2022.html

Not sure if this is what you settled on, but I'd just initialize the state variable as null and then put it into the dependencies of a useEffect that fires when the variable is set

It’s a mix of that. This introduced a race condition and a frustrating rendering experience, but yeah it’s a flavour of this.

I realize this is unsolicited advice, however this sounds like you're hitting the "DOM has an imperative API but React is declarative" barrier, because React (until `use` ships at least) has no way to just await reactive values, you can:

if sufficiently complex, you may want to look into `useSyncExternalStore`[0] which can be used to store and update state (IE maintaining UI reactivity) in a microcosm.

Otherwise, I'd recommend framing it as a series of dispatch-able steps, which maps well to `useReducer`[1] possibly in combination with `useEffect`

[0]: https://react.dev/reference/react/useSyncExternalStore

[1]: https://react.dev/reference/react/useReducer

> I found myself just the other day wishing i could await the setting of a state variable, it was making saving a file in a complicated form a little difficult.

It used to be that React.setState would accept a callback function to fire after the state was set.

The newer setter function returned by useState doesn't have that anymore I'm pretty sure. Tbh I've never tried though.

if you need to await a setState call, you're prob structuring your logic in a less-than-efficient way. in whatever handler is calling setState, you should compute the next state in the handler, setState(nextState), then use that nextState for whatever comes next.

I don’t know, i agree it wasn’t in the react style but it was in the style of basic logic

On change detect new file is there, Set file to variable, Call api to save state.

The issue is setting the variable and calling save is now a race condition.

Reply on news.ycombinator.com