This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-12-07
Channels
- # adventofcode (38)
- # aleph (1)
- # bangalore-clj (3)
- # beginners (126)
- # boot (165)
- # boulder-clojurians (5)
- # cider (42)
- # cljsrn (11)
- # clojure (203)
- # clojure-greece (6)
- # clojure-hk (1)
- # clojure-italy (11)
- # clojure-new-zealand (1)
- # clojure-nl (1)
- # clojure-russia (112)
- # clojure-spec (86)
- # clojure-uk (176)
- # clojurescript (38)
- # code-reviews (2)
- # core-async (2)
- # cryogen (2)
- # cursive (16)
- # datascript (2)
- # datomic (80)
- # events (2)
- # garden (28)
- # hoplon (115)
- # jobs (1)
- # jobs-discuss (7)
- # klipse (50)
- # lein-figwheel (15)
- # liberator (17)
- # luminus (6)
- # off-topic (8)
- # om (31)
- # onyx (26)
- # parinfer (4)
- # planck (35)
- # protorepl (26)
- # quil (2)
- # re-frame (50)
- # reagent (21)
- # ring (5)
- # rum (2)
- # schema (1)
- # untangled (29)
- # vim (10)
- # yada (40)
Has anyone wanted/tried to document reads/mutations? Particularly if they are multi-methods.
Right now I’m putting a :doc
”string”
in the return value,
but I was wondering if there’s some other way I should or can be doing it.
Can someone point me to the correct way for a tempid mapping to move from the server to the client? I don't see a way for the send
callback to take it. Isn't that where it would go?
@peeja: I have a dirty tempid example here: https://github.com/anmonteiro/talks/blob/master/2016-berlin-meetup/src/clj/berlin_meetup/parser.clj
Hope it helps
@anmonteiro Ah, cheers. Looks like you're sending it over as :tempids
, but I don't see where that key is used on the client side. Is that a key that Om itself knows about?
@peeja: yeah, it's what default-migrate
looks for
Ah, got it. So it's well-known by the default, but you can provide your own :migrate
that looks for something else. :thumbsup:
Exactly
@calvis I was thinking it would be simple for :history
to be a number or some IHistory
instance, thoughts?
ah wait maybe not- it looks like the tx
information is gone by the time it gets to the cache
so that could be solved with a quick pass of tx
to .add
but it could probably be solved more nicely by having the history decide what gets logged/cached
then people could just watch and do all kinds of things and I don’t have to worry about it
I think previously I thought people might want to treat history as both a stack and as hashmap - but maybe shouldn’t really care about the later
like something to convert a vector to hash map? or scan the history looking for a particular entry?