komoot: get the places right, then put them in order
komoot helps hikers and cyclists discover, plan and navigate outdoor routes. Its web planner brings map locations and waypoint order together, so a plan can be adjusted before heading out.
Break down the problem and try your own design and implementation first. Then explore the reasoning to check states, edge cases, trade-offs, and ways to test your approach. The guide offers a reasoning path, not a complete implementation.
01
CODE EXERCISE
Reorder a route and undo changes
Implement a reorder-and-undo module for a route editor. After several changes to waypoint order, users should be able to undo those changes in reverse order.
- Initial data: Initialize the module with ["S","W","V","E"], representing Station, Water stop, Viewpoint and Exit. The module owns its state and must not modify the supplied array. Every subsequent order is guaranteed to be a complete permutation of these four distinct IDs. This exercise allows the start and finish to be reordered too; input validation is out of scope.
- Operations: Provide reorder(nextIds), undo() and snapshot(). Each returns a copy of the current order. reorder saves the previous order before adopting a new one; if the order is unchanged, it adds no undo record. undo restores and removes the most recent undo record; with no records, it leaves the order unchanged. Modifying any returned array must not change internal state.
- Acceptance: Starting from the initial order, call reorder([S,V,W,E]), repeat the same call, then call reorder([S,W,E,V]). The results are [S,V,W,E], [S,V,W,E] and [S,W,E,V]. Three successive undo calls must return [S,V,W,E], [S,W,V,E] and [S,W,V,E]. Change the first item of one snapshot to X; another snapshot must still return [S,W,V,E].
- Deliverable: Implement the module in a language you know, run the sequence above, and explain who owns the current order and history. Work only with local IDs: no map drawing, route calculation, redo or persistence across reloads.
Explore the reasoning
- Make the module own both current order and history, with outside access through the three operations. Consider how shared array references could corrupt saved records.
- Decide what to save before each real change and how to retrieve the latest record during undo. An identical order should not consume another undo step.
- Trace the two effective reorders and three undo calls. Then modify a returned array to confirm that outside code cannot change internal state.