Move it on screen first, save it after
Dragging a dish up the menu did nothing you could see, then redrew the whole page a second later — and a second drag during that second confused it. Three complaints, one cause: every move waited for the server. The row now moves the instant you drop it, and the resulting order is what gets saved.
The review came as three complaints. Moving items around did not move them straight away. Items would not move up and down inside their section, only sections moved. And moving a section took a second to update — if you moved something else during that second, it got confused. Three symptoms, and when we read the code they had one cause.
Waiting for the server to draw
Every move on that screen sent its change to the server, waited for the answer, then threw the whole page away and fetched it again. That is the simplest possible code and it is why nothing moved straight away: the row you dragged stayed where it was until the round trip came back and the page was rebuilt. It is also why a second move mid-way confused things — it landed on a page that was half-way through being replaced, and its save raced the first one.
And dishes did not move up and down within a section for the plainest reason: nothing stored an order. Every menu — the guest's phone, the till, the back office — sorted a section's dishes alphabetically. There was no position to move to.
The order is the thing you save
Dishes now have a place in their section, and every menu reads it, so the order you arrange in the office is the order a guest scrolls and the order a till shows. The screen moves the row the instant you drop it — or press the small arrows beside it, because a finger on a tablet has no drag — and then saves the resulting order, not the gesture. A row is a target: drop on its top half to go before it, its bottom half to go after. Drop on the section itself and the dish goes to the end of it.
Latest order wins
Saving after the fact needs one more rule. If you make three moves in two seconds, the server should not receive three saves that might land out of order. While one save is in flight, later orders replace each other and only the newest is sent when it lands; an order identical to the last one saved is not sent at all; a failed save is reported and does not wedge the ones behind it. That arithmetic — move by one, place before or after, are these two orders the same — lives in a small module with its own tests, because it is the kind of logic that looks obvious and is wrong in an edge case nobody drags into.
Sections moved the same way from the same night. Nothing on that screen waits for the server any more; the server catches up with what you did.