This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (191)
- # boot (3)
- # cljs-dev (2)
- # clojure (46)
- # clojure-austin (1)
- # clojure-spec (4)
- # clojure-uk (32)
- # clojurescript (10)
- # clojurewerkz (3)
- # cursive (14)
- # datomic (88)
- # defnpodcast (1)
- # editors (2)
- # fulcro (2)
- # hoplon (3)
- # jobs (4)
- # jobs-discuss (1)
- # luminus (5)
- # lumo (6)
- # off-topic (13)
- # random (1)
- # re-frame (50)
- # reagent (245)
- # remote-jobs (1)
- # spacemacs (3)
- # specter (16)
- # uncomplicate (4)
re-frame-datatable (changelog: https://github.com/kishanov/re-frame-datatable/blob/master/CHANGELOG.md, updated documentation website: https://kishanov.github.io/re-frame-datatable/ )
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: https://react.semantic-ui.com/
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
sodium? I only know they’re related to
react.semantic-ui, haven’t used them or anything.
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?)
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 (https://www.youtube.com/watch?v=DdkwNTgtIJ0) 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.
@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
@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.
@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
@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
Layer 3 subscriptions will only run if their inputs are different from last time
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
@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