Fork me on GitHub
#om
<
2017-01-10
>
ag02:01:09

eghrrr… can someone tell me? why when I have a query in the Root with subquery of a component that has ident such as [{:app/data (om/get-query CompWithIdent)} then in :app/data read method I can see things in state normalized. Yet when I move the query to another component, let’s call it simply Widget and then replace query in the Root to use (om/get-query Widget) then om doesn’t normalize things anymore?

ag03:01:40

ok, for the lack of better ideas I just did this: (om/tree->db (-> ast om/ast->query vector) @state true) in :app/data read method to force normalization.

mavbozo05:01:06

@ag have you tried [{:widget (om/get-query Widget)}] as your Root query?

alex-glv07:01:38

Can anyone suggest why I can’t target :nodejs when building cljsjs.react dependant app? I get

Error: Cannot find module 'react'` 
thrown from react-dom.inc.js, even though I don’t use any optimizations? Something to do with require paths, but can’t make it look in the directory where compiled files are (out)

alex-glv07:01:52

I think it’s a problem with cljsjs.react.dom, as soon as you require the ns it won’t compile for :target :nodejs. The issue is reproducible with omcljs, too

alex-glv07:01:13

You can try by removing all require’s from (ns om.next.run-tests) and only require cljsjs.react.dom, run

./bin/tests
it will fail with the above error.

alex-glv07:01:43

(ns om.next.run-tests
  (:require [cljs.test :refer-macros [run-tests]]
            [cljs.nodejs]
            [cljsjs.react.dom]
            ;[om.dom]
            ))

(defn main []
  )

(set! *main-cli-fn* main)
This should do.

alex-glv08:01:42

This assumes you don’t have react or react-dom installed with npm

alex-glv09:01:44

I think it’s cljsjs/react-dom issue, created a ticket: https://github.com/cljsjs/packages/issues/923

danielstockton15:01:31

with compassus, where can i find out the route params?

danielstockton15:01:05

nvm, i need to handle this myself in my set-route! method i believe..

danielstockton15:01:01

can params be passed to :index-route? its not so clear to me how i set params when the page loads

danielstockton15:01:40

should i pull them out of the url and set them in my initial app-state?

danielstockton15:01:06

it works, just don't know if its a best practice...why even set an :index-route and not just set that up in the initial app-state as well

tmulvaney16:01:41

@danielstockton in an om.next toy using bidi I stick it in the app-state under the key :route/params

tmulvaney16:01:01

(c/set-route! app handler {:params {:params route-params}})

danielstockton16:01:14

yeah, that's what I'm doing, just seems strange to pass :index-route to compassus without having the option to initialize params too

peeja17:01:51

@danielstockton FWIW, our :index-route just shows a spinner, then the history mechanism fires some kind of set-route!, even when the path is /

peeja17:01:34

Is the :easy-reads reconciler options documented anywhere? Looks like it just picks an implementation of transform-reads, but I'm not quite following the code. Is :easy-reads false a more thorough search that's less performant?

anmonteiro17:01:59

@peeja not documented and probably subject to removal soon

anmonteiro17:01:19

:easy-reads true just keeps whatever you passed in the read vector

anmonteiro17:01:47

if it's false it'll eliminate duplicates and such

peeja17:01:54

Ah, gotcha

ag18:01:15

That’s exactly what I’m trying to do, but the normalization not being kicked-off. I’m wondering now, maybe defcard-om-next (macro that @anmonteiro wrote) is doing something and Root component not being rooted properly?

ag18:01:29

basically I expect things to be automatically normalized if I have a component with an ident anywhere in the component graph, not just top level, right?

anmonteiro18:01:14

@ag yes as long as your non-normalized data matches your query structure

ag18:01:28

oh, it means that if I have final query {:root {:app/data ,,,, in the atom as well I have to have the same structure? I can’t just put :app/data at the top level?

ag18:01:11

is there anything I can do in read method for :root? since it’s just a “placeholder”? Right now what I’m doing is this {:value (parser env query)}

ag18:01:58

but then things don’t get normalized automatically, since the state-atom doesn’t have :root key

ag18:01:50

and :app/data is at the top level

ag19:01:55

do I need to use :pathopt somewhere maybe?

danielstockton20:01:44

interesting @peeja, sounds like a good idea to avoid a FOUC before the loader kicks in

danielstockton20:01:22

i trigger/remove my loader in send, either side of request/merge at the moment

ag21:01:06

geez… everytime I feel I get close, om throws temper tantrums. can someone explain to me. (db->tree) does not execute parser reads, right?

peeja21:01:17

@ag That's correct. The parser (often) uses db->tree.

ag21:01:35

so now I’m struggling to get the right query that a) being in the root will normalize data, b) pulls things based on given ident pointer out of normalized db

ag21:01:53

combining this too is giving me major headache

ag21:01:21

so, setting the right query in the root that resembles the structure of denormilized data in the atom forces reconciler to denormalize things. Now how do I include in the query part where I need specific data, that I want to grab via ident pointer e.g. [:list-data/by-id 1]

ag21:01:44

so my initial query that forces things to be normalized when I pull it with (get-query Root) looks like this: [{:root [{:app/domain-data [{:rows [:description]}]}]}], now in reality what I need is to pull data by ident, e.g. [{[:domain-data/by-id :resources] [{:rows [:description]}]}] but setting that kind of query in the root breaks normalization.

ag21:01:56

So I guess I need to combine them, but how?

ag21:01:59

oh I think I get it now. so I need to have a query with one part that still refers to whole :app/domain-data (also forces normalization) and then part with ident pointer that joins on some placeholder