Change variable's current value about vscode-httpyac

[AnWeber]

To set variables, you can simply add them inline right before the request (see https://httpyac.github.io/guide/variables.html#inline-variables).

@foo=bar
GET https://httpbin.org/anything?q={{foo}}

Or alternatively you could import an .env file, Intellij Idea format or variables from a central http file. It would also be possible to fill them dynamically.
I have not yet planned to change the cached variables. These can be not only text, but also any file types or even special classes (e.g. Date or HMAC). This makes it more complicated and I don't see the benefit so strongly, because there are enough alternatives.

[klutzer]

The alternative to import env/http files I'm already using but when I set some variable using a script after some response, I can't change the current value again just changing the imported file. Even so, I can go with your first solution.

Nevertheless, if we could change the variable inside the extension's Variables section could be a nice/simple way to improve user experience, at least for primitive variable types.

[AnWeber]

@klutzer How would you solve the data problem here? I could then only allow the input of text, since VSCode otherwise does not provide me with any controls see https://code.visualstudio.com/api/references/vscode-api#InputBox). Alternatively, only JSON would work, but this would complicate the input of simple text.

[klutzer]

I don't know if this is a viable option, but maybe we can able user to put some arbitrary JS code and set the variable the same way you do in @myVariable = {{ some JS here }}

[klutzer]

Another thing I've noticed, is that if I change some environment variable (first defined in .env) in one .http file, the new value isn't applied for other files using the same variable. Shouldn't environment values be global scoped by default? Or the only way to reflect a variable change in all files is using $global?

[AnWeber]

@klutzer The behavior could be a bug. I have a certain order for loading the variables (default > config (file or vscode) > env > cached variables > variables) and it can happen that the variable from the environment is overwritten afterwards. The object displayed as variables in VSCode is not used directly at all, but is only the result of the last execution. I try to separate the variables pots (environement or variable of httpregion). Your description indicates an error in the separation and an example of the error would be interesting.
This is also the reason why manual changing from the outside is also complicated to implement. To determine to which pot the variable belongs is not trivial but necessary that this overwrites the variable at the next execution.

[klutzer]

Yep, changing variables from the UI isn't so trivial indeed.

An example of the environment variable behavior:

.env:

host = http://httpbin.org
source = envFile

file1.http:

### first
POST /anything
{
  "source": "{{source}}"
}
@source = file1
?? body json.source == envFile


### second
POST /anything
{
  "source": "{{source}}"
}
?? body json.source == file1

file2.http

### third
POST /anything
{
  "source": "{{source}}"
}
?? body json.source == file1

To simulate just execute the requests in order (first, second..). In my understanding, the third should pass instead of fail.

[AnWeber]

@klutzer I do not have global variables. The environment is global. The variables are always present only in the respective httpRegion. Since this approach was too strict for myself, the variables are leaking in the same file (useRegionScopedVariables = false). To access variables from other files, this file must be imported, and if necessary also the respective HttpRegion.
To override the source variable, I now need to determine that it was created in file1.http - first.

The whole approach is driven by test execution. My goal was that the execution is reproducible and automatable. Your requirement is important during the development of the request that you can easily change the call. In this case I simply adjust the request body directly or try to avoid variables and use multiple requests. I want to focus on the development of the backend and miinimize the cognitive load for tooling.

[klutzer]

In this case, knowing that environment is global, when I change the env (setting new value to env source), the new value shouldn't be reflected globally?

For variables (defined in .http files), you're using a nice approach indeed. The only thing here is, even importing the same variable file in file1 and file2, file2 will still receive the same value, without the change made in first request, so we have the same behavior of using envs.

I know this can be undesired, I'm just raising some possibilities to have envs similar to extensions like ThunderClient, where we have global envs as default, and an initial and current values for each.