allow multiple values in query strings

[AnnMarieW]

This pull request allows for multiple values in query strings to be passed to the layout function.

For example, this URL has 2 values for indi:

http://127.0.0.1:8050/chart?com=AAA&indi=sma-50&indi=sma-200

The following is now passed to the layout function. Note that the value for indi is a list

{'com': 'AAA', 'indi': ['sma-50', 'sma-200']}

Previously, only the first value was included:

{'com': 'AAA', 'indi': 'sma-50'}

[alexcjohnson]

What's the use case for json loading the value here? And in particular, do we need to json.loads each item, if we have a list at this point?

[AnnMarieW]

@chriddyp can you answer this question about the use-case for json.loads?

[chriddyp]

JSON parsing - to bring number strings into numbers and allow human readable booleans (true, false)

[AnnMarieW]

Sorry, @chriddyp I don't understand your answer - could you elaborate?

[chriddyp]

Example: ?weekends=false&start=5. If we don't JSON parse, then the dev would get literally the strings 'false' and '5'. By JSON parsing, the dev will get False (a Python boolean) and 5 (a number)

[AnnMarieW]

@alexcjohnson should we also use this with the path variables for consistency?

If so, should the default path when using a path_template be "/dasboard/null" rather than "/dashboard/none" ?

[chriddyp]

"False", "True" and "None" remain as strings.

Oh true, good point. That feels a bit confusing, I could imagine that we convert those to the Python types as well

[AnnMarieW]

After giving this a little more thought, I think it might be better to keep data as strings. For example, not all string numbers should be converted to int or float. What if the number was part of a 3 digit string id? "?id=010" would be converted as a string {"id": "010"} but "?id=100" would be converted as an int {"id": 100} .

Plus there are other keywords that would convert that people might not expect -- such as "NaN" and "Infinity"

[alexcjohnson]

Right, I'm starting to think the same - with all the questions about JS vs Python keywords, and now @AnnMarieW's point about numeric strings that aren't numbers, automatically converting just seems too ambiguous and confusing.

For path variables we could adopt Flask's convention of <converter:name>, but unless we can think of a good place to specify similar converters for query parameters I'm leaning toward leaving them as strings.

[AnnMarieW]

@chriddyp Is this good to go now? I removed the json.loads.

[chriddyp]

💃🏼

[AnnMarieW]

Yippee - Thanks!