3 ms·

A bit of a tangent: I have been experimenting with replacing REST style backend interaction with websockets an having the state manipulation round-tripping thr

by geon 11y ago

A bit of a tangent: I have been experimenting with replacing REST style backend interaction with websockets an having the state manipulation round-tripping through the server. Instead of setting values on mutable objects and telling the server about it postfact (having to deal with errors like ba validation and connectivity somehow), I would send a change command to the server, which would decide what to do, and push an updated state back. Once I detect this change of state, I update the UI. This simplifies error handling a lot, since the user simply can't update state if an error occurs. And I get cuncurrent multi user editing for free. Unless you want offline editing (which is hard), it's a big win.

wereHamster 11y ago
That introduces a noticeable delay. It's acceptable in some situations but in others less so. Having immediate feedback on button press or text entry makes the UX much more pleasant.
- rhia 11y ago
  This is still rather easy. You can change the UI (i.e. set the button into a "Loading..." state) directly after the click and when the server sends back the response act accordingly. An error would reset the button and prompt an error message.
  - geon 11y ago
    Exactly. The difference is, this becomes the default behavior (minus the spinner), and simple to implement. With rest, it would be a much more manually implemented feature. The default would be to just fail silently and potentially drop important data on the next page load.
mlangenberg 11y ago
I'm not sure if this is good API design, but it definitely sounds like a fun thing to try. I'll keep it in mind for a personal project. Edit: Actually when you pass all state as props, this will even apply to typing in a textarea. Better make sure the roundtrip is pretty short!
- geon 11y ago
  I let the textarea take care o itself. I hate when they try to change the text while I type. The update wouldn't be sent until it is unfocused or possibly after a set delay after the last keypress.

by geon 11y ago

wereHamster 11y ago

That introduces a noticeable delay. It's acceptable in some situations but in others less so. Having immediate feedback on button press or text entry makes the UX much more pleasant.

rhia 11y ago
This is still rather easy. You can change the UI (i.e. set the button into a "Loading..." state) directly after the click and when the server sends back the response act accordingly. An error would reset the button and prompt an error message.
- geon 11y ago
  Exactly. The difference is, this becomes the default behavior (minus the spinner), and simple to implement. With rest, it would be a much more manually implemented feature. The default would be to just fail silently and potentially drop important data on the next page load.

mlangenberg 11y ago

I'm not sure if this is good API design, but it definitely sounds like a fun thing to try. I'll keep it in mind for a personal project. Edit: Actually when you pass all state as props, this will even apply to typing in a textarea. Better make sure the roundtrip is pretty short!

geon 11y ago
I let the textarea take care o itself. I hate when they try to change the text while I type. The update wouldn't be sent until it is unfocused or possibly after a set delay after the last keypress.