Save/Autosave feature discussion & roadmap

[animator]

Relevant issues:

• Remove the "Save" modal #474
• Add keyboard shortcut for the "Save" action #475
• An autosave on close? #993

Autosave exists to eliminate cognitive overhead and data loss while preserving developer trust. It ensures that every meaningful change in API Dash is captured reliably - without forcing users to think about manually saving, or recovery.

Currently, users have to manually Save in API Dash. If they close the application, they are prompted to Save using a dialog. but, it is still a hassle. The reason why autosave is currently not possible in each and every change is because the entire collection state has to be saved every time which makes it slow, inefficient and not scalable.

Hence, to make this feature work:

• Collection provider has to be changed to not load the entire data in memory and update for every change. But, to load and change only the request data when the user clicks on it.
• For any change the request data can be saved instantaneously in the filesystem/hive and manual Save feature can be removed.

[ShashwatXD]

What i understand on this:
Architecture Change: Move from a “Load All / Save All” model to a “Lazy Load / Granular Save” model.

Lazy Loading: Initially load only the list of request IDs. Load the full Request model only when the user selects a request.

Granular Persistence: When a user edits a request (name, URL, headers, etc.), we trigger a save only for that specific request ID to the storage layer (e.g. Hive), instead of re-serializing the entire collection.

Autosave Safety & Performance:
Once the above aree in place, persistence becomes an O(1) operation, since each change results in a single, bounded write for the active request, independent of the total collection size.

[ShashwatXD]

@animator, should i start with the implementation? Is their anything more this should cover?