Really interesting. Thank you.

・ Totally agreed! Tools like GraphQL helps hide away these complex stuff that we had to build. I wished tooling was as mature when we started. Actually, I wished operation queues were part of the web platform. ・ Firebase also does queue write operations automatically, for both Realtime Database (no support for persistence on the web) and Firestore (has persistence but multiple tabs are unsupported). ・ Lee Byron also presented a very similar concept, called “Immutable App Architecture” back in 2016. This talk didn’t build upon it though, as we independently came up with a solution, and “immutable” doesn’t really represent the notion of having write queues. ・ I just knew about the BroadcastChannel API today; wasn’t aware that it exists. Thanks for sharing! ・ BroadcastChannel API is not natively supported in Internet Explorer 11. ;_; ・ But a polyfill exists! (which falls back to IndexedDB and eventually localStorage) :D.

Lol

🤣

That won't solve any problem here. As the problem isn't asynchronous action. The problem is a data race between different clients

・ Yep, Observables can simplify the code a lot, especially in the first example. In RxJS, debouncing is just `debounceTime`, and discarding non-latest result is just `switchMap`. ・ Many “make an autocomplete using RxJS” tutorials would end at `switchMap`, but as discussed in the talk, the experience is not optimal. ・ For discarding results that arrive out of order, I couldn’t think of an elegant solution in RxJS yet. How would you implement that with Observables?

@@dtinth I haven't checked, but I think this should work: const latestMap = (selector) => pipe( mergeMap((input, index) => pipe( selector, map((value) => ({ value, index })), )), mergeScan((last, { value, index }) => !last || index > last.index ? of(value) : EMPTY ), map((item) => item.value), ); Now, that's not exactly elegant, but it is at least fairly explicit about the behavior and is factoring away the gory bits from the rest of the app. That said, I've never been that impressed by the operators rxjs has, the tend to be overly fiddly for direct use. I'm far more enamored with the idea of observables and operators as a way of clearly factoring your apps.

@@SimonBuchanNz Thanks for the code example. I think it looks pretty good, at least better than how I’d write it myself! I just learned that `mergeScan` exists today. I have the same sentiment towards observable… I really like the idea of observables and use them as well, but when it comes to practice: ・ The API surface of RxJS is large and requires a shift in mental model, which can sometimes make onboarding new developers harder. (That’s why I did not use observables/RxJS in the talk, also to make a point that although tools help, most of the time attention to detail is enough.) ・ Even with a large API surface, we still can’t express “ignore out-of-order responses” concisely. Then we have to choose either to always inline it (write the same thing every time) or create a new operator (like `latestMap` as your comment), which means more project-specific API on top of already large API of RxJS.

then it wouldn't be optimistic UI