Hi, I'm curious if re-frame has any planned usage for the new reagent track feature. It seems like there may be some overlap between the two libs in this area...

@johanatan: no plans to use track. Not enough overlap

So, just sticking with reaction then?

Yes, but under the covers. The coming v0.8.0 way means you are mostly oblivious to the mechanism: https://github.com/Day8/re-frame/blob/develop/examples/todomvc/src/todomvc/subs.cljs

any planned date for the official 0.8.0 release?

Well, I keep saying about a week 🙂

But right now it feels closer than that

I wish I could be clearer

@mikethompson: I know that my parameters are wrong; the re-com assertions are clear. What I don't understand completely is why it breaks the react rendering, so I have to reload the whole page

Has middle wares for subscriptions ever been given any thought? Things like path would let my subscriptions be more symmetrical with my event handlers

Any Chinese/Japanese/Korean typers in the house? When I use the dead-simple re-frame approach to typing in a text area (`:onChange #(r/dispatch [:my-handler (-> % .-target .-value)])` on the input tag) and try typing with an IME, my text gets butchered because React is grabbing individual key presses instead of letting the IME complete the word.

Smells like this https://github.com/facebook/react/issues/3926 but the latest React examples (https://jsfiddle.net/reactjs/n47gckhr/ linked from https://facebook.github.io/react/docs/thinking-in-react-zh-CN.html) seems fine with IME? They’re doing something a little different, the search bar there updates not onChange but something called onUserInput which might be unofficial because I can’t seem to find anything about it

you're probably aware but a ghetto workaround is use :on-blur instead of :on-change

@fasiha: I've disconnected the input state from my app-db for other reasons in the past, and that may work for you - basically, I added an extra key for the current state that was updated on change, but the input didn't change in response to it. Then when focus changed or a form was submitted, I updated the "real" database key - I think I only really needed one extra db key, something like :editing that held that current input value.

how can I use the app-db / subscriptions in a non-component context?

I have a url routing table that I want the different components to register themselves with, probably through the app-db, but the way it would be accessed is through a non-component function, 'url-for

so basically url-for is a non-reactive query on app-db for the data I guess

I guess just inspect re-frame.db/app-db directly?

you can dispatch-sync on startup?

app-db is always there - you can just deref your subscription to get the value when you need it

so I can use a subscription as if it was a normal atom for deref?

yep

ok, thanks

@(re-frame/subscribe [::my-query])

just curious, but how would you go about converting a subscription to a lazy sequence of updates?

so you can do stream ops on it?

you mean using reaction?

I can't find any documentation on reaction, but perhaps that's what I'm looking for

@shader https://github.com/Day8/re-frame#how-flow-happens-in-reagent

^ a long read, but well worth it. read it twice to make sure it all goes in 🙂

well, I'm not sure that's exactly what I'm talking about. It still requires you to imperatively deref the reaction to get the current value. I was hoping for something more like rx.js or most.js reactive streams; lazy sequences you can use with map, reduce, etc.

Anyone know the answer to the question I asked yesterday? https://github.com/Day8/re-frame/issues/170

it seems as though reagent/re-frame give the illusion of a stream of updates because of the re-rendering of ui components when one of the values changes

I currently grab the value from my REST api on the route change, but thats a bit sucky

@shader: Are you looking at going through the history of changes for a particular item after the fact?

not particularly; I just think the reactive stream model is slightly more declarative in its construction. Also, easier to use outside of a react component

I might be misunderstanding, but it seems like you are looking at a different philosophy to reach the same goal as what re-frame gives you. I find the whole reactive data landscape pretty fascinating but have not used many of the other options, but I can throw up a few links if you're interested that may help you explore a bit of what currently exists in the Clojure landscape to see if it helps you find what you're looking for (either in a way to use re-frame or outside of it).

it's possible

reactive streams are definitely nice, imho still there is the burden of learning the jargon and set of transformers which can get quite complicated. Re-frame hits the sweet spot with its view on things, not to hard but powerful and flexible enough. For now it has fulfilled all my dev needs and 0.8.0 fixes many if not all the pain points

have you seen most.js?

it's really not that complicated

there is a little bit of mind-bending when it comes to thinking in terms of streams vs values

but you still have that layer of indirection from a ratom

Nope but I'll check thanks!

The ratom is still useful for component-local state you are right

Maybe I am used to it and I find it manageable,

Nonetheless the binding data-view should be kept as simple as possible in order to avoid using too many atoms...not saying it is perfect...

do you think an ratom is better than an event/sub for local state? For example, imagine a pagination component for a table?

@mnewhook: aren't the two things supposed to work together for that feature? the ratom holds the current page number, while on the re-frame event bus you send the :page-changed event? Am I understanding correctly your question?

(defn whitelist []
  (let [white (subscribe [:white])
        page (r/atom 0)]

vs (subscribe [:page-number])

the thing is that page is entirely local to the current component, so I’m not sure what polluting the entire application with this local state is a good idea.

mmm no but you are talking about ratom, but a ratom can be either local or global depending on the use case right? I think even in a re-frame app you it is good practice to keep local ratoms if they are not needed in any other component

I guess

isn’t ratom a reagent atom?:)

in either case if I read you right you are agreeing with my point?

yes still a ratom can be both global or local, up to you to organize it properly

the ratom in this case is completely local to the current component, so using the event/sub mechanisms seems unnecessary and pollutes the global environment.

yeah agree

the moment your data needs to be visible outside of it, then you can start thinking about a bus