This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-06-10
Channels
- # aleph (4)
- # announcements (27)
- # aws (12)
- # aws-lambda (1)
- # beginners (207)
- # boot (4)
- # calva (8)
- # cider (9)
- # clj-kondo (9)
- # cljs-dev (27)
- # cljsrn (6)
- # clojure (104)
- # clojure-android (3)
- # clojure-dev (9)
- # clojure-finland (2)
- # clojure-italy (18)
- # clojure-spec (8)
- # clojure-uk (100)
- # clojurescript (43)
- # clojutre (1)
- # core-async (49)
- # cursive (18)
- # data-science (3)
- # duct (24)
- # events (2)
- # fulcro (27)
- # immutant (1)
- # off-topic (32)
- # om (2)
- # onyx (2)
- # pathom (14)
- # pedestal (2)
- # planck (3)
- # re-frame (38)
- # reagent (7)
- # reitit (10)
- # rewrite-clj (7)
- # ring-swagger (3)
- # shadow-cljs (32)
- # spacemacs (63)
- # test-check (16)
- # tools-deps (5)
- # vim (21)
is there some tool that would help me to find unused event handlers and subscriptions? I'm trying to clean cobwebs off a legacy project but it's quite hard to eyeball this.
one of the shortcomings of everything-is-a-keyword in re-frame is that it doesnāt provide easy discovery of that sort of thing. if we used vars we could know by analyzing a call-graph
although I tried writing a quick tool based on slurping all the files, read-stringing them and walking everything collecting handlers and rf/dispatches
it's Just Data, so it can be serialized in some format and stored into LocalStorage or elsewhere.
but I'm not aware of anything that does PouchDB-like sync to a backend automatically.
Heard of https://github.com/denistakeda/re-posh and https://github.com/metasoarous/datsync , but have not tried
Currently Iām serializing with transit, but the app-db is so large now that itās a significant performance hit to do that on every action
we just serialize our app-db to EDN on the filesystem when the app is backgrounded, and retrieve from EDN when the app has been evicted and is started or foregrounded
Oh, thatās a good idea. I hadnāt thought of leveraging backgrounding/foregroudning.
Itās a little scary though, because if the app crashes before itās backgrounded, the user would lose all of their work.
"evicted" means that, after backgrounding, the app's paused process image was killed by the o/s, so when next foregrounded it's starting from scratch
in the case of our app we also have most state server-side, so we are only storing locally so that the app can continue to work offline - so the risk of the user losing anything is small
if i needed to store everything then i would consider storing an occasional app-db snapshot, and then appending in a separate file, a list of mutation events to be applied to the app-db snapshot
you can probably arrange that neatly with a re-frame interceptor
and since you would only be appending event data (which will serialize nicely to EDN, since your re-frame events / app-db are all pure, simple data) to an already open file it will be blazingly fast
i ran into a couple of issues with that. 1) Not everything in the event data was neatly serializable (e.g. some cofx data had infinite sets or fns etc) and 2) Itās possible that the implementation of the event handlers could change between the time the event was stored and when it was played back
[2] you can deal with in a similar way to how you would deal with e.g. messages from kafka being processed after a db schema changes - either make sure schema changes are backwards compatible (only additions - no field deletes / type changes until you are sure everything has been flushed) or drop changes with stale schema
[1] are you putting things which are not pure, simple data into your app-db ? if so, try and avoid doing that. it causes pain š¬- could you store a pure-data description of a seed or generator for the infinite set instead ?
[2] Yeah thatās a good call. I had thought about doing that as well. Maybe Iāll open source my current implementation and release it as a re-frame plugin/interceptor.
ah, i see what you mean for [1] ... in which case, you could perhaps look at the :db
fx itself, after the event has processed, and use clojure.data/diff
to extract a minimal diff to write to your change-log - cf https://clojuredocs.org/clojure.data/diff
i've only used the clojure.data/diff
stuff for single-level diffs myself - but the docs indicate it's ok for nested structure diffs
Iām actually doing just that haha. Using a lib called differ https://github.com/Skinney/differ