Fork me on GitHub
#re-frame
<
2016-02-11
>
samueldev00:02:18

I've got the following...

samueldev00:02:00

but only the former generic input component shows up in the UI

samueldev00:02:19

Can I not call 2 generic components back to back?

samueldev00:02:20

Derp messed up parens. Ignore me.

danielcompton01:02:43

@martinklepsch: you could just copy it out

danielcompton01:02:30

@jaen re-frame is looking at moving to not having global state, similar to pure-frame https://github.com/Day8/re-frame/issues/137

martinklepsch10:02:59

@danielcompton: yeah considered that but not really something I like doing haha. Thought about how I should take the re-frame.router and release it as ame and come up with some funky acronym like "async message engine" 😄

danielcompton10:02:47

we were considering making a library out of it, but it was just a little bit small at the time

danielcompton10:02:06

could reconsider though

martinklepsch10:02:13

@danielcompton: makes perfect sense to me (now that I need it simple_smile )

lad10:02:17

Hello. How can I view the slack archive for this channel? It seems I can only scroll back to Feb 5.

jaen10:02:24

Sorry, it's a free slack which has limit on search

jaen10:02:28

BUT drumroll

lad10:02:42

edge of my seat

jaen10:02:51

There's a bot that logs stuff ; d

lad10:02:07

:thumbsup: jaen

lad11:02:08

What's the recommended approach for integrating with a restful service which requires token authentication (need to store unique token which each response contains). I need to store the token and ensure that all requests requiring auth use the latest token(which changes with each response).

lad11:02:05

I'm using cljs ajax. I seem to be having non deterministic 401 when I start firing multiple ajax request quickly. My intuition is that multiple request dispatches are completing ajax response out of order and then setting an invalid token.

jaen11:02:04

Store in an atom, deref it when sending request

jaen11:02:21

The problem is indeed when you start firing multiple requests in short order

jaen11:02:32

How would you ensure the linearisation of the order you get the new tokens in?

jaen11:02:50

What if a later AJAX request finishes before the earlier AJAX request?

jaen11:02:56

Won't that mess up the tokens then?

jaen11:02:05

Basically you have a concurrency race

jaen11:02:21

At least it appears so from your description

jstaffans14:02:08

I'd think re-frame more or less follows the pattern the author lays out in the article. OTOH the author called redux "garbage" because it doesn't follow it closely enough ..

kamn14:02:21

@jstaffans: Interesting talk. Not sure I grok certain parts

kamn14:02:01

I maybe need to learn TLA+ to understand better

jstaffans15:02:06

@kamn: this is how the author summarised TLA+ on Gitter:

jstaffans15:02:05

* actions are pure functions: data' = A(data) * model is responsible for every state mutation: model.present(A(data)) * compute state from model: S(model.present(A(data))) * compute next-action-predicate and execute action if any: S(model.present(A(data)), nap(M))

jstaffans15:02:58

but yeah, I'm also not quite grokking it, especially the next-action-predicate part

kamn15:02:33

I watched a talk from the TLA+ guy a while ago but it didn't sink in much

kamn15:02:26

I think that is it

lad18:02:21

Jaen: I believe it is a concurrency race also. I'm more or less at a loss of how to ensure linearisation of the ajax requests. :(

jaen18:02:49

Well, I think this is entirely nontrivial - if you've ever read Aphyr's Call me Maybe series on disitrbuted systems you'll be aware how hard that is.

jaen18:02:06

I think an idea would be to try to decouple the ticket from the request

jaen18:02:17

As in let the client ask for tickets separately

jaen18:02:30

They will have a certain TTL

jaen18:02:37

During which the client can use to query

jaen18:02:50

And client can hold multiple tickets at a time

jaen18:02:04

And they are valid either until TTL runs out

jaen18:02:08

Or a request using it is made

jaen18:02:22

Then they are removed from the pool of active tickets

jaen18:02:42

That way you can decouple the tickets from time

jaen18:02:48

Which could help to solve your case

lad18:02:01

Jaen: well that makes me feel a little better knowing it's non trivial. I'll have to revisit those articles. And I'll have a think about your ideas.

jaen18:02:12

Well, at least it feels non-trivial to me, I may be missing something. But given that the requests are asynchronous and can vary in the time it takes for them to be processed, they can overlap eachother, which means the tickets you get from the server will be not received in the order they are issued and if there's only one ticket active at a time (at least from your description I assume that's the case) it will mean the ticket can get invalidated before you can use it, resulting in intermittent errors.

lad19:02:14

That is exactly what I believe is going on!

jaen19:02:45

Yep; so I'd try with a ticket pool instead, so that you can have > 1 ticket active at a time

lad19:02:28

jaen: thanks for your input. will think more about how to get a ticket pool in place

jaen19:02:55

Sure, glad to have been (probably) of help