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.
iris
cae04c2559