This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-05-26
Channels
- # admin-announcements (2)
- # aws (1)
- # beginners (21)
- # boot (61)
- # cider (5)
- # cljs-dev (94)
- # cljsrn (35)
- # clojure (106)
- # clojure-austin (3)
- # clojure-belgium (1)
- # clojure-dev (4)
- # clojure-dusseldorf (9)
- # clojure-greece (2)
- # clojure-mexico (1)
- # clojure-russia (40)
- # clojure-spec (61)
- # clojure-uk (17)
- # clojurescript (151)
- # code-art (1)
- # component (7)
- # core-async (4)
- # cursive (1)
- # datomic (9)
- # dirac (55)
- # funcool (12)
- # hoplon (118)
- # incanter (12)
- # jobs (8)
- # juxt (1)
- # lein-figwheel (6)
- # mount (2)
- # off-topic (2)
- # om (76)
- # onyx (28)
- # other-lisps (1)
- # planck (7)
- # re-frame (9)
- # reagent (13)
- # ring-swagger (2)
- # specter (1)
- # yada (22)
what’s the right way of binding the handler? trying on-mouseover
mouseover
onMouseOver
- nothing seems to work
Hi all - I’ve been having an issue with circular dependencies; it keeps coming up. To try and keep things simple I’ve got 4 namespaces (kind of following the pattern from kanban):
reconciler
- contains the multimethod specs for read/mutate, the parser and reconciler
app
- contains my app root and mounts my page, depends on reconciler and ui
ui
- contains my UI components, depends on reconciler and parser
parser
- contains my dispatched read/mutate functions, depends on reconciler and app
I think I want my parser
to depend on app
because I frequently use om/tree->db
in mutate functions across the App-Root
query.
But whenever I take the reference to parser
out of the ui
- I get complaints at runtime about missing read
and mutate
functions.. (ie. no read function found for :current-user
type stuff)
I’m not sure why om.next is validating the read/mutate functions from the ui
namespace; reads are being issued from the App-Root
and mutates are being dispatched through the App-Root
component.
Is this kind of problem something anyone has seen? (I seem to see it a lot - must be doing something wrong)
@mattyulrich: You have what in Java would have been called a 'recursive package dependency' issue. You need to break that by introducing another namespace. And obviously you need to avoid Om's complaints. Seems like you have ui -> parser -> app -> ui ...
Guys… is it a bad idea to have more than just one (om/add-root!
that use the same reconciler? i.e.:
(om/add-root! reconciler navbar/TopNavBar (gdom/getElement "navbar"))
(om/add-root! reconciler app/Content (gdom/getElement "app"))
Those two components can go in app state and have their own idents, that's the way I would do it.
@mattyulrich: fwiw I have quite a few namespaces under app-name.parsing.mutations
, that namespaces under the ui
namespace depend upon.
@cjmurphy: so I need to have one root, that would include TopNavBar
component and its query, right?
Your root doesn't have an ident. Often it is called App
or Root
, but yes TopNavBar
would do.
@cjmurphy: Thanks for the reply; so you’re also familiar with these Om complaints? I don’t use the parser
namespace in ui
but if I don’t at least require it, then Om gets fussy.
@mattyulrich: You just need to avoid the circular dependencies. Robert C Martin has written whole books around that subject.
@cjmurphy: I am very confused with the query syntax and with the way how root component incorporates queries for children. So right now I have TopNavBar component that perfectly works (if used as a root), its query is this:
(query [this]
`[{:app/top-nav-menu [:app/top-nav-menu]}
{:app/active-top-nav-menu ~(om/get-query TopNavSubmenu)}])
can you help me to write query for when it’s used as a child not root?@cjmurphy: Yeah - I can work on re-organizing to remove the circular dependency, thanks.
@ag When used as a child it would not be that much different I would not think, but it would have to have an ident in your state.
@ag one thing that takes a bit of realizing is that all data/props comes into the root, and it only works to one level of depth - this basically means that your root will end up with a lot of joins, more than you might think.
If you have studied the Kanban demo you will see - for example it doesn't seem to make much sense how many components are joined in the root component.
Also you need to do a fair bit of @my-reconciler to check that your state is in default db format as you think it should be.
@cjmurphy: you mean this https://github.com/Jannis/om-next-kanban-demo ?
@jannis Yeah it super helped me and probably others I've recommended it to here too. The way I see it is tutorials give you bottom up understanding but your thing helped with top down thinking design decisions - like when to use local state. Especially helpful I would think for people (like me) who did not come from Om (I came from Reagent/reframe). Thank you
is there likely to be support for set-query with datascript any time soon?
I’m glad you ask that, I was going to bring it up with @dnolen today
I’ve been thinking about that problem, and I was thinking we could store the queries in the indexer
We’re doing everything related to queries there anyway
Yes, i think that was one solution that came up before. One disadvantage is that you now effectively have two app-states (if you want to replicate a certain state in another browser, you'd have to sync both).
The other solution would be some simple hooks that define how queries can be saved/retrieved from whatever store you're using
(defaulting to the default atom store)
@danielstockton: we’ve already lost the ability to sync by replicating just the state
with the way we’re handling dynamic queries
Oh, have we? I thought it just used a special namespaced keyword in the state
that’s right, but not where the problem is
get-query
uses the indexer to get queries that have changed so as to have a consistent view from the parent
Anybody using react-router
with om/next? Does it even make sense? (sorry, I'm pretty new to both React and Om)
So, I have this app-state / query setup:
(defui ^:once SubChild
static om/IQuery
(query [_] [:id :my-fav-word])
static om/Ident
(ident [_ props] [:child/by-id (:id props)]))
(defui ^:once Child
static om/IQuery
(query [_] [:id
{:things [:my-fav-number
{:sub-child (om/get-query SubChild)}]}])
static om/Ident
(ident [_ props] [:child/by-id (:id props)]))
(defui ^:once Root
static om/IQuery
(query [_] [{:children (om/get-query Child)}]))
(def state {:children [[:child/by-id 1]]
:child/by-id {1 {:id 1 :things [{:my-fav-number 26
:sub-child [:sub-child/by-id 2]}
{:my-fav-number 42
:sub-child [:sub-child/by-id 3]}]}}
:sub-child/by-id {2 {:id 2 :my-fav-word "clojure"}
3 {:id 3 :my-fav-word "clojurescript"}}})
When I call (om/db->tree (om/get-query Root) state state)
, it returns {:children [{:id 1, :things [{} {}]}]}
which suggests to me that you cannot have a vector of maps in app-state — all vectors of maps must be normalized
is that conclusion correct?
@ethangracer: I think you’re running into this: https://github.com/omcljs/om/issues/604
looks about right
any thoughts on where to look for a fix? I was having a hard time finding where in denormalize*
it happens
I opened that a while ago to track
a decision wasn’t made whether it’s something that needs a fix or not
so I never inspected it further
why wouldn’t it? the only alternative would be to normalize every list of maps
maybe the normalization process isn’t worth the trouble
for some set of data
maybe it needs some more discussion now that someone else found it 🙂
Happy to discuss 😄 — just not understanding the other point of view, why it wouldn’t need a fix
I can describe how I’m running into it in the app I’m building, if that helps
maybe
I bring it up at 21:12:22
not sure if it would be the same time for you
also quote by David:
if people just leverage this they won’t normalize - and their apps will be crazy slow
that was the main point against
hm, ok
what if there is no situation that I would need to re-render the child data alone?
i.e. every time the child is modified, the parent is as well
then there is no performance loss
maybe an odd use case, but there wouldn’t be a need for optimizing the query to that degree
I definitely see the importance of normalization for optimizing query duration, I guess in the app I’m working on I have a situation where normalizing seems unnecessary — the data does not need to be reused in multiple places
@anmonteiro: I have a fix to process-roots
not working with recursive queries. Should we discuss it here or can I just open an issue/pr?