[New Feature]: Convert to configurable code action

[malinthar]

Description

Consider the following code.

import ballerina/lang.array;
import ballerinax/googleapis.drive;
import ballerinax/googleapis.sheets;
import ballerinax/openai.images;

string googleAccessToken = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2V4YW1wbGUu";
string openAIToken = "i8vYXBpLmV4YW1wbGUuY29tL2NhbGFuZGFyL3YxLyIsInN1OjE";
string sheetId = "id";
string sheetName = "name";
string gDriveFolderId = "id";

public function main() returns error? {
    sheets:Client gSheets = check new ({auth: {token: googleAccessToken}});
    images:Client openAIImages = check new ({auth: {token: openAIToken}});
    drive:Client gDrive = check new ({auth: {token: googleAccessToken}});

    sheets:Column range = check gSheets->getColumn(sheetId, sheetName, "A");
    foreach var cell in range.values {
        string prompt = cell.toString();
        images:CreateImageRequest imagePrompt = {
            prompt,
            response_format: "b64_json"
        };
        images:ImagesResponse imageRes = check openAIImages->/images/generations.post(imagePrompt);
        string? encodedImage = imageRes.data[0].b64_json;
        if encodedImage is () {
            return error(string `Failed to generate image for prompt: ${prompt}`);
        }

        // Decode the Base64 string and store image in Google Drive
        byte[] imageBytes = check array:fromBase64(encodedImage);
        _ = check gDrive->uploadFileUsingByteArray(imageBytes, string `${cell}.png`, gDriveFolderId);
    }
}

In the code above I have used module variables to define secrets. A new code action to convert them to configurables would be useful.

The code action should add the secrets to the Config.toml file while converting the module vars to configurable variables.

Describe your problem(s)

No response

Describe your solution(s)

No response

Related area

-> Editor

Related issue(s) (optional)

No response

Suggested label(s) (optional)

No response

Suggested assignee(s) (optional)

No response

[nipunayf]

Upon the execution of the code action, we should provide two options to capture the user preference:

1. Whether the user wants the value as a default value.
2. Whether the user wants to move the value to the Config.toml.

[LakshanWeerasinghe]

To make this feature complete we need to implement three code actions.

1. Convert to configurable code action

The code action targets a module variable defined in the source code. The cursor must be placed within the literal expression of the variable user want to convert. Then it transforms the variable declaration by adding the configurable keyword.
Before Applying the Code Action:

string githubPAT = "this-is-my-fake-github-pat";

After Applying the Code Action:

configurable string githubPAT = "this-is-my-fake-github-pat";

2. Extract to configurable code action
This code action can be broken into two parts.

• Extract a single literal value
  This part functions similarly to the "extract to local variable" code action. When a single literal value is selected, the user will be prompted with a rename popup to update the configurable variable name.
  Before Applying the Code Action:

final mysql:Client myDb = check new ("<CURSOR>localhost", "my_user", "dummy_password", "dummy_database");

After Applying the Code Action:

configurable string configurableVar = "localhost";
final mysql:Client myDb = check new (configurableVar, "my_user", "dummy_password", "dummy_database");

• Extract a Selected Range of Function Arguments into Configurable Variables
  In this part, all arguments within the selected cursor range will be extracted into configurable variables. The names of these configurable variables will be derived from the function parameter names.
  Before Applying the Code Action:

final mysql:Client myDb2 = check new (<CURSOR_START>"localhost", "my_user", "dummy_password", "dummy_database"<CURSOR_END>);

After Applying the Code Action:

configurable string host = "localhost";
configurable string username = "my_user";
configurable string password = "dummy_password";
configurable string database = "dummy_database";
final mysql:Client myDb2 = check new (host, username, password, database);

3. Add Configurable to Config.toml

This code action will perform the following functions:

• Add Missing Configurables: It checks for the presence of required configurables in the Config.toml file. If any configurables are missing, it adds them to the file.
• Create Config.toml if Absent: If the Config.toml file does not exist, this code action creates a new Config.toml file and adds the required configurables to it.

[LakshanWeerasinghe]

After an offline discussion with @KavinduZoysa, we came to a conclusion to support Convert to configurable code action only for these expression syntax kinds BOOLEAN_LITERAL, NUMERIC_LITERAL, STRING_LITERAL, MAPPING_CONSTRCUTOR and LIST_CONSTRUCTOR_EXPRESSION.

[MaryamZi]

After an offline discussion with @KavinduZoysa, we came to a conclusion to support Convert to configurable code action only for these expression syntax kinds BOOLEAN_LITERAL, NUMERIC_LITERAL, STRING_LITERAL, MAPPING_CONSTRCUTOR and LIST_CONSTRUCTOR_EXPRESSION.

Any particular reason to support only these? I think it would be useful to have the support also (at least) for unary expressions (e.g., -1 is a unary expression), string template expressions, table constructor expressions, etc.

Technically we could support this with anything that has a static type belonging to anydata, right? I get that it may not make sense for all such expression though - e.g., is checks - and in such cases it can be a bit of a distraction.

[LakshanWeerasinghe]

After an offline discussion with @KavinduZoysa, we came to a conclusion to support Convert to configurable code action only for these expression syntax kinds BOOLEAN_LITERAL, NUMERIC_LITERAL, STRING_LITERAL, MAPPING_CONSTRCUTOR and LIST_CONSTRUCTOR_EXPRESSION.

Any particular reason to support only these? I think it would be useful to have the support also (at least) for unary expressions (e.g., -1 is a unary expression), string template expressions, table constructor expressions, etc.

Technically we could support this with anything that has a static type belonging to anydata, right? I get that it may not make sense for all such expression though - e.g., is checks - and in such cases it can be a bit of a distraction.

One reason to suggest only above syntax kinds was others won't make any sense. As you mentioned we can add UNARY_EXPRESSION, STRING_TEMPLATE_EXPRESSION, XML_TEMPLATE_EXPRESSION and TABLE_CONSTRUCTOR_EXPRESSOION.