Allow switching sub-environment inside Manage Environment modal

[cobwebsonsale]

Closes #2761

• Added a button next to the sub-environment name to activate it
• Added a filled button next to the current active sub-environment
• Added helpful text in tooltips
• Renamed occurrences of activeEnvironment to selectedEnvironment in WorkspaceEnvironmentsEditModal (to avoid confusion) -- separated in another commit, for easier review/revert.

Caveat:
Could not re-render the currently selected environment in the right-pane after activation, so showing the activated environment instead. The re-render only makes sense when Base Environment is selected, as a different active environment changes the validations on variables. Tried:

• calling _load,
• adding activeEnvironmentId to state inside WorkspaceEnvironmentsEditModal and setting state, and
• deriving activeEnvironmentId from activeWorkspaceMeta in Wrapper, as that is what gets updated in handleChangeEnvironment

Demo:

[develohpanda]

Wow, thanks a lot for tackling this @cobwebsonsale! 🤗

[CLAassistant]

All committers have signed the CLA.

[cobwebsonsale]

Requesting a review here.

[develohpanda]

I'm sorry about the mega delays @cobwebsonsale 😞 I'll try to at least give a prelim review this this week

[develohpanda]

Thank you for the PR, QA'd locally and seems to be working as intended, and thanks for splitting up your work into individual commits which made the rename and feature easier to review. 🙌🏽

My apologies for the delays. Unfortunately the team is spread quite thin at the moment, evident by the sheer number of open-source PRs we need to get through. We currently have a code-freeze in place for migrating to typescript, but once that is done I'll come back to this PR to merge it.

[cobwebsonsale]

seems to be working as intended

Nice, that's good to know.

And no worries about the delay. I want to contribute to help, not to add stress. xD So please take your time and merge this accordingly. Bumped only so it stays on the radar.

Let me know when you come around to this and there are conflicts, I'm surprised there weren't already.

[develohpanda]

Sounds good 👍🏽

This is a note to myself to double-check the caveat you describe above and whether that's a concern right now; with the testing done so far it seemed to be fine

[dimitropoulos]

I updated this branch for TypeScript: it seems to be working well -

https://github.com/dimitropoulos/insomnia/commits/feature/switch-env-ts

The first commit is yours (please let me know if I messed up anything on the revival) and the second commit is to fix some TypeScript errors now that we're actually using types for react-sortable-hoc.

Please take a look. If everything is ok, I can push that branch to this one and update this PR, at which point we should be ready (or nearly ready) to go.

[develohpanda]

@dimitropoulos having 2286466 (#2891) and d1c4ae2 (#2891) separate certainly was helpful in processing this PR, but if that's tricky to retain it's okay. I briefly checked your branch and dimitropoulos@c5eff8a looks correct.

Please push those changes up to cobwebsonsale:feature/switch-env and we'll run through another code-review and QA round.

[dimitropoulos]

@develohpanda sure, I un-squashed the rename and pushed to the PR's branch.

[develohpanda]

Alright, double checked again and it looks good to me

Could not re-render the currently selected environment in the right-pane after activation, so showing the activated environment instead. The re-render only makes sense when Base Environment is selected, as a different active environment changes the validations on variables.

I worked through this caveat you described; it's interesting that the re-render doesn't occur but when hovering over a template tag in the base environment the sub environment in that tooltip does change but the resolved value does not. This leads me to believe there must be a bug somewhere and that it should work automatically.

Regardless, I still think what you have is fine for this iteration. 🎉

[develohpanda]

Removal of this await actually shows a bug where Wrapper._handleChangeEnvironment function swallows a promise. It should be awaited correctly so we don't proceed to delete an environment until the change is complete.

Can be handled separate to this PR

[reynolek]

Product perspective: Good addition, once merged we should probably do a design pass but that doesnt have to happen right now.