Different screens should not invent saving again
Consolidate common mechanics without hiding important domain differences.
When the project growsAbout 2 min read
Each version made sense in its own conversation
A profile screen, an application editor and an opportunity reader may be built weeks apart. Each can acquire a different request wrapper, retry rule or save scheduler. The differences become visible when the connection fails or the person keeps editing.
My Next Step’s connection handling distinguishes a connection failure from an advert that cannot be interpreted. Its save-scheduling work also deals with keyed saves and repeated acknowledgements. These are small mechanisms with consequences for what the person believes happened.
Compare before creating a shared helper
Put several flows side by side: what starts a request, how it is cancelled, how failures are classified, which draft survives and when a success belongs to the latest edit. Extract the mechanics that truly have the same contract.
Keep domain decisions explicit. Retrying a read is different from retrying an operation that creates work or consumes credits. A common network helper should not quietly turn every failure into the same message or every retry into the same policy.
Keep the consolidation bounded
Choose a small family of flows and specify what must remain unchanged. Check disconnection, edits during saving, navigation away and return. Look for removed duplication and for any meaning that the abstraction has hidden.
The aim is less behaviour to relearn, for both the person using the app and the person maintaining it. A helper that needs many exceptions may be drawing the boundary in the wrong place.