This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-11-06
Channels
- # bangalore-clj (16)
- # beginners (120)
- # boot (21)
- # cider (24)
- # clara (9)
- # cljs-experience (1)
- # cljsrn (1)
- # clojure (218)
- # clojure-dev (3)
- # clojure-italy (12)
- # clojure-losangeles (4)
- # clojure-norway (2)
- # clojure-russia (2)
- # clojure-spec (19)
- # clojure-uk (178)
- # clojurescript (52)
- # cursive (7)
- # data-science (55)
- # datomic (25)
- # defnpodcast (11)
- # emacs (5)
- # fulcro (27)
- # hoplon (2)
- # leiningen (14)
- # midje (9)
- # off-topic (132)
- # onyx (19)
- # other-languages (23)
- # portkey (2)
- # re-frame (31)
- # reagent (1)
- # ring-swagger (15)
- # shadow-cljs (58)
- # slack-help (13)
- # spacemacs (22)
- # sql (7)
- # test-check (13)
@brunex thats a known issue you can turn off those warnings by setting compiler option :closure-warnings {:global-this :off}
How do people handle cancelable actions? Consider this flow of events: - user clicks on "get product A" - the server takes a while to return this result - while the server is busy, the user gets annoyed and clicks on "get product B" - the request B finishes, but then request A also finishes In this contrived example, the clunky user experience may be acceptable, but it's easy to imagine scenarios where this is not ok. In those scenarios, you'd want to make sure that only one action of type "request X" is active at the same time.
I just have the client know what it is waiting for from the server. If the client changes its mind, it ignores what the server sends. Your product A might arrive but the site does nothing with it while it waits for B.
right, but how do you have the client ignore the result, in practice?
perhaps i don't understand the full context of the question, but when it comes in i might first look at what it is, if it's what I want, i might call another function or put something on a core.async channel, and if it isn't, it's a no-op, just return nil from the function that is doing the receiving (my receiving functions are typically for side effects only anyway)
What patterns do people use to cancel ongoing actions, in general and in particular with re-frame?
purelyfunctional on 'interceptor' https://purelyfunctional.tv/guide/re-frame-building-blocks/#interceptors
@lovuikeng I think if they request B, that means they expect to see B next, not A
They don’t care about the fact that there is an async event loop in the background, or that multiple concurrent requests can coexist
@pesterhazy that's one of the challenges of optimistic updates that I'd like to address in my content
So what options do I have?
I could use XhrIo’s ability to cancel the request
queueing up the messages to the server
so "select A" sends to the server, then "select B"
instead of both firing at the same time
Some sort of abstraction over a server “connection”?
they're serialized on the client and the server, so "select B" will win in a last write wins system
I'd use a core.async channel or something similar
all messages get sent through that
and the next message waits until the previous one is finished
Right, a queue would help
there's still the issue of dealing with the failed messages
it might depend on your UI
Yeah sounds like we need a design pattern here
i'd say in your use case, the user selected
or active
product always takes precedence over the incoming
product from data channel
I've added a start-expanded?
argument to single-dropdown
component of my local copy of re-com
for the cases where I show such dropdown in a pop-up.
An interesting thing - if I set drop-showing?
to the value of start-expanded?
when the component is created, the change of focus will cause the viewport scroll like crazy.
But if I reset drop-showing?
to true inside a js/startTimeout
with 0 timeout, the focus is changed correctly, but the viewport is not scrolled.
Any ideas why this happens?
Maybe there's some better approach to display an opened dropdown inside a pop-up?
How do people implement side-effects that are dependent on each other? i.e. side-effect A must run and then give the result to side-effect B. 1. Write A and B as independent effects, have A dispatch to B 2. Write a combined effect for A+B 3. Something else? In cases where B must be configurable, I’ve see code that passes in handlers as events https://github.com/Day8/re-frame-http-fx#step-3-handlers-for-on-success-and-on-failure However, I’ve also seen this pattern when side-effect B does not need to change. I’m wondering if anyone has experience with the tradeoffs here.
AFAICT, if B has it’s own event/effect, then it’s easier to trace it with standard re-frame tools, but it adds two layers of indirection that can hamper readability (you can’t understand what the effect handler of A will do just by reading it)