Numeric Values in RadioGroupItem

[mfbayraktar]

Hi,
When numeric values used to populate value map of radiogroupitem, Smart GWT does not respect the insertion order of the values which causes an unexpected result on UI.
This issue mentioned in previous years, and provided solution seems to be using optionDataSource as mentioned in RadioGroupItem sorts the value Map according to the Keys in value map - SmartClient Forums
However RadioGroupItem also does not seem to work with optionDataSource which is also mentioned before in RadioGroupItem optionDataSource - SmartClient Forums

I would like to learn the officially suggested solution of this problem?

[Isomorphic]

The previously suggested official solution remains the official solution. Note that it is quite easy to apply, as you can just use a clientOnly DataSource.

[mfbayraktar]

The problem is that optionDataSource with client only datasource does not work with radiogroupitem. So how it can be the solution?

[Isomorphic]

Sorry for the delay on this. The only solution is to make the value keys non-numeric, that is, use "1A", "2A" etc instead of 1, 2, etc.

The underlying problem is that JavaScript Objects respect key order unless the key can be parsed as a number. This was a very, very stupid behavior change introduced in Chrome some years ago, as an "optimization".

If we did not use JavaScript Object for things like valueMaps, and instead used a more complex structure, everything would slow way down. So we are all stuck with this niggle, thanks to Chrome's decision.

[mfbayraktar]

Thank you for the answer. I want to note couple of things.

It's important to clarify that this isn't solely a "Chrome problem.". It is specified under ECMAScript(The standard upon which JavaScript is built.) that javascript object will disregard insertion order of the key/value items if keys are numeric.

Anyhow, it is also important I think to pinpoint why this error exist in Smart GWT. As someone who has delved into the JavaScript world, I would argue absolutely zero javascript developer would use or implement this in the way Smart GWT implemented. The main problem here stems from the conceptual differences in how data structures are often handled in Java versus JavaScript, and SmartGWT must reconcile these two languages in its transformation process.

As an example in javascript world no one would write a value map like this:

const valueMap = {
"1": "First Option",
"2": "Second Option",
"3": "Third Option"
};

Instead the following pattern is the most natural in javascript language:

const options = [
{ value: 1, label: "First Option" },
{ value: 2, label: "Second Option" },
{ value: 3, label: "Third Option" }
];

[Isomorphic]

Sorry, you are quite incorrect about the history here - we'll explain.

Prior to Chrome making this change, all browsers maintained propertyName order, and this had been the case for more than 10 years.

When Chrome implemented this change as an "optimization", thousands of sites broke, including parts of Facebook, among many other prominent sites.

The JavaScript spec, at the time, did not say anything about whether insertion order should be preserved or not. That was changed later, after the Chrome team effectively forced the spec to conform to their implementation.

It is not at all "natural" to use the second, far more verbose format. In other languages, such as Python and Ruby, Object literals preserve order, and this is very useful. And if you had asked any JavaScript developer to represent a valueMap before Chrome's change, of course they would have used the simpler format.

Finally, JavaScript's new behavior - preserving key order for string keys, but not preserving it for keys that happen to be parsable as an integer - is bizarre and inconsistent. No other mainstream programming language does this.

So, you are working around the Chrome team's decision to add a weird quirk to the JavaScript language, because they were excited to add an optimization that could have been achieved without damaging the language, but they just didn't want to bother.

That's what this really is.