This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-06-09
Channels
- # aleph (4)
- # arachne (3)
- # beginners (41)
- # boot (300)
- # cider (17)
- # cljs-dev (37)
- # cljsjs (4)
- # cljsrn (5)
- # clojure (249)
- # clojure-boston (3)
- # clojure-czech (4)
- # clojure-dev (14)
- # clojure-greece (183)
- # clojure-nl (2)
- # clojure-russia (11)
- # clojure-spec (135)
- # clojure-uk (37)
- # clojurescript (56)
- # community-development (8)
- # cursive (22)
- # data-science (4)
- # datomic (150)
- # devcards (6)
- # emacs (5)
- # euroclojure (8)
- # funcool (18)
- # hoplon (29)
- # immutant (1)
- # jobs (1)
- # lambdaisland (3)
- # lein-figwheel (7)
- # leiningen (18)
- # mount (1)
- # om (81)
- # onyx (95)
- # planck (50)
- # proton (6)
- # re-frame (62)
- # reagent (2)
- # ring (1)
- # robots (1)
- # spacemacs (2)
- # specter (88)
- # test-check (32)
- # untangled (23)
- # yada (1)
How do you know where in the app-db to put state for a component that's currently editing something?
Let's say I have a component that has some semi-transient state. Is there a best practice for where those semi-transient things should go?
@escherize: ha. depends what you mean by semi. I’m inputing individual keystrokes into the app-db (for searching) and it’s going pretty well
I’d put it in app-db
My goal is to be able to restore the exact UI for a user from local-storage
Well, if you were keeping your address card info in [:address-card] maybe put it in [:address-card :temp]?
you can only have one “in-progress” address card, right?
hmm, yeah there’s not really one right way to do this. I’m only using the app-db for UI state. I’m storing everything else in datascript and that’s made things a hell of lot simpler
I used to worry how to store the app state and now it’s always easily accessible
Yeah, it’s quite wonderful really (IMHO).
Especially because Posh can make all of your queries reactive
well, Posh has one for sure, but I don’t think they are using re-frame
I mean, I wish I could claim I’ve done something unique, but I’m just putting posh queries in my subscriptions
(register-sub
:participants-all
(fn [_ _]
(let [ds-query (q-tx @shared-db
[['_ :participant/firstName]
['_ :participant/lastName]
['_ :participant/photo]
['_ :participant/dateAdded]]
'[:find [(pull ?e [:db/id
:participant/firstName
:participant/lastName
:participant/photo
:participant/dateAdded]) ...]
:where [?e :participant/firstName]])]
(reaction @ds-query))))
stuff like that
then my app-db schema is super simple. {:search-query “asdf” :current-group 2 … }
not sure I’m following you?
like in the app-db?
well, not really. that’s why I switched to datascript.
I kept realizing I needed the data to be represented in different ways, but didn’t want to repeat it
I got tired of re-writing all of my subscriptions because later on I’d realize the data was better stored in a different format
it’s a membership database for after school programs, non-profits and schools.
(super sexy I know)
and I feel blessed for that
I used to have to write in C#!
I plan on open sourcing the general app I’m building. It’s been a pain to get this all running with react native, so if I can help someone else out I’ll be happy. Doubtful that will be anytime soon though. Sorry!
Anyway, getting back to your question, if you stored that data in datascript then it’d be a lot easier. You’d have an address entity with a field pointing to an edited version. So then when you’re displaying the card you’d get both back and then it’s pretty obvious what you want to show in the UI.
(keep in mind I’ve clearly drunk the kool-aid w/r/t datascript…and everything clojure related for that matter)
@seantempesta: tell me more about re-frame + datascript! I'm using datascript to store data & run queries, but the connection is stored inside re-frame's app-db. And entirely by coincidence, because of that setup, all the UI stuff is in app-db, while my actual data is in datascript. Are you also storing the conn in re-frame app db?
That feels a little clunky because the subscription that returns the connection (an atom containing the actual db) has to be smarter than usual: I can't just return (reaction (:conn @db))
because the Datascript atom doesn't change "value" (only the object it references), and the reaction never returns
So I have this helper key in app-db, called :conn-heartbeat
with an integer value, and whenever I transact on the Datascript db (changing it), I just inc
the :conn-heartbeat
. The subscription that returns the Datascript conn depends on both :conn
and :conn-heartbeat
, and returns both, so my views get hydrated with the Datascript conn properly
if I needed something with a lifecycle, like a datascript connection, I would probably create a component for that. https://github.com/stuartsierra/component