View Model data mapping: JSON.parse inconsistency

[BrentH-Alnico]

Hi Boris,

When VM data is mapped, I was expecting to convert a JSON string of this form:
"HasVoted_list": "[{\"GUID\": \"51564165FA8149864D6D216391EAC4BB\", \"VoteState\": 1}]"
But, it is automatically parsed to valid array of objects...nice ;-)

However, if we apply that same logic to a JSON string of this form:
"IsHost_list": "[\"2273DC25C55777CD8BF22300E4D9E279\"]"
It is not parsed to a valid array...it remains unchanged.

Is this intentional or by design?

You can find this line of code (valid array) in the file I previously sent you, if you want to test:
"IsHost_list": ["2273DC25C55777CD8BF22300E4D9E279"]

Thanks,
Brent

UPDATE:

I think I am wrong on this...this worked with v15 but is an issue with candidates not refreshing I think...
I think I've got myself confused? ;-)

[BrentH-Alnico]

Ok, this issue still stands after testing jsviews16 Candidate C...I guess I wasn't confused ;-)

Here is a jsfiddle showing the two scenarios https://jsfiddle.net/alnico/Loceskwu/

I can use extend IsHost_list to override/transform "IsHost_list": "[\"2273DC25C55777CD8BF22300E4D9E279\"]"
...but wasn't expecting to since
"HasVoted_list": "[{\"GUID\": \"51564165FA8149864D6D216391EAC4BB\", \"VoteState\": 1}]"
...parses fine.

extend: {
   IsHost_list: function() {
      return JSON.parse(this._IsHost_list);
   }
}

[BorisMoore]

Thanks Brent. I'm looking into it. Thanks for the jsfiddle...

[BorisMoore]

Hi Brent, can you test this in your environment? Thanks!

jsviews16 Candidate D.js.txt

[BrentH-Alnico]

Awesome! That works Boris...Thanks

---

This got me thinking about something similar I did a long time ago attempting to initialize data using plain objects/arrays...
Of course it's ideal to have data in good form when passing to the link/render method...but I have found initializing data on the fly in a couple of scenarios to be ~easier~...there's always tradeoffs ;-)

Converters work well for use on an individual tags, but initializing is a one-time process that affect all 'other' following... links to that data.

I've done something like this for plain objects/arrays:
Depending on template, may need one or more such initialization tags...

{{include ~initData("checkedIDs", checkedIDs) /}} Initialize data
...tags using checkedIDs...

$.views.helpers({
  initData: function(propName, data) {
    if (typeof data === "string") { // Transform data on first use
      $.observable(this.data).setProperty(propName, JSON.parse(data));
    }
  }
})

I don't think there's any room for improvement here, just sharing.

---

Thankfully I have no other issues to report...thanks for all the fixes Boris!

Best,
Brent

[BorisMoore]

Hi Brent,
Yes, that is an interesting approach. Thanks for sharing....

I'm glad that (for now at least :-) ...! ) we have fixed those outstanding bugs. I'll write to you separately on email, concerning current status, and moving forward from there...

[BorisMoore]

Hi Brent, this is an update (candidate E for v1.0.16), which includes a fix for #469.

Can you check that it works for you? Thanks.

jsviews16 Candidate E.js.txt

[BrentH-Alnico]

I missed getting the notification about this update...
I've tested candidate E for v1.0.16, everything seems to be working fine for me.

[BorisMoore]

Ah, thanks Brent. In fact Erik found an issue in the candidate E, for which I just uploaded a fix for .

The update (candidate F) is here: jsviews16 Candidate F.js.txt

Sorry to give you another update to test !!

[BrentH-Alnico]

Strange, I did not get email notifications for your last two posts...not in Trash either...

candidate F is working fine for me.

[BorisMoore]

Yes, that's strange. I have no idea why the notification didn't function. But no problem!!! Thanks for testing...