-
-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changed the processing of Additional JSON #149
Changed the processing of Additional JSON #149
Conversation
…bles and JSON parse after that, so variables can be also used as non-string type in the JSON
I'll try to run this in my project ASAP (tmrw I hope). Thanks for patience! |
I tried with string-type variable as { "IncludeFilteredOutItems": $stringVar } which produces { "IncludeFilteredOutItems": stringvalue } resulting in incorrect json |
string variables still need to be added as strings, so I think that shouldn't be a problem. So for non-string types you can use: { "IncludeFilteredOutItems": $nonStringVar } and for string types you can use: { "IncludeFilteredOutItems": "$stringVar" } |
I'd prefer universal solution so you don't need to take into account what type of value is in variable. Also the type of the value might be dynamic, eg. when loading value from another data source. Not sure if it's doable though. I guess we might start by parametrising the test allowing us to test multiple type variations easily. Definitely need tests for
|
I did some testing based on your feedback and found the following: By having a universal solution:
|
I personally think that giving the control to the users isn't necessarily a bad thing. Users should know what type of their variables are and if not, they could always just use them as string: So
In my opinion it would also be more clear/transparent how the variable substitution works. |
Hm, the issue seems more complex. See https://grafana.com/docs/grafana/latest/variables/syntax/#variable-syntax where they say
So for example we should not consider supporting Also, if you check their docs So for your use case, I'd first try to discuss with Grafana if it makes sense to implement something like |
I think there might be some misinterpretation here. The doc says indeed that
I didn't find any reference for that either:
Also at this moment their variable interpolation works with both string, number, boolean, etc out of the box, the only thing prevents it from working is the code in this repo parsing the data input into JSON before doing the variable interpolation.
Even if that change would be made (while there is no need for it), the plugin code still wouldn't make it possible to use it at this moment since the JSON parsing would still fail due to the current code setup. So if the built in variable interpolation supports using non string variables, I don't see why this change wouldn't comply with Grafana standards. |
So the issue is that piece of code: GrafanaJsonDatasource/src/DataSource.ts Lines 162 to 170 in 3ad7ac6
While with the change proposed:
|
Aight, let's ship it. It does not break any tests (I'll have to look into them anyway, it's kind of mess in my opinion :) ) and you have a point. This is step forward. Thank you! 🚢 |
Thank you too! |
I'll put this in my production by the end of this week and next week I'd release it. |
So it first parses the variables and only after that parses the data as JSON, so variables can also be used as non-string type in the JSON.
Solving #148