Make a clear distinction between Environments and Variables

[yaugenka]

Mixing Environments and Variables within one list (the Env tag) is quite confusing. There should be a clear distinciton between these entities. Environment is something that you switch between like dev/stage/prod. Variables are placeholder values bound to environments and collections. It would be better to allow creating variables from within collections and environments only and let to flag any variable as secret to prevent it from serialization.

[rangav]

Hi @yaugenka, did not understood your question.

Can you please provide a more details with examples and screenshots

[yaugenka]

Global and Local envrionments are confusing. The former stands for a true global scope environmet while the latter stands for a group of secret variables within global scope environment. The suggestion is to remove local environment and let flag any variable as secret both within global scope and custom environments.

[rangav]

Thanks for the feedback @yaugenka , will review it.

[yaugenka]

Also I guess the initial idea of binding an environment to collection was actually to allow binding a group of collection scope variables, not the custom switchable environments. I think that it is a rare case that a collection scope environment will be shared between different collections, one can just define global variables for that. So instead of binding switchable envrionments to collections it would be better to allow creating collection variables right within collections. Alternatively, there should be a separate collection envrioment menu item in the Env tab; and global, switchable and collection environment lists should be visually clearly distinguished, and then finally it should be possible to bind only collection environments to collections.

[skela]

I actually really think the whole local env / different envs stuff is a stroke of genius. Being able to stick things like API urls in different shared environments, and have things like local login credentials, tokens, etc in the local environment.

I just wish perhaps the local environment was instead a separate Tab called "Session". Being able to have multiple different sessions working in tandem with the environment choice would be awesome, I find myself having to switch to different login credentials to try out different API calls, and its a bit difficult to change username etc that way.

An alternative is to stick a Sessions section inside each environment, that way, the "Local environment" is more tied in with a particular environment. (Still think its important to be able to choose different sessions in a particular environment).

[MelGrubb]

I could be missing something, but my use case for this is much clearer. I have a request that calls to Auth0 to get a token. Because I want to use that token in later requests, I stuff it in an environment variable because I have no other mechanism that I know of to share information between requests. Now I've mutated my thunderEnvironment.json file and Git wants to check it in. It's not so much that I'm checking a token into source control that bothers me since it's going to expire within 24 hours anyway, but any time ANY of the devs on the team run the tests, they'll mutate the same file even though the thing that changed (the token) is only temporary to begin with. I'd really like somewhere to store temporary values that isn't the environment file to cut down on the commit noise if nothing else.

[rangav]

@MelGrubb you can store temporary tokens in Local Environment. did you try that?

[MelGrubb]

I just found that after posting. I don't know how I missed that before. Probably the same say I never noticed the "Sort using drag & drop" before today. How long has THAT been there. I've definitely tried dragging and dropping settings. I guess the key is finding the magic spot between the variable name and the value.

[rangav]

env variables sort is available from 13 July, 2021 https://github.com/rangav/thunder-client-support/releases/tag/1.7.0

[cw1934]

We also have plenty of use cases where we could leverage variables on the Collection in addition to the variables on the Active Environment AND the Local Environment.

As just one example, we have variables that we share among users. This is so we have a known working value that is substituted into multiple requests only within that collection, which changes periodically so we need as few places as possible to update when it is changed. This value would be consistent across all environments. Having it in the Local Environment would hide the value from being seen/used by anyone else on the team, even though it is something that all would need to access.

[cw1934]

I didn't remember(or find) the "Global Environment" when commenting yesterday. I will be trying out global variables today to see if it will meet the need for now. I think it would still be advantageous to have variables scoped at the Collection level, keeping them closer to only the Requests that utilize the variable instead of having it be something that anything could access. Closest I've thought of so far is to use Global variables with a naming convention that indicates the Collection it's intended to be used in/for.

While the above described plan should work....our mindset of collection-based variables is something we leveraged previously, and requires thought on how to reimplement in TC. While I understand that this is a different app, the real issue this presents is that we can't simply just import our Postman file and have it work. We are creating a User Story for each project we try to move from Postman to ThunderClient in order to account for the manual adjustments that need to be made. The smoother the import could be, the quicker our usage of TC will grow; whether it's converting how Postman did it to how TC handles it within the import, or implementing something at the same layer as Postman.

[rangav]

Collection Level Variables are possible using scripting

• To use - open collection settings or request view -> then select Pre Run Tab and use the Scripting tab

  tc.setVar("name", "Thunder Client", "request");
  tc.setVar("baseUrl", "http://localhost:8744", "request");

Docs Link https://docs.thunderclient.com/features/environments