Improve ability to check when shopping lists change #3449
Replies: 2 comments
-
Have you looked at our notifiers? You don't need to poll Mealie for changes, Mealie can send out notifications any time a shopping list item is added, updated, deleted, etc. This is how I built my shopping list integration with Alexa and Todoist: https://github.com/michael-genson/Unified-Shopping-List. If you're able to use a subscriber/consumer model I strongly recommend that over a polling model. However, I still agree, the |
Beta Was this translation helpful? Give feedback.
-
The mobile app has to be able to work offline. It allows edits while offline and needs to be able to merge changes when the client comes online. The ability to work offline and to merge changes is a key reason why I wrote the app -- that, and to have a native client. It's a different operating model from an always-on application like an Alexa integration. I do plan on using the pub/sub API, but on an optional side-loaded push notification server. Push notifications are going to be more reliable on mobile than a bespoke pub/sub API -- again, simply because the client is mobile. This won't eliminate the need for the client to compare and merge list contents. |
Beta Was this translation helpful? Give feedback.
-
First Check
Please provide a concise description of the problem that would be addressed by this feature.
In the new API, shopping lists and list summaries have creation and modification times; these attributes only refer to changes to the attributes on the data structures themselves; that is, the modification time is only changed when e.g. the
name
is changed. The modification times are not updated when list contents are changed; this means that it is impossible to tell if a shopping list has substantively changed by looking at alistSummary
. Having a change timestamp on list summaries (and lists) would allow clients to more easily detect when shopping list contents change -- and these are the sorts of changes in which humans are most interested.Please provide a concise description of the feature that would resolve your issue.
Ideally,
updateAt
would be changed when any change to anything in the list'slistItems
happens -- essentially, bubbling-up any change timestamps to the parentlist
andlistSummary
objects. However, the current timestamps are almost certainly a reflection of the serialization of the DBO, and so changing the behavior ofupdateAt
attributes is unlikely. Therefore, I'd like a new attribute added to bothlistSummary
andlist
that is updated when any change is made to a list'slistItems
contents or any item in the list.Please consider and list out some caveats or tradeoffs made in your design decision
In a shopping list, what is most significant to clients is the contents of the list. Changes to the contents -- items being added or removed, or renamed or checked-off -- are going to be the most common and most interesting changes, and it's currently hard to detect these changes: it's impossible from
listSummary
, and requires recursive timestamp checks. Since we're interested in when attributes at the leaves change -- a bottom-up change -- and because list trees are not deep, it should not be intrusive on the server side to update parent objects when their children change.I am currently exclusively concerned about shopping lists; impacts on recipes or other structures have been excluded.
This change would significantly reduce client calls and data transfer for detecting changes interesting to humans.
I'm interested in this feature as the author of an OSS shopping list client that Mealie users can use on mobile devices and while offline.
Additional Information
Beta Was this translation helpful? Give feedback.
All reactions