views.get_stats returns data in an old format about zing HOT 5 CLOSED

@julen please have a look into this.

from zing.

Quick update: I've looked through this today, and making the returned stats a list is straightforward.

But there is a caveat. The client needs to merge the new stats data with existing UI data (there are some properties which are irrelevant to stats and are not part of the /xhr/stats/ payload), and this exhibits a mismatch in the ordering of the children elements that have been provided. The effect is that stats are updated, but the displayed data is incorrect because merging happens for items which are not in the same order. I tried to sort all children elements as returned by all users of TreeItem, and while it works, it quickly becomes unwieldy and I would prefer not to resource to this.

Another option I'm thinking about would be to make /xhr/stats/ return the entire UI properties as returned to templates. This would include extra properties which are irrelevant when stats are dirty (e.g. pootlePath, itemType...), so the response payload is unnecessarily bigger. It also requires some extra plumbing to be able to return exactly the same data as in browsing views.

from zing.

I'd just return exactly the same format of data as we do in browsing views. This should ideally simplify the code and help in the future to get rid of browser page reloads. That'd be step one.

Step two is an ability to get short patch updates (in the future, via websockets), so we will need a mechanism to push partial data for specific keys.

from zing.

Okay, I'll try to match the format we use in browsing views. We'll need to have some plumbing code to be able to get all the context-relevant data. At the same time, I'm thinking that this won't be stats anymore, but rather something like browsing data, so we should probably rename /xhr/stats/ to something more relevant.

from zing.

Agree on renaming this to browsing data.

from zing.