7 ms·

You are over complicating things. UI state should live in the client. Having the server maintain it is not only more complex but will also introduce a latency.

by rafale 6y ago

You are over complicating things. UI state should live in the client. Having the server maintain it is not only more complex but will also introduce a latency. Let's say I click a button to delete an item in the list. The button state goes to pressed, list loses focus, button takes focus, button unpressed, delete animation starts on deleted item, translation animations on the other items to slide into its place, new items devirtualized if the list is too long,... Now that's 1 user input. Imagine multiple consecutive input like mouse scroll. Or drag-and-drop. Only state shared between multiple clients should go to the server.

jiriknesl 6y ago
"UI state should live in the client." this is wrong and I think you have missed the point of the article. In server-rendered app, there's nothing like UI state. There's a request. This request and the database is enough to build response. There is no UI state. Your app can be (and often is) absolutely stateless and restult depends only on request and a state of the storage. While when you have SPA, API & server, you lose the application state and it's not possible to store the whole app state in the client for many reasons (security, scalability, synchronisation...). So you have to store subset of it. And you have to build a machinery that will do all this synchronization so your states stay in sync. It's double the effort to get 5% improvement.
- pier25 6y ago
  > In server-rendered app, there's nothing like UI state. Of course there is. For example, any state related to interactivity like forms, client-side validation, widgets, filters, etc.
  - jiriknesl 6y ago
    All these things can be set up declaratively on the render time and managed through Ajax/socket. Local state is voluntary here.
    - pier25 6y ago
      So when using a drag-and-drop widget you're going to be waiting for server responses at every step of the way?
juskrey 6y ago
The way to eliminate latency with server side state is called optimistic updates.
- mathgladiator 6y ago
  This is a next step for my project as I'm trying to figure out how to generalize client side predictions in a sane way. Basically, I'm happy with my latency (for board games) which I hope to migrate closer to people as more edge compute offerings emerge. However, I'm wondering what the path is to find some of these ideas in more latency sensitive applications. The explanation for how the net-code behind Overwatch is a good explanation: https://www.youtube.com/watch?v=W3aieHjyNvw https://www.youtube.com/watch?v=W3aieHjyNvw and I'm just trying to figure out how to build the reactive tree in a way to support it sanely.
  - juskrey 6y ago
    You don't have to predict. Requests just fall into two categories: 1) Nothing bad can happen if we show some optimistic result before server returns, but server side will end up in different result. 2) Something bad can happen. Accordingly, for (1) we can do optimistic update, for (2) can't
  - Fire-Dragon-DoL 6y ago
    Consider that while a videogame runs on 60fps (or more), a board game runs on frame-per-turn. You would be doing what overwatch is doing in a frame, for an entire turn. That's way easier: if a turn is out of sync, revert to the previous one!
mathgladiator 6y ago
The server isn't maintaining the UI state in my model. Instead, the server is maintaining a single document, and the entire UI view is then predictable based on that. Think about the nature of a document store, you put data in and data out. You gain concurrency by using compare and set such that multiple requests can compete, but this is expensive. First, you risk conflicts which require re-execution for the losers. Second, you must download the entire object, make a change, then write the entire object back. The key to what I am doing is that I'm having the language take a message from a durable queue, integrate that message into the document via some code, then emitting a state change out. The client then subscribes to the document's parts to updates its UI state, and as the document changes, so does the UI. The UI can be much more complicated while the server can be beautifully simple.

by rafale 6y ago

jiriknesl 6y ago

"UI state should live in the client." this is wrong and I think you have missed the point of the article. In server-rendered app, there's nothing like UI state. There's a request. This request and the database is enough to build response. There is no UI state. Your app can be (and often is) absolutely stateless and restult depends only on request and a state of the storage. While when you have SPA, API & server, you lose the application state and it's not possible to store the whole app state in the client for many reasons (security, scalability, synchronisation...). So you have to store subset of it. And you have to build a machinery that will do all this synchronization so your states stay in sync. It's double the effort to get 5% improvement.

pier25 6y ago
> In server-rendered app, there's nothing like UI state. Of course there is. For example, any state related to interactivity like forms, client-side validation, widgets, filters, etc.
- jiriknesl 6y ago
  All these things can be set up declaratively on the render time and managed through Ajax/socket. Local state is voluntary here.
  - pier25 6y ago
    So when using a drag-and-drop widget you're going to be waiting for server responses at every step of the way?

juskrey 6y ago

The way to eliminate latency with server side state is called optimistic updates.

mathgladiator 6y ago
This is a next step for my project as I'm trying to figure out how to generalize client side predictions in a sane way. Basically, I'm happy with my latency (for board games) which I hope to migrate closer to people as more edge compute offerings emerge. However, I'm wondering what the path is to find some of these ideas in more latency sensitive applications. The explanation for how the net-code behind Overwatch is a good explanation: https://www.youtube.com/watch?v=W3aieHjyNvw https://www.youtube.com/watch?v=W3aieHjyNvw and I'm just trying to figure out how to build the reactive tree in a way to support it sanely.
- juskrey 6y ago
  You don't have to predict. Requests just fall into two categories: 1) Nothing bad can happen if we show some optimistic result before server returns, but server side will end up in different result. 2) Something bad can happen. Accordingly, for (1) we can do optimistic update, for (2) can't
- Fire-Dragon-DoL 6y ago
  Consider that while a videogame runs on 60fps (or more), a board game runs on frame-per-turn. You would be doing what overwatch is doing in a frame, for an entire turn. That's way easier: if a turn is out of sync, revert to the previous one!

mathgladiator 6y ago

The server isn't maintaining the UI state in my model. Instead, the server is maintaining a single document, and the entire UI view is then predictable based on that. Think about the nature of a document store, you put data in and data out. You gain concurrency by using compare and set such that multiple requests can compete, but this is expensive. First, you risk conflicts which require re-execution for the losers. Second, you must download the entire object, make a change, then write the entire object back. The key to what I am doing is that I'm having the language take a message from a durable queue, integrate that message into the document via some code, then emitting a state change out. The client then subscribes to the document's parts to updates its UI state, and as the document changes, so does the UI. The UI can be much more complicated while the server can be beautifully simple.