Fork me on GitHub
#om
<
2016-05-26
>
ag00:05:50

has anyone transacted values on mouseover event (rather than on-click)?

ag00:05:55

what’s the right way of binding the handler? trying on-mouseover mouseover onMouseOver - nothing seems to work

ag00:05:48

actually nvmd.

ag00:05:09

the last one on-mouse-over with sablono works

mattyulrich01:05:38

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

mattyulrich01:05:26

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.

mattyulrich01:05:37

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)

mattyulrich01:05:19

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.

mattyulrich01:05:56

Is this kind of problem something anyone has seen? (I seem to see it a lot - must be doing something wrong)

cjmurphy02:05:58

@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 ...

ag02:05:51

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"))

cjmurphy02:05:30

@ag: I can only say yes, that doesn't seem like a very good idea to me.

cjmurphy02:05:33

Those two components can go in app state and have their own idents, that's the way I would do it.

cjmurphy02:05:43

@mattyulrich: fwiw I have quite a few namespaces under app-name.parsing.mutations, that namespaces under the ui namespace depend upon.

ag02:05:45

@cjmurphy: so I need to have one root, that would include TopNavBar component and its query, right?

ag02:05:23

how do I include TopNavBar’s query? what should it be? union?

ag02:05:28

or join?

cjmurphy02:05:48

Your root doesn't have an ident. Often it is called App or Root, but yes TopNavBar would do.

cjmurphy02:05:32

Your root component just has a lot of joins. No special need for a union.

mattyulrich02:05:31

@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.

cjmurphy02:05:06

@mattyulrich: You just need to avoid the circular dependencies. Robert C Martin has written whole books around that subject.

ag02:05:57

@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?

mattyulrich02:05:42

@cjmurphy: Yeah - I can work on re-organizing to remove the circular dependency, thanks.

cjmurphy02:05:10

@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.

cjmurphy02:05:43

@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.

cjmurphy02:05:14

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.

cjmurphy02:05:17

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.

cjmurphy02:05:06

@ag yes - I would have been lost without a good study of it.

ag02:05:30

ok… I’ll study it.. thanks

jannis07:05:18

cjmurphy: Aww, thanks 🙂

cjmurphy08:05:46

@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 simple_smile

danielstockton14:05:43

is there likely to be support for set-query with datascript any time soon?

anmonteiro14:05:52

I’m glad you ask that, I was going to bring it up with @dnolen today

anmonteiro14:05:17

I’ve been thinking about that problem, and I was thinking we could store the queries in the indexer

anmonteiro14:05:26

We’re doing everything related to queries there anyway

danielstockton14:05:40

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).

danielstockton14:05:05

The other solution would be some simple hooks that define how queries can be saved/retrieved from whatever store you're using

danielstockton14:05:19

(defaulting to the default atom store)

anmonteiro14:05:41

@danielstockton: we’ve already lost the ability to sync by replicating just the state

anmonteiro14:05:58

with the way we’re handling dynamic queries

danielstockton14:05:57

Oh, have we? I thought it just used a special namespaced keyword in the state

anmonteiro14:05:25

that’s right, but not where the problem is

anmonteiro14:05:21

get-query uses the indexer to get queries that have changed so as to have a consistent view from the parent

dobladez21:05:45

Anybody using react-router with om/next? Does it even make sense? (sorry, I'm pretty new to both React and Om)

ethangracer22:05:55

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"}}})

ethangracer22:05:33

When I call (om/db->tree (om/get-query Root) state state), it returns {:children [{:id 1, :things [{} {}]}]}

ethangracer22:05:07

which suggests to me that you cannot have a vector of maps in app-state — all vectors of maps must be normalized

ethangracer22:05:13

is that conclusion correct?

ethangracer22:05:35

looks about right

ethangracer22:05:03

any thoughts on where to look for a fix? I was having a hard time finding where in denormalize* it happens

anmonteiro22:05:17

I opened that a while ago to track

anmonteiro22:05:35

a decision wasn’t made whether it’s something that needs a fix or not

anmonteiro22:05:17

so I never inspected it further

ethangracer22:05:17

why wouldn’t it? the only alternative would be to normalize every list of maps

ethangracer22:05:34

maybe the normalization process isn’t worth the trouble

ethangracer22:05:45

for some set of data

anmonteiro22:05:04

maybe it needs some more discussion now that someone else found it 🙂

ethangracer22:05:23

Happy to discuss 😄 — just not understanding the other point of view, why it wouldn’t need a fix

ethangracer22:05:03

I can describe how I’m running into it in the app I’m building, if that helps

anmonteiro22:05:26

I bring it up at 21:12:22

anmonteiro22:05:37

not sure if it would be the same time for you

anmonteiro22:05:06

also quote by David: if people just leverage this they won’t normalize - and their apps will be crazy slow

anmonteiro22:05:15

that was the main point against

ethangracer22:05:03

what if there is no situation that I would need to re-render the child data alone?

ethangracer22:05:21

i.e. every time the child is modified, the parent is as well

ethangracer22:05:31

then there is no performance loss

ethangracer22:05:38

maybe an odd use case, but there wouldn’t be a need for optimizing the query to that degree

ethangracer22:05:54

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

cmcfarlen23:05:28

@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?