iris
cae04c2559
Pressing Delete refetched the whole list on success, so every other row went back through its loading state and the reader got a blank screen for the length of a round trip -- to report on something that was never in doubt. Now the row being deleted fades, says so where its status goes, and stops responding to taps; when the server answers, that one row is removed and nothing else moves. A refusal keeps the row, because it is still there: the server answered and said no, so the session it said no about is exactly as it was, and the error goes on its own card as it already did. Faded rather than removed on the way out, deliberately. Taking the row away when Delete is pressed is a promise about a request that has not been answered, and putting it back when the server refuses is worse than never having taken it away. Looked at rather than reasoned about: the in-flight state lasts milliseconds against a local server, so I slowed the delete route to four seconds, watched the faded row and its spinner, watched it removed on success, then killed the server and watched a refusal leave the row in place with the reason on it.