Fork me on GitHub

@roberto on #C0620C0C8 you said, a few days ago, that "everytime I started working on the [re-frame] project, the first file I’d open is the one that describes the dependencies … with re-frame, it got a bit difficult to figure out where things were going after a while"—whenever you get the chance, can you expand on what that means? I'm trying to see if I somehow skipped that point, or if that's something I can look forward to hitting simple_smile


We don't have roboto's experience. It always seems perfectly obviously where to look for things.


Same here, especially with re-frame-template


There's been a lot of non-re-frame talk on this channel last few days but I'm still in awe of how much progress I was able to make with re-frame. Shipping an in-cockpit pilot aid for flight tests with re-frame in a few days simple_smile


I was referring to keechma, not re-frame.


Make sure you namespace the keywords in the events you dispatch (dispatch [:dayparts/delete-all] )


Ah, sorry! The first sentence in that quote was about keechma, the second was about re-frame, got it.


yeah, sorry I wasn’t explicit enough


Did you use re-frame-template? Putting db in db.cljs, subscriptions in subs.cljs, handlers in handlers.cljs, and views in views.cljs?


yeah, that is how I started


eventually broke out the views into separate files


@mikethompson: doh! that's a really good idea, namespacing events (and subscriptions too now I think of it—usually I name a key in db the same thing as a handler as a subscription). Should be recommended in the re-frame readme 😄


You know, I saw the title of that wiki page when I was starting out, and didn't read it because I was just starting out. Now I realize I have "A Larger App". Where does the time go…


@mikethompson: I've been wondering for some time and felt sheepish about asking, but here goes. How do your apps handle backend communication and client/server(/other clients) sync?


@fasiha: I work with Mike, we are working on synchronising parts of our app state with RethinkDB


Ah, got it! I, in my ignorance and foolhardiness and refusal to Get It Done, am hoping to find a way to express my re-frame subscriptions/handlers in the same "language" as backend queries/transactions, so that when certain parts of app-db are changed in re-frame, they get pushed to the server using the same representation of the change on the backend, so I don't basically have to rewrite re-frame subs/handlers on the backend in, e.g., Rethink


(So I'm studying datascript, much to my colleagues' chagrin—if my subs/handlers can internally use queries/transactions, which are just normal Clojure vectors, then I hope to be able to push the same vector to the server to evaluate on the backend. Like Posh.)


Is there something special with RethinkDB that lets you get away from doing the usual REST endpoints, ad-hoc client-to-server interface that specifies the query/transaction requested, etc.?

fasiha01:05:51 looks dank cool too… JS tho.


RethinkDB has changefeeds, so you can subscribe to a table and get changes come down


Ah right!, so that simplifies one half of the whole greatly.


Although reconciling the updates with their changes is a bit tricky still


@mikethompson: i finally had enough of all the boilerplate required to use clairvoyant with re-frame subs & handlers and wrote some code to tidy it up...