This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-14
Channels
- # admin-announcements (2)
- # beginners (8)
- # boot (75)
- # clara (2)
- # cljs-dev (3)
- # cljsjs (39)
- # cljsrn (1)
- # clojure (75)
- # clojure-brasil (3)
- # clojure-dusseldorf (13)
- # clojure-gamedev (1)
- # clojure-mexico (1)
- # clojure-quebec (5)
- # clojure-russia (30)
- # clojure-sg (3)
- # clojure-spec (25)
- # clojure-uk (65)
- # clojurescript (36)
- # core-async (1)
- # cursive (15)
- # data-science (6)
- # datomic (38)
- # devcards (29)
- # editors (1)
- # emacs (11)
- # funcool (6)
- # hoplon (43)
- # immutant (48)
- # lambdaisland (2)
- # leiningen (9)
- # mental-health (4)
- # mount (1)
- # numerical-computing (1)
- # off-topic (4)
- # om (19)
- # onyx (1)
- # pedestal (1)
- # proton (1)
- # re-frame (21)
- # reagent (1)
- # specter (8)
- # sql (3)
- # testing (14)
- # untangled (9)
- # yada (31)
@dnolen: fixing #604 depends on the #637 fix. do you think it’s OK to put them in the same PR?
(I do provide separate tests for each of them, though)
@dnolen: looking through the issues, I think these have been fixed and can be closed: https://github.com/omcljs/om/issues/673 https://github.com/omcljs/om/issues/679
@anmonteiro: k thanks
Just thinking out loud, it's not a bug for me, but I noticed a change from alpha37 to alpha40, which is that a map I pass into factory:
(.root render.
((om/factory Component) {:data "to be read in comonents props"}))
that the :data
is only seen in the Components properties after one rerender, but not on initial load, which it did in alpha37. Maybe I'm the only one noticing this, or this is to be expected. And in my case the workaround was easy.ahh ok, one big difference, besides version, is that I use om/update-state! in componentDidMount, that causes this more likely than version changes. Nevermind.
@anmonteiro I saw that you set up om/transact!
to return the parsed value in alpha40, did you have a use case in mind for that? Since the app will have to re-render the component with the new data anyway, I’m not understanding the benefit, but I feel like I’m missing something
@ethangracer: when a mutation throws, the error will be assoc
ed in the result
Previously there wasn't a way to get at those stacktraces
So you could only guess what was throwing
ahhh, yes that will be very handy
thank you
@anmonteiro: mapped-ident?
?
I'm assuming this is a function that checks for the existence of an item in a table via something that looks like an ident
so, an "ed" ending seems better than "able". Though you may feel that the mere existence of the table is sufficient. In which case "able" is better.
@tony.kay: thx for the feedback. Atm I'm just checking for the existence of the table
It seems to me that the actual item may exist or not depending on remote stuff but the table will be there if any other items of that kind have existed before
@anmonteiro: yeah, that's reasonable. If the table is there and the thing checks out as an ident (2-vector starting with a keyword) then it should be a rare case that you get a malfunction. Especially if people use the idiom of naming tables things like :people/by-id
instead of just :people
...the latter leading to possible false-positives when composing random libraries of components.
@tony.kay: agreed. IMHO, sometimes stronger validation leads to less usability