Hi. Can anyone suggest, what this horrible error might be caused by? Using om-intermediate-template http://dpaste.com/209ZJK8

@andrewboltachev: I was able to create a project with lein new om-intermediate-template … and after I had setup a datomic instance a lein figwheel runs without problems. Did you change anything in the project.clj?

How do you pass a callback to an element? I’m trying to do this: https://github.com/awkay/om-tutorial/blob/master/src/tutorial/om_tutorial/B_UI_Exercises.cljs#L118

@pupeno: with om/computed

(om/computed % {:onDelete delete-person}) ?

yes

And then, to trigger the event from the button, this is not working: (dom/button #js {:onClick #(js/console.log "foo")} "X")

What am I missing?

you have to get your delete function out of computed in Person and put it into the onClick handler

akiel: yes, I know that bit, but the onClick handler the way I defined is not running.

I’m not getting “foo” on the console when I press the button.

the :onDelete they in the computed pros is only for you - it has no meaning regaring events

I know, I know, I’m just trying to get the button to do something first.

ok I see

Mh… now it’s working.

so, did the tutorial recommended onDelete because it’s a JavaScript property? why not on-delete? why even call the function deletePerson instead of delete-person? (yes, I’m asking at about the style)

I would use clojure naming style when possible

me too.

If you use sablono, you can even use clojure naming style for JS handlers

Does sablono replace om.dom?

yes

I’ll probably be using it. Thanks

its like hiccup

Do you know if it escapes values by default or is it an XSS waiting to happen (like, sadly, Hiccup)?

no I don’t know

This https://github.com/r0man/sablono#setting-innerhtml-of-a-dom-node seems to suggest it’s safe by default.

It is safe. It compiles Hiccup forms into React calls so only way to render arbitrary strings is through dangerouslySetInnerHTML

Thanks deraen.

following this https://github.com/omcljs/om/wiki/Intermediate-Tutorial

but i get an error that i can’t google for when trying to execute config/samples/free-transactor-template.properties

i get "-bash: memory-index-threshold=32m: command not found -bash: memory-index-max=256m: command not found -bash: object-cache-max=128m: command not found"

this is a property file it’s not executable

you have to execute bin/transactor transactor.properies after doing something to the template

so how should i interpret "run the following inside the directory”?

wait I don’t know the tutorial

there you have it: bin/transactor config/samples/free-transactor-template.properties

it says bin/transactor in front

it’s two separate files

i get another error if i only run bin/transactor

it’s just running the transactor with some properties

well, if im not supposed to do “. config/samples/free-transactor-template.properties” in terminal, i get "ConnectException Connection refused java.net.PlainSocketImpl.socketConnect (PlainSocketImpl.java:-2)” following the steps otherwise

is the transactor running? what does it output?

“Saving session... ...copying shared history... ...saving history...truncating history files... ...completed. [Process completed]"

is this what you meant?

no a typical output of the transactor looks like this:

datomic-free-0.9.5130 $ bin/transactor config/samples/free-transactor-template.properties
Launching with Java options -server -Xms1g -Xmx1g -XX:+UseG1GC -XX:MaxGCPauseMillis=50
Starting datomic:, storing data in: data ...
System started datomic:, storing data in: data

do you use linux or a mac and be in a shell?

i use terminal in a mac

not too savvy, otherwise i wouldn’t be following a tutorial

so whats the problem with the transactor?

I just unzipped the download and run the command from the tutorial

i get this now: "Launching with Java options -server -Xms1g -Xmx1g -XX:+UseG1GC -XX:MaxGCPauseMillis=50 -bash: bin/classpath: No such file or directory Error: Could not find or load main class clojure.main"

oh its working now

thanks for the help

you started the transactor inside the bin dir?

yes

you have to do it from outside

oh yeah i mean outside the bin directory sorry

I have an Om Next project that has a form that has a variable number of line items that are editable. The problem is that when the number of lines is large (e.g. 200 lines), there is a noticeable delay when typing characters into a text box on the form. This isn't an Om problem, but a problem with how I designed these text boxes. On each onChange an om/transact! is run and the state is updated. This causes a read of the root query, and I think the problem is that using db->tree in my read is taking enough time that the delay is noticeable (I am using the default db format and using links to each line item from the parent record). If I only load up a record with 20 lines, everything is faster. Here's a simple example that shows the problem: https://github.com/caleb/om-input-perf-example/blob/master/src/perf/core.cljs Is there a different way I should be handling onChange?

@caleb: you should try to avoid a full re-read when it's not nescessary, you can do that by placing idents at your line component, that way you can transact on it, making it refresh, avoiding a full re-read

Hmm, I have an ident on my StatementLine component, but my read function is still being called on the parent key (`:current/statement`)

Here’s my line item component’s ident: https://github.com/caleb/om-input-perf-example/blob/master/src/perf/core.cljs#L63

And I’m being sure to call transact! with the StatementLine component. The good news is that it is not re-rendering the entire form (only the line item), but it is still doing a full read

Hi. Can anyone tell what :pathopt option sent to reconciler means?

@andrewboltachev: :pathopt refers to path optimization

It's there to prevent a whole re-render when only a certain part of your ui transacts

Look into the NormTree example in the Om devcards to see how it works

@anmonteiro: thanks, and NormTree is exactly what I'm looking at

@andrewboltachev: so, in particular, look at the read method with dispatch key :node/by-id, this is where the magic happens

yep, I noticed that

Wouldn't it work w/o it?

:query-root there is set to the ident of the node that transacted

it wouldn't

I mean, the example would work without it, sure, if you set pathoptto false

also, IIRC, tutorial says "we have to provide read functions"

(in case we're implementing om/Ident)

not sure what you mean there

and I don't think it's true

me too, though

1 sec

https://github.com/omcljs/om/wiki/Components%2C-Identity-%26-Normalization#adding-reads

"Note that in this case we must supply read functions..."

@andrewboltachev: that refers to having to convert normalized data to the data we expect in our UIs

e.g. using db->tree

but here done manually, right?

right. the tutorial was written before db->tree

huh

anyway, where to dig if I face Uncaught #error {:message "No queries exist for component path (ex0001.core/App ex0001.core/AnimalsList)", :data {:type :om.next/no-queries}}?

(version is last one, updated couple of hours ago)

@andrewboltachev: there could be a number of reasons, if you put it in a gist I can look at it really quick

So what to do about the root component not re-rendering after the cb has been called with new data in the reconciler's :send function?

@anmonteiro: sure, here it is: https://gist.github.com/andrewboltachev/3061c19dcd35b1bcf000

@andrewboltachev: how do I trigger the problem=?

uhm... let me rather push the repo then

@andrewboltachev: no need

your queries must compose to the root

for example?

your PerspectiveSwitch component declares queries

that never get to the App component

so, in other words "parent" components must include all their children queries?

exactly

Is there any nice way for the root component of handling child query parameters other than dissecting the query via query->ast?

@anmonteiro: but query of PerspectiveSwitch is [:perspectives/list :perspectives/active] and query of App includes it: [{:categories/list [:db/id :category/name {:category/_parent ...}]} :app/title (:animals/list) :selected/animal :perspectives/list :perspectives/active]

Do you mean that it should rather look like {:perspective-switch <something>}?

@andrewboltachev: right, but the App component is using that query as its own

yes, it needs to be under a map key

@nano: 1st question: I'd start by looking if the app state gets properly updated

and go from there

@nano: 2nd question: haven't figured something out since you last asked that one

Humm.. I realized I had seen query-template mentioned here a while back, and found it in the tests.

@nano: query template is useful but it's private

Oh 😞

@nano: it's more of a utility thing that returns a zipper

1st question, app-state is being updated correctly when inspected in the repl, and if I reload my browser to get to the main page again, and enter the child component I selected last time, it will then display the already fetched data.

that's really odd because merge! queues the incoming keys for re-render

and merge! is something that's called via the cb passed to the :send function?

merge! is exactly what the cb is

ah, maybe i should just bite the bullet and start reading more source code instead of sticking with the documentation.

@anmonteiro: now it does look for :perspective-switch key, i.e. tries to read it: https://gist.github.com/andrewboltachev/3061c19dcd35b1bcf000#file-core-cljs-L215

is it the right form of query for child component now?

feel like not understandind at all how co-located queries work 😐

@andrewboltachev: it is, but you should be using get-query so that Om can calculate the paths

ah, so, probably metadata matters here

@andrewboltachev: yep.

just think of it like a modularity thing

and the Root being where all your "modules" meet each other

because when you add-root!, Om only has knowledge of one component, the Root

it must descend the query paths in order to be knowledgeable of the other components

i.e. your UI is a tree

but you already knew that

so, now when it looks for :perspective-switch, my read fn must return {:perspectives/list <...> :perspectives/active <...>}

I don't know, I haven't looked at anything besides the queries

i went through the om/next "Components, Identity & Normalization" demo and tried to add a remove button to remove a person from a list, but i'm getting a problem where the RootView/ListView do not update, so the deletion isn't shown even though the app state updates correctly

but I suppose so, if those are the keys in the join

anyone know what is wrong?

@anmonteiro: I mean it looks like duplication

@isak: depends where you're transact!ing; you might just need to add a key to be re-read after transact!

i.e. read fns duplicates what IQuery tree already knows about

@andrewboltachev: so that might be because you have structured your things the wrong way

there can always exist components that don't have queries!

ok, i'll look into that, thanks

@isak

oops

@isak: https://github.com/omcljs/om/wiki/Om-Next-FAQ#why-is-my-component-not-rerendered-after-transact

@isak also feel free to post your core.cljs file, as many others here went through the tutorial also

@anmonteiro: quick question: is it wrong to pass whole (om/get-props this) thing to a child component (say, when it uses the same data what parent is, i.e. when parent also does using the data)?

@andrewboltachev: it kinda smells from where I stand

I'd look into having a better structure of your app-state / UI components

as in, try to understand where things fit; start with a small example and go from there

@andrewboltachev: @anmonteiro : the tip about adding keys to reread with the transact call solved my issue, thanks!

@isak: cool! thanks to @anmonteiro actually. I think it's important to have ppl to succes with tutorials and do more attempts to solve problems with Om Next

from the docs I see that is also possible to provide a hint about what keys are affected in the mutate function itself, but that it does not affect re-rendering

does anyone know why it doesn't affect re-rendering? i'm worried that specifying it in the transact calls could lead to repetition

like if you have one mutation you want to run from 5 places in your app - it seems like you'd also need to specify the other keys affected in all those 5 places

@isak

oops again

do you mean :value :keys ?

yeah

@isak: the :keys in the mutation's value is sort of a documentation thing

@isak: if you're worried about repetition then just create a function that receives a component instance and performs the transact! call. Then you only write the keys to be re-read once

no one ever said that transact! needs to be directly invoked

thats true, though it seems like a missed opportunity, unless there is something i'm not getting

@anmonteiro: won't :value :keys work on the server also?

@andrewboltachev: depends on what you mean by "work"

they are supported, yes; they won't do anything, though. As I said, they are there just to provide documentation

so "supported" means there wouldn't be any error message, then

uh, right

are https://github.com/omcljs/om/wiki/Components%2C-Identity-%26-Normalization#adding-reads

'[:name :points] from 2nd snippet also for documentation purposes?

sorry where?

query part of defui Person

it's not for documentation purposes if it's an implementation of IQuery

I mean not for Person on itself, but in this particular case

No, in that case it actually serves a purpose

the fact that there are no render methods doesn't mean anything; the IQuery implementations (along with the Ident ones) in that case have the purpose of telling Om how to normalize the data

ah, there's get-query Person just below

though, anyway, what function would receive there as parameters?

I mean read-fn only obtains :list-one and :list-two keys, isn't it?

huh, it should rather obtain whole sub-query as a key

dunno if that's right thinking

@andrewboltachev: tree->db uses those

even if you don't call it explicitly, the reconciler will normalize the data for you when you add-root!

oh, that answers one of my first questions

with tree->db I should get rid of duplication I were afraid of

I hope you understand what I'm talking about, and it's something useful not meaningless 😄

also, a thing about idents it that ident fn doesn't know the name of the key which is unique

thus it isn't removed from map of normalized things

e.g.

:person/by-name
 {"John" {:name "John", :points 0}
; the rest}

Should data be normalized when it is returned from a remote source and passed into the callback from the send function?

it looks like it gets normalized but I can’t see the refs in the metadata

@tyler: does this issue break something?

not sure what you mean by break something. And I’m not sure if its an issue or I’m just incorrect in my implementation

say my remote returns: {:quay/images [{:name aat} {:name agronomy} {:name billing} {:name core} {:name weather}]}

and I call callback from the send fn with that edn data

what is the expected behavior

should the refs be added to the metadata of state?

@tyler: from what I know, read-fns always return data in "end-user" form

e.g. in tutorial https://github.com/omcljs/om/wiki/Components%2C-Identity-%26-Normalization#adding-reads

"Note that in this case we must supply read functions - our data will be normalized so we have to build the original tree form."

so, read-fn is to return "original tree form"

I haven't worked with remote parsers so I don't know for sure

IIRC David also said "parser is the thing we put into cljc file", so it should be no different then

@tyler: just in case check what version of om you're on and try on latest one from master

thanks

@anmonteiro: Guessing here, but I think that it might have to do with my hacking the params into the query. That way the query loses its meta. If I hardcode the params into the child, and use the original child component query, the changing of the child component works as expected. Haven't read up on the source, not sure where to start digging really.