No, that's not what I meant.
Only the order of the channel IDs specified will be changed
In your example 1, c
has moved as well, even though only d
and b
were given.
To move a channel up or down...
This is equivalent to swapping two adjacent items.
I didn't give an example of setting the order of three items because I couldn't think of a UI where it would make sense, but it is still possible.
The nice thing about this approach is that the same update logic works for all the use cases, and doesn't matter how many items are in the list, and is atomic.
Working on implementing this in together now, I'm sure there is a valid reason, but I'm just wondering why the _id
is different from the paging before and after values, could they not be the same?
The before
and after
values are meant to represent pages of data, not necessarily individual records. In my case, the after
value refers to an item that isn't in the current page. I could return a string for _id
that looks more like the before
and after
strings, but that's just an implementation detail of my server. Alternately I may switch my before
/after
strings to look more like the current _id
value. Either way, this difference doesn't seem important to the client.
Not that it has to be implemented right now, but I do want to make a case for the “updated” field of a channel. In order to reduce “high noise signal”, for most of my channels, I’ll want the channel’s “unread indicator” to disappear when I reach the top of the timeline (even if things are unread). When a channel is updated (receives new posts), I would want to be able to re-enable the unread indicator. Essentially saying “there are new posts here” rather than saying “there are unread posts here”. In fact now that I say it, I might make the indicator a different color as well. That said, the purpose of such a channel is, I want to be able to know what I have and haven’t read, while only being prompted to open the channel if there are new posts. The “new posts” indicator essentially upping the priority of time looking at that channel than one without new posts. That said, when I have more time, to be able to go back to an existing channel and still know what I haven’t read (which is why this can’t just use the “last_read_entry”, even though that is a useful method).
(Originally published at: https://eddiehinkle.com/2018/02/12/7/reply/)
Not that it has to be implemented right now, but I do want to make a case for the “updated” field of a channel. In order to reduce “high noise signal”, for most of my channels, I’ll want the channel’s “unread indicator” to disappear when I reach the top of the timeline (even if things are unread). When a channel is updated (receives new posts), I would want to be able to re-enable the unread indicator. Essentially saying “there are new posts here” rather than saying “there are unread posts here”. In fact now that I say it, I might make the indicator a different color as well. That said, the purpose of such a channel is, I want to be able to know what I have and haven’t read, while only being prompted to open the channel if there are new posts. The “new posts” indicator essentially upping the priority of time looking at that channel than one without new posts. That said, when I have more time, to be able to go back to an existing channel and still know what I haven’t read (which is why this can’t just use the “last_read_entry”, even though that is a useful method).
(Originally published at: https://eddiehinkle.com/2018/02/12/7/reply/)
With the work in tracking read state, I've started implementing these additional properties by prefixing them with _
. I felt like that was the least obtrusive way to include them while also making it obvious they are not part of the post vocabulary.
Additional brainstorming around other per-item data should be discussed in new issues.
The unread
property has been documented in the spec, and implemented in Aperture.
I am not sure the updated
property is useful, so I'm leaving it out for now. I'm going to close this issue as most of the discussion is taking place in #4.