Thanks God, I thought I was alone thinking about these kind of edge cases where in most tutorials they act like there's nothing to worry about.
@tusharf55 жыл бұрын
This presentation is so amazing and talks about some very practical scenarios. Amazing! Very informative.
@platoh5 жыл бұрын
Great examples, clear visuals and explanations. Props to the speaker for the way they structured the presentation.
@gauthamstalin5 жыл бұрын
One of the best presentation I have ever seen. This video needs more appreciation. The presenter had pointed out very practical issue which many people simply ignore or don't even realize that it exists.
@dtinth3 жыл бұрын
Hello, Thai (speaker) here. Thanks all for watching my talk and for your comments, I really appreciate it! 💚 If you’re interested in seeing more content from me, please feel free to check out my channel. 😅
@TheBitterlove2 жыл бұрын
Even in 2022. This is still relevant. Nice presentation.
@isaachagoel73445 жыл бұрын
Well presented and thought provoking. Nice work!
@binary645 жыл бұрын
This is what makes GraphQL so exciting, is the possibility of having most of this automatically scaffolded for you. I'm thinking www.apollographql.com/docs/react/features/optimistic-ui/ plus the local storage caching layer on top. As for the inter-tab elections, you can also use BroadcastChannel API and just have the oldest tab win (I also send it a ping, to check it's alive!)
@siwatkaolueng68715 жыл бұрын
Really interesting. Thank you.
@dtinth5 жыл бұрын
・ 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.
@SelomAMOUZOU4 жыл бұрын
Great presentation!
@MegaGrinbull5 жыл бұрын
Great talk.
@user-zb4ev2mq4j4 жыл бұрын
nice explanation and demonstration!! like
@WhateverYouLove5 жыл бұрын
Alright, that does it for me. I'll start using .then() instead of await. :-)
@mmghv5 жыл бұрын
Lol
@dtinth3 жыл бұрын
🤣
@arttioz5 жыл бұрын
Very Good Presentation
@AdityaFingerstyle5 жыл бұрын
Very well presented. Thank you
@RonaldFelix5 жыл бұрын
Is this the next Dan Abramov?
@ekaterinazakharenkova80252 жыл бұрын
Why we cant use sessionStorage? In this case each tab will have its own storage.
@ErnestGWilsonII5 жыл бұрын
Great job @dtinth
@tuscala2 жыл бұрын
Thank you
@user-ii9rb6hk4c5 жыл бұрын
use Observables, Luke
@IceQub35 жыл бұрын
That won't solve any problem here. As the problem isn't asynchronous action. The problem is a data race between different clients
@dtinth5 жыл бұрын
・ 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?
@SimonBuchanNz5 жыл бұрын
@@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.
@dtinth5 жыл бұрын
@@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.
@oneminutefriend.5 жыл бұрын
await on my thoughts
@GiveMeAnOKUsername5 жыл бұрын
Why not update only on success? Or if there’s an error, scrub all changes that came after it.