Fork me on GitHub
#re-frame
<
2016-05-12
>
fasiha01:05:45

@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

mikethompson01:05:24

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

fasiha01:05:27

Same here, especially with re-frame-template

fasiha01:05:24

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

roberto01:05:42

I was referring to keechma, not re-frame.

mikethompson01:05:42

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

fasiha01:05:42

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

roberto01:05:00

yeah, sorry I wasn’t explicit enough

fasiha01:05:27

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

roberto01:05:22

yeah, that is how I started

roberto01:05:38

eventually broke out the views into separate files

fasiha01:05:53

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

fasiha01:05:36

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…

fasiha01:05:06

@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?

danielcompton01:05:45

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

fasiha01:05:42

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

fasiha01:05:09

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

fasiha01:05:00

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

https://github.com/amark/gun looks dank cool too… JS tho.

danielcompton01:05:11

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

fasiha01:05:14

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

danielcompton03:05:03

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

mccraigmccraig20:05:07

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