feat: replace builtin variables in string

[shahrokni]

Description 🖊️

A dataLink may include built-in variables. Ideally all variables could be placed in the dataLink.
So far, the function which has been responsible for the variable replacement has not covered the built-in variables.
This change finds the built-in variables in a string and replace them with their respective values.

The new regex covers the built-in variables

Checklist

• Pull request has a descriptive title and context useful to a reviewer.
• Pull request title follows the [<catalog_entry>] <commit message> naming convention using one of the
  following catalog_entry values: FEATURE, ENHANCEMENT, BUGFIX, BREAKINGCHANGE, DOC,IGNORE.
• All commits have DCO signoffs.

UI Changes

• Changes that impact the UI include screenshots and/or screencasts of the relevant changes.
• Code follows the UI guidelines.
• E2E tests are stable and unlikely to be flaky.
  See e2e docs for more details. Common issues include:
  • Is the data inconsistent? You need to mock API requests.
  • Does the time change? You need to use consistent time values or mock time utilities.
  • Does it have loading states? You need to wait for loading to complete.

[jgbernalp]

this will assume that variable names containing __ are not possible or are mistaken by builtIn variables. something__not__built_in

[shahrokni]

Sorry I didn't get this comment.
Could you make a realistic example?

A custom variable will be found and replaced with the following patterns

• $var
• ${var}

It seems built-in variables always start with __

{
    "builtin": {
        "__from": {
            "loading": false,
            "value": "1768229967725"
        },
        "__to": {
            "loading": false,
            "value": "1768233567725"
        },
        /* some others */
    }   
}

Am I missing something?

[jgbernalp]

this validation will take this as a builtIn variable something__not__a__built__in__variable

[jgbernalp]

Suggested change

	const VARIABLE_REGEX = /\$(\w+)|\${(\w+)(?:\.([^:^}]+))?(?::([^}]+))?}|__(\w+)/gm;
	const VARIABLE_REGEX = /\$(\w+)|\${(\w+)(?:\.([^:^}]+))?(?::([^}]+))?}|^__(\w+)/gm;

[jgbernalp]

instead of casting each value we could add the correct type to the const

[jgbernalp]

aren't the built in variables in the format $__<variable>? meaning they will be already covered in __<variable> as the match is $(\w+)

[shahrokni]

I think Built-in variables (which start with __ ) should be placed directly into a string. (As long as I understood)
I am checking other dashboarding applications, and if I am not mistaken they are suggesting we should be able to put the built-in variables directly into a dataLink.

Please take a look at this and let me know if it makes sense

https://grafana.com/docs/grafana/latest/visualizations/panels-visualizations/configure-data-links/

This test specifically

This test simply checks if it is possible to have a custom variable, identical to a built-in one

[jgbernalp]

IIUC, when they are searched on text, either queries or links. all the variables have the format $<variable> or ${<variable>}. Built in variables fall into the first format $__<built-in-variable>