…eorder

Collection ID can be inferred from request ID by removing last index from the path.

…ewRequest` type

Collection ID serves the purpose.

…ns performed over it

Ensure the entire collection tree is rendered if the search query matches a collection name.

Only the IDs (workspace, provider & request IDs) to restore the handle are stored under `localStorage` and the handle is restored back at runtime.

…erences

A special list of writable handles is compiled in a list while issuing handles (request/collection creation, etc). Instead of manually computing the tab and toggling the dirty state, the writable handle is updated (changing the type to invalid on request deletion) and the tab with the request open can infer it via the update reflected in the request handle under the tab save context (reactive update trigger).

…st` method

Wrap the request handle data in a `ref` and make the writable handle operate over it ensuring reactive updates are received.

…move action

…esolution

…r collection move/reorder actions

…collections to be based on request handles

…time

Remove provider, workspace and request IDs.

… handles

Mark the tab (saved request under a collection) as not dirty if the request contents are reset to the value since previous save.

- Filter out duplicate issued handle entries.
- Move from `getAffectedIndexes` helper function to a custom implementation for updating affected request indices.

…etion

…deletion

…lection below it

Ensure child collections are created instead of the action resulting in new root collections.

- Increase test coverage.
- Move store mock data under `__tests__/__mocks__`.
- Rephrase test descriptions.