I've got the following...

http://puu.sh/n3pxE/dbd0258082.png

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

Can I not call 2 generic components back to back?

Derp messed up parens. Ignore me.

@martinklepsch: you could just copy it out

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

@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" 😄

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

could reconsider though

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

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

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

BUT drumroll

edge of my seat

Use this - http://clojurians-log.mantike.pro/

There's a bot that logs stuff ; d

aw snap

:thumbsup: jaen

np

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).

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.

Store in an atom, deref it when sending request

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

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

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

Won't that mess up the tokens then?

Basically you have a concurrency race

I think

At least it appears so from your description

pretty interesting: http://www.infoq.com/articles/no-more-mvc-frameworks?utm_source=infoq&utm_medium=popular_widget&utm_campaign=popular_content_list&utm_content=presentation

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 ..

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

I maybe need to learn TLA+ to understand better

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

* 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))

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

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

https://channel9.msdn.com/Events/Build/2014/3-642

I think that is it

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. :(

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.

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

As in let the client ask for tickets separately

They will have a certain TTL

During which the client can use to query

And client can hold multiple tickets at a time

And they are valid either until TTL runs out

Or a request using it is made

Then they are removed from the pool of active tickets

That way you can decouple the tickets from time

Which could help to solve your case

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.

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.

That is exactly what I believe is going on!

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

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

Sure, glad to have been (probably) of help