Fork me on GitHub

@henrik you might be interested in the Track feature of


Is it possible to use existing react component libraries with re-frame? In particular I'm interested in using the react semantic ui component lib:


Just added a feedback form that captures the entire appdb state. And then I load it into the app from an admin page. Can see exactly what the user was seeing. Pretty cool stuff re-frame/reagent!


@stvnmllr2 I have had this use case in mind for reagent from the very beginning, but never got around to implementing it. Do you have intent of librarifying your solution?


@ramblurr maybe you should check out soda-ash or sodium? I only know they’re related to react.semantic-ui, haven’t used them or anything.


@reefersleep ah, very nice, thanks for the links.


I want to build an offline first app that keeps all state and data locally, with syncing to a server occasionally. Normally I'd use PouchDB for this, but in this brave new clojurescript world I'm entering, I'm not sure if that's possible


looking around the ecosystem I see datascript, datsync, but they don't seem applicable in the this case


Hi folks, is there any solution to avoid running all the subscriptions at any update on app-db ?


@ramblurr does “syncing to a server” basically mean “overwriting the saved state on the server with the newest local state”? Or is it more complex than that (for example involving several offline/occassionally-online users?)


there needs to be some kind of conflict resolution, not just "newest wins"


the data model of this application actually fits quite well to the pouch/couchdb data model (one user per "store", little to no collaboration on shared data among users), which is why i was thinking along those lines to begin with


I saw an interesting talk ( about re-frame, and the speaker says he used pouchdb, so it must be possible.


@reefersleep No, it was pretty trivial and tied to specific events and a db in my case , so not sure a library is needed.


@ramblurr talk to Martin Clausen then? he’s @mac here 🙂 EDIT: (btw mac, only outing you because you seem like a nice guy who wouldn’t mind! sorry!)


(I think… met him a couple of times at #copenhagen-clojurians meetups)


@stvnmllr2 it does seem like something that requires trivial programming, but involving implementation-specific technologies


like how and when to contact the server, and how to communicate the saved state to the admin panel


or even if there is a server involved 😄


Ah cool mac is here 🙂 I sent him a tweet, but maybe he'll see this!


@ramblurr It is very possible to use PouchDB. I don't have any public code out there using PouchDB with cljs , but happy to help with any questions.


@reefersleep Happy to be outed 🙂


@mac thought you might be 😉


@ramblurr PouchDB is available on so you can start by adding to your :dependencies.


@ramblurr I think your use case sounds like it could be done by hand, though? Depending on requirements you haven’t mentioned. looks into pouchdb


ship off your frontend state to the backend periodically (such as when the user opens the app and is actually online, or do asynchronous, periodic checks, like every 5th minute or whatever, to see if the user is online) and then have your conflict resolution in the backend, with whatever data store you desire (sounds like simpler is better in your case)


it’s a problem I’d like to try my hand at 🙂 at a toy level, any way. If there’s a library that takes care of complications I haven’t even thought of, I’d surely go for that!


@lxsameer I’m in doubt about what you’re asking? Aren’t only the subscriptions whose data has changed run?


@reefersleep As far as i know, and tried all the subs run on each change on app-db, and I want to confirm it by asking it in here


@lxsameer just tested it in a re-frame project of mine, it did seem to be the case that a particular sub was run on each db change


is this a problem in your case?


@lxsameer all Layer 2 subscriptions will rerun on any change to app-db. That's why we keep them trivial. All real computation is put into Layer 3 subscriptions.


@mikethompson hmm so as far as i understand, my observation was correct. all the subscriptions will run by each app-db change


All Layer 2 subscriptions will run on any app-db change


Layer 3 subscriptions will only run if their inputs are different from last time


I'm a bit lost in here


To say that another way: 1. subscriptions will run when the value of their inputs have changed 2. Because the input for Layer 2 subscriptions is app-db they will run on every app-db change 3. Because the inputs for Layer 3 subscriptions are other subscriptions they will only run when the derived value (output) of those subscriptions change


Have a read through the link I supplied


ow so layer 3 refers to nested keys for subscriptions


That's a limited view, but yes you could see it that way


and use it that way


@mikethompson I'm using re-frame with a websocket connection and I'm sending data to client constantly


the problem is I have lots of 2 layer subscriptions and on each message all of them execute and slow down the app


So you'll either have to batch updates or design appropriately layered subscriptions