I need to show a refreshable/searchable list of items and update/add-to it whenever an event is published. How do I make sure no events are lost while refreshing/searching is happening?

Some sort of event buffering and locking the list on search/refresh comes to mind, but I am wondering if there is a common reactive lockless pattern.

In other words how do I do push instead of pull on a list of items that might change for non-event-driven reasons?

  • My current idea is to mix the command results into the feed of events. – Den Nov 26 '15 at 18:42
  • For the app that I work on, the initial load and any subsequent refresh both mean "go ask the server for the full list as of right now, and subscribe to all subsequent updates". Any events that show up during the refresh are correctly ignored (as they're from the old subscription). So, what is it about your use case that makes it incorrect to ignore those mid-refresh events? And since it's probably related, how do you retrieve the full list the first time around and on refresh? – Ixrec Nov 26 '15 at 18:54
  • Why do you want a lockless pattern? It seems, from your description, that there is a great desire to have your object have one official state at any point in time, but lockless algorithms tend to rely on making that distinction more fuzzy. Also, by the word "show," is this a GUI? This would also affect the desire for lockless. Most of the solutions I have seen for what you are looking for involve a "feed of events" as you say. The official name for that activity is "journaling." – Cort Ammon - Reinstate Monica Nov 26 '15 at 19:03
  • @Ixrec there is a chance that some events will be published after the query run on server but before the client receives it. Initial load is done same way as refresh, so it has the same problem. – Den Nov 27 '15 at 9:11
  • @CortAmmon I probably misused the word "lockless". What I meant is that I would like to handle this in a RX-idiomatic way. Yes, it's a GUI. – Den Nov 27 '15 at 9:15