Comment by bcherny | Hacker News Reader

Comment by bcherny | Hacker News Reader

Parent Full thread

Author here.

Data fetching, caching, consistency, and UX are all closely related. If you treat them as separate problems, you're punting the problem onto product engineers, who won't solve it well. (See the last paragraph of the post, which suggests this same idea.)

> That is state management, yeah, and you can build proper state management with any HTTP library and any message serialisation format.

You're right that to do this manually it's just state management. But to automatically update the UI, it means your client data layer (eg. Apollo) needs to know & track the identity of fields; the data layer also needs to be able to subscribe to fetches anywhere in your app, not local fetches; it also means your protocol needs to support this identity (via agreed-upon ID fields); etc. These problems are all closely related.

> Request batching: How would that happen "automatically"? By waiting to fire requests and then batching them?

eg. Relay does this by statically combining requests throughout a React tree into a single request at the top of the tree. You could also do it dynamically, as you suggest. The tradeoff is often performance.

> UX when fetching data

Having engineers manually define loading states doesn't scale. React is approaching this problem with Suspense, and you could imagine standard loading states when fetches are in flight.

State management, for anybody half competent, is stupid easy and not tied to the UI. State management is a data storage/retrieval problem only. Once the UI has the state information it needs you can populate it for the user however you want in many different ways.

State management is also proclaimed as something it isn’t because web UI is full of incompetent expert beginners who can’t write two lines of original code and are helplessly mortified if their colossal framework is taken away.

Here is simple web UI state management:

* have a centrally available object in the UI code that stores state data.

* store that data upon change. That storage can be localStorage for maximum simplicity. It can also be a locally written file if you have a local running service or an http server. The further away from the local computer that storage location becomes the slower it is regardless of access mechanism.

* state changes can occur from user interaction or system updates to remote data. Most important are user interactions because that data is locally available. Keep up with remote system changes as best you can, but unless you own that data as well it’s a window into some distant concern.

* when state changes update your central state object save the changed state object. Most of the time UI developers are only concerned with state updates and not saving state because they don’t know what they are doing and hope the framework does everything (or it must obviously be unnecessary).

* once the state object is updated, and optionally saved, update the UI. For most UI developers updating the UI is the ultimate and only struggle. This is such a junior level basic required skill for UI developers. Knowing that you can root out the incompetent people during hiring.

But but but what about 2 way data binding... Treat it as an event. Update the central state store. Process the change. Still simple and no framework is needed.

Oh,dear. Little too much redux koolaid, eh?

I'm curious about your approach to making UIs. Are there any libraries you do use?

Do you use anything to render your view or do you construct the nodes and insert them into the DOM directly?

Is your centrally available object an instance of a class or is it a plain JavaScript object?

Does it manage the state for all your UI or is it segmented in some way?

How do you drive changes to your UI? Is there an imperative process that renders the UI when you know the data model has changed or is your state object an observable or something that your views subscribe to?

I use the ws library for web sockets.

The state object is just a regular JavaScript object. I prefer to avoid classes as they increase complexity for almost no substantive benefit.

Changes to the UI are handled as events whether those events are from user interactions, HTTP responses, or web socket data events.

I update the DOM using old school DOM methods and some custom DOM methods I have written to do things the standards do not provide.

This stuff that people cry tears of blood over is easy and very basic. I really think the bane of evil is addEventListener allowing multiple handlers for the same events which allows laziness and super increased complexity.

What’s more challenging is writing test automation that executes in the browser and coordinates between browsers of different computers.

Would the stuff you have on Github be a fair representation of your ideal way of writing a web UI?

Try this: https://github.com/prettydiff/share-file-systems/tree/tests

It is a complete GUI with full state management and the browser part of the application is very tiny.

I had a look through that alright. Do you code in that style in work?

I have been away from my primary employer for about a year and they are HUGE with many different teams that do many different things in many different ways. I just try to gel to the team and not be disruptive.

Reply on news.ycombinator.com