mavo
mavo copied to clipboard
mavoweb
Should mv-order actually affect data?
Right now, if mv-order="desc", this does not just affect the UI, but also things like $next and $previous, and where in the actual data new items are appended. A collection cannot really be edited as top-down, then switch to bottom-up, then back to top-down, it will mess up the order of items entirely.
I think mv-order should be entirely presentational, so that it can be added and removed with no harm to the data, and $next and $previous always have their semantic meaning, and are not affected by presentational order. In the rare case where items do need to be stored in reverse, authors can always specify a transformation.
However, since this is a breaking change, we should probably find different syntax for it, so that the current syntax can be deprecated and auto-migrated. Any ideas?
Just to make sure that I get everything correctly.
Suppose I have a collection of blog posts. I plan to add new posts to the top of the collection so that the new ones come earlier (as readers expect). So, to achieve my goal, I decided to add my-order="desc" to the collection of blog posts.
<div mv-list="blogpost" mv-order="desc">
<article>...</article>
</div>
For now, blogposts are rendered and stored the way I expect (from newest to latest).
With the new syntax to achieve the same result, should I use the Sort plugin? Or are we planning to render collections according to the value of the new attribute (e.g., mv-list-order), not the order they are stored?
I.e., will this code
<div mv-list="blogpost" mv-list-order="desc">
<article>...</article>
</div>
produce the same result even though blogposts are stored in the opposite order?
I.e., will this code
<div mv-list="blogpost" mv-list-order="desc"> <article>...</article> </div>produce the same result even though
blogposts are stored in the opposite order?
Yes, that's the idea.
That’s great. Thanks!
I have another thought. It might be just me, but when I see either asc or desc I think of sorting and its order. However, previously, we meant something a bit different. That’s why we had to explain in the docs the way we understand the mv-order attribute.
To my mind, the fact that mv-order affects the behavior of the controls that add new items is the consequence of the way we render a collection. That’s why I think it would make sense if we could reflect via an attribute whether we need to render a collection in reversed order or not. So, I suggest adding a new attribute to collections: mv-list-reversed or mv-order-reversed. We could also introduce mv-list-order="reversed". However, I’m not sure whether there will be other values for this attribute. 🤔
To clarify, I think it should still affect what controls do. The end result would be identical. It just shouldn't affect the actual data, expressions, $index etc. @karger, thoughts? I seem to recall we discussed this a month or two ago, but it was not here and I can't find that discussion.
I agree that the previous syntax looked like it was performing sorting. Something to avoid with the new syntax.
To clarify, I think it should still affect what controls do.
Absolutely! I’m not against it at all. :)
I seem to recall we discussed this a month or two ago, but it was not here and I can't find that discussion.
It's in our group on FB. See August, 4th (and later). TIL we can search in the conversation in the app on iPhone. :)
@DmitrySharabin can you port the discussion here if that's not too much trouble?
From our FB group
David
what is a bottom-up collection?
why not just implement a slice method. slice(foo.all,0,$index)
I think having a large collection of functions that do all sorts of things works very well in the spreadsheet setting, so I think that would work well with mavo too
Lea
what is a bottom-up collection?
A collection where new items are prepended instead of appended and the add new button is before it
David isn't there some kind of order attribute that indicates that? I seem to recall.
Lea
yes
e.g. this one from the demos has this: https://mavo.io/demos/talks/
mv-order="desc"
David i see; you're earlier question was whether the order is imposed on the data itself (ie storage order) or just on the presentation of the data (ui order)
Lea Yes
David for most of our mavo authors i don't think it really matters. either way, switching the parity of the order property will reverse the order of what they see. the programmer in my intuits that by default you should be adding to the end of the collection, which would suggest making order affect the UI but not the data model.
Lea
the programmer in my intuits that by default you should be adding to the…
Agreed, and also if everything adds to the end of the collection then you can switch between bottom-up and top-down without data corruption. The problem is what to do with existing data. But if we change the syntax as well, that won't be a problem, as then we can detect the old syntax and transform the data ourselves.
David I don't think data corruption happens either way.
Lea how so? with the current behavior, if you switch to a top-down collection from a bottom-up collection your data will be in the reverse order and there's no way to fix it either
David "be in the reverse order" is not well defined here. reverse from what?
Lea the reverse order from the one you want
David if i start with an add-to-bottom collection (i'm not sure if that's top down or bottom up) and add items 1...7 then 7 will be at the bottom in the data model. if i then switch to add-to-top and add item 8 then the stored data will be 8,1..7. Is that "corrupt"? why?
Lea yes, that's what I meant by corrupt because presumably, the 1..7 order meant something
David but what else would I want? I don't want 8 after 7
Lea and 8, 1...7 breaks that what? why? you do want 1 ... 8
David if i wanted 1..8 i wouldn't have switched from add-to-bottom to add-to-top
Lea but add-to-top is a UI choice, not a data choice!!
David i was naming the data choice, not the ui choice
Lea to make it less abstract, you have a list of entries with dates. New entries have newer dates than older entries. If you switch, now the data breaks this ordering
David that will be true either way i think. but I have to organize what I'm thinking. ok, i think i can articulate this now. there are two characteristics the author should be able to manage in their collection: (i) is the presentation order same or reverse as database order and (ii) are items added at the beginning or end (by default) these are independent choices---2 distinct attributes are needed where there is ambiguity is what "beginning" and "end" mean in the second attribute
Lea 2 distinct attributes are needed only if there are use cases for both
David
does "beginning" refer to beginning of presentation or beginning of data?
if you have a collection with mv-presentation-order="same as data" and mv-addition-position="beginning" and then you switch to mv-presentation-order="reverse of data" then where is data added?
Lea this is getting too complicated
David
it's clear that if you flip the mv-addition-position attribute then you will start adding at the opposite end. but if you switch mv-presentation-order then it is defensible to add in the same place or in the opposite place
this is getting too complicated
i think it was always this complicated but now we are describing the complication 🙂
Lea I think you are introducing complication that is unnecessary. WHY would the order of the data matter? if it's the same, you can always change how it's displayed
David it doesn't matter in the same way big-endian vs. little-endian doesn't matter. which is to say, it doesn't matter at all but it still demands a lot of attention. i do think we need both attributes. e.g., someone may be collecting data chronologically, and suddenly decide they want to see latest first instead of latest last. i suppose that is the more important attribute, and you could hope that nobody ever changes their mind about whether they want to add at beginning versus end. in which case you could get away with just the order attribute, and if you want to add at the beginning, you would initially specify the order to be reversed.
Lea
i do think we need both attributes. e.g., someone may be collecting dat…
if they do, they can change the presentation of the data, why do they need to control the order in the data as well?
David i think your implicit argument is that people will never want to change the addition order; ie that an item should always be added immediately next to the previously added item. i will see if i can come up with a counterexample.
Lea you can always add an item anywhere, this is about the order of the default controls
David i should have said "never want to change the default addition order
Lea no, my point was that they usually don't need to change it in the data if they can change it in the UI I think the cases where they need to change it in the data are so niche that they are served fine by custom code
David nothing we are discussing involves "changing it in the data". No change in attributes is suddenly going to cause the data to be written back in reverse order from how it was read.
Lea I mean the cases where they want to enforce that order in the data as well
David i think we agree that there has to be an attribute for saying whether you want to order the display with last-added item at top or at bottom. Once you have that attribute, there is a question of whether you need a second attribute to control where the next item gets added. the vast majority of the time, you'll want to add the next item adjacent to the most-recently added item. that is, if you are putting most recently added last, you will want to add the next item at the end. and vice versa. but are there cases where you might want to change your mind about where you add, without reversing the order of the already-extant data?
Lea if you load data from the remote you don't necessarily know what the most recently added item is
David i was using most-recently added to make clear what i was tallking about. not saying that the attribute describes in those terms
Lea so you are saying there should be an attribute to control UI addition order, and another to reverse the data pre-saving/post-load?
David I think you do need both if you want to cover all possible situations. the question is if some situations are so rare that you don't need to bother covering them.
Lea well, having an attribute to reverse makes it very easy to implement rewriting from the old syntax it would just add that attribute oh no, wait, it needs to add that attribute when loading, but not when saving, otherwise no change
David so here's one thing to consider: if mavo is used to access data produced by a different system, that system may have made its own decision about collection ordering. for example, the data might be stored from newest to oldest while mavo generally stores that data from oldest to newest. if mavo only has one of the two attributes i discussed, I don't mavo will be able to default-add items to the right place in the collection.
Lea yes, I understand the theoretical point, but are there real use cases?
David for mavo to use a collection that came from a non-mavo source? Only everything tarfah's been doing with shapir! 🙂
Lea Mavo can use such a collection just fine regardless this does not affect uneditable data in any way until Tarfah's tool can actually write, it's not a real use case
David it's only uneditable for the moment because tarfah hasn't implemented writing back yet. yesterday I told her to talk to you about that 🙂 but i agree that if we are only talking about data that mavo both reads and writes, then you can probably get away with a single attribute, because it is unlikely for anyone to change their mind about which end of the collection they want to add on to. even if they do change their mind about which order they want to display the collection in.