Fork me on GitHub
#re-frame
<
2017-11-06
>
thheller10:11:14

@brunex thats a known issue you can turn off those warnings by setting compiler option :closure-warnings {:global-this :off}

pesterhazy12:11:20

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.

ajs00:11:30

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.

pesterhazy10:11:37

right, but how do you have the client ignore the result, in practice?

ajs11:11:57

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)

pesterhazy12:11:54

What patterns do people use to cancel ongoing actions, in general and in particular with re-frame?

lovuikeng12:11:43

but then we don't really know of the intension of user to cancel product a or b

pesterhazy12:11:06

@lovuikeng I think if they request B, that means they expect to see B next, not A

pesterhazy12:11:09

They don’t care about the fact that there is an async event loop in the background, or that multiple concurrent requests can coexist

ericnormand13:11:02

@pesterhazy that's one of the challenges of optimistic updates that I'd like to address in my content

pesterhazy13:11:48

So what options do I have?

pesterhazy13:11:31

I could use XhrIo’s ability to cancel the request

ericnormand13:11:58

queueing up the messages to the server

ericnormand13:11:18

so "select A" sends to the server, then "select B"

ericnormand13:11:24

instead of both firing at the same time

pesterhazy13:11:56

Some sort of abstraction over a server “connection”?

ericnormand13:11:10

they're serialized on the client and the server, so "select B" will win in a last write wins system

ericnormand13:11:31

I'd use a core.async channel or something similar

ericnormand13:11:43

all messages get sent through that

ericnormand13:11:06

and the next message waits until the previous one is finished

pesterhazy13:11:22

Right, a queue would help

ericnormand13:11:51

there's still the issue of dealing with the failed messages

ericnormand13:11:12

it might depend on your UI

pesterhazy13:11:43

Yeah sounds like we need a design pattern here

lovuikeng13:11:03

i'd say in your use case, the user selected or active product always takes precedence over the incoming product from data channel

p-himik14:11:40

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?

bbrinck23:11:42

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.

bbrinck23:11:42

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)