Clojurians
#om
<
2016-01-06
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

esnunes00:01:15

Hi guys, I have a noob question. I develop node+react universal apps, I'm learning clojure/clojurescript and in short future I want to be able to develop "universal" om apps. Do you have some reference material of how to develop "universal" om apps?

jethroksy01:01:36

@esnunes the solution isn't official, but dnolen has stated that this is a good idea and might incorporate in future Om

esnunes01:01:12

thanks @jethroksy

steveb8n05:01:07

can anyone clarify which is correct or are both valid? In other words are tempids returned the client as ident vector pairs or just id pairs?

adammiller06:01:37

@steveb8n: both are valid, however tony’s is using a custom migrate function to update the id’s as you can see here: https://github.com/awkay/om-tutorial/blob/6cae13ebd704b02254e443897b7963dcab35304c/src/main/om_tutorial/core.cljs#L40

adammiller06:01:14

mine is using the built in migrate functionality

adammiller06:01:06

that being said i don’t believe there is any reason they have to be ident’s….mine is because i’m using idents

steveb8n06:01:19

@adammiller: thanks for that. In that case I’ll follow Tony’s since it keeps the clients ident structure out of the server code.

raphael11:01:38

Hello, can I work with om and om-next in the same project? is it the right place to ask this kind of question? thanks

anmonteiro11:01:25

@raphael: depends on what your use-case is

anmonteiro11:01:04

you can have an Om version and an Om Next version of your project in the same repository if that's what you mean

anmonteiro11:01:13

and share whatever common utility code you have

anmonteiro11:01:35

sharing code across Om & Om Next in terms of components / lifecycle is not possible

anmonteiro11:01:00

@raphael: I've got an example project which has two versions, one in Om and one in Om Next

anmonteiro11:01:03

they share the same repository

raphael11:01:40

@anmonteiro: thank a lot :simple_smile:

hugobessaa11:01:56

anyone got nice resources on testing om.core state?

hugobessaa11:01:38

I'm nicely testing component outputs, but now I just want to test my transaction helpers and don't know how to do it

nxqd12:01:36

hi guys if I have cell as (def cell (js/React.createFactory js/FixedDataTable.Cell)), how do I present <Cell>City</Cell> in om. I have tried (cell "City") but it's not right way :disappointed:

anmonteiro12:01:38

@nxqd: try (js/React.createElement cell "props" "children")

anmonteiro12:01:12

"props" and "children" should obviously be replaced by the props and the component's children

nxqd12:01:25

ok, cool let me try it

jethroksy12:01:26

@iwankaramazow: #C0DT1AZD3 isn't regularly checked

iwankaramazow12:01:44

why doesn't my query compose to root?

jethroksy12:01:44

about 99% of the discussion here is Om Next anyway

jethroksy12:01:18

you need to use get-query

jethroksy12:01:03

eh my bad must've misread

iwankaramazow12:01:51

I think I'm using get-query at every stage

jethroksy12:01:09

did you get it flipped?

iwankaramazow12:01:20

the query is working, when opening the website, it loads all data just fine

iwankaramazow12:01:50

changing params of a query however seems to trigger a problem

iwankaramazow12:01:18

should I file an issue?

jethroksy12:01:00

I think you should wait for the more experienced ones to reply

iwankaramazow12:01:25

ok :slightly_smiling_face:

jethroksy12:01:43

can't really help, haven't had the time to look at Om for a while

anmonteiro12:01:53

@iwankaramazow: your RootView is stealing ThResultTableView's query

anmonteiro12:01:11

this is a no go

iwankaramazow12:01:29

what does 'stealing' mean in this case?

anmonteiro12:01:49

that RootView is using ThResultTableView's query as its own

anmonteiro12:01:59

it should be under a keyword

jethroksy12:01:02

it has to be under a keyword

iwankaramazow12:01:20

ah yea, that makes sense

iwankaramazow12:01:56

I'll check it out right now

jethroksy12:01:30

under "Common Mistakes"

iwankaramazow13:01:09

Anmonteiro, Jethroksy Thanks for the response, it seems I resolved the issue

iwankaramazow13:01:19

Thanks a lot! (I'll check out that tutorial)

geraldodev13:01:06

Notice that CreditoApp (the root) already has received its props, but in the 1st pass Cliente (the inner one) receives nil. As long I interact with a text box (another pass) the inner component receives the value.

anmonteiro13:01:05

@geraldodev: there are a number of things that can be going wrong; a gist is more helpful in getting people to help

geraldodev13:01:23

@anmonteiro: I'm using last om (making the gist atm),

danielstockton13:01:31

Are there any example apps yet with datascript/datomic? Quite interested in what solution people have for tempid migration after optimistic mutations. Creating a second id attribute just for this seems hacky.

danielstockton13:01:10

Another solution would be to remove the temporary datum before transacting the permanent one, meaning there is no need for any migration

geraldodev13:01:55

Please disregard the render function building the form using the keys from get-query and using local state.

anmonteiro13:01:44

what's gconn ?

anmonteiro13:01:48

some datascript connection?

jannis13:01:16

@geraldodev: In the gist you're not passing down any props to (cliente). Is that intended?

geraldodev13:01:57

the inner component is called at line 80, if you comment it and instead of passing nothing you pass {:foo :bar} instead of nil on the 1st pass it ll receive {:foo :bar} and the subsequents it ll be the correct value

geraldodev13:01:07

@jannis yes it is intended

anmonteiro13:01:17

@geraldodev: that's what's causing it to receive nil

jannis13:01:43

You have to pass query results down to children via props. That's not happening magically.

geraldodev13:01:47

@anmoneiro but why just on 1st pass

jannis13:01:14

(cliente (:form-cliente (om/props this))) should do it.

geraldodev13:01:55

@jannis makes sense but why on the 2nd pass it receives the value ?

geraldodev13:01:02

@jannis even without being explicitly passed as suggested

jannis13:01:35

I don't know, so I can only guess that perhaps your g-conn changes, causes the reconciler to schedule a rerender and somehow alters the props based on the indexer query -> component information. It could be a bug.

jannis13:01:33

Fix your (cliente ...) call anyway, that should make it work. If you don't, that's an issue in your own code.

geraldodev13:01:24

Thnx @jannis and @anmonteiro

hugobessaa14:01:11

hey pals, any resources on using om next with REST endpoints before migrating backend to understand the query language?

nxqd14:01:51

@anmonteiro: actually if we define (def cell (js/React.createFactory js/FixedDataTable.Cell)) we can call it like this (cell #js {:props {} :children []) , it's a bit shorter btw :smile:

anmonteiro14:01:46

@nxqd: glad you solved it

nxqd14:01:27

does anyone try to implement fixed data table in clojurescript yet ? I'm a bit confused that, where is that rowIndex defined in cell. And how do we get that prop in clojurescript https://github.com/facebook/fixed-data-table/blob/master/examples/ObjectDataExample.js

henriqueqc15:01:07

I'm experimenting with forms in om-next. It seams like a good idea to use component local state to track the input field's value. After looking through the code in dom.cljs the react form components are already wrapped to track state changes in a "value" state prop. However the "value" prop is only updated if a onChange handler is set. Is this intentional? I'm using an empty handler just to trigger the update. Maybe line 27 should be outside the "when-not" clause? https://github.com/omcljs/om/blob/master/src/main/om/dom.cljs#L27

adammiller15:01:30

@henriqueqc: not sure I understand how you are using it. The input itself is a react component so the only way to hook into it to know what its value is would be to provide the onchange handler and grab the value out at that point. How are you getting the value with an empty handler?

denik15:01:57

@jannis @geraldodev I experience something similar. Often some keys of the queries are nil in my props other times they’re not which really messes up updating components based on diffing changes

adammiller15:01:54

for instance @henriqueqc a common pattern (when using component state is this:

adammiller15:01:03

(dom/input #js {:type "text"
                        :placeholder "Firstname"
                        :value       (om/get-state this :first-name)
                        :onChange    #(om/update-state! this assoc :first-name (.. % -target -value))})

nxqd15:01:31

@anmonteiro: I got this error while trying your lein template for om next goog.dom.DomHelper is not a constructor : line 34 history.cljs

henriqueqc15:01:38

@adammiller: I'm getting the children of the form on the onSubmit handler and asking for the value of each imput. The pattern you suggested will save the value of each input in the parent component, so you can access it directly right?

adammiller15:01:26

@nxqd I got that too, had to require goog.dom and changed it to (let [dom-helper (gdom/DomHelper.)]

adammiller15:01:20

right, so ideally your form would be a react component that will track the changes of all your fields which are all react components…so then on submit you just grab the props from your local state on the form

nxqd15:01:59

@adammiller: cool, thanks :smile:

adammiller15:01:59

can also use app-state if you prefer to keep it all there and avoid local component state

anmonteiro15:01:32

@nxqd: @adammiller will update accordingly, thx

adammiller15:01:25

@anmonteiro: yeah, sorry i should’ve submitted a pull request when i noticed it the other day

henriqueqc15:01:29

@adammiller: I guess the down side of getting the value from the children is that the onSubmit handler has to know about the dom structure of the component. In your approach it only has to know the keys in the local state or the app state.

nxqd15:01:51

@anmonteiro: I just send the pull request :simple_smile:

anmonteiro15:01:09

@nxqd: @adammiller: actually open to PRs if you've got it working

adammiller15:01:53

@henriqueqc: right so here is an example form i had https://gist.github.com/akmiller78/e14bb779cb8950405e98

anmonteiro15:01:54

@nxqd: you just closed your own PR.

anmonteiro15:01:59

was that intended?

nxqd15:01:51

yes, there was a mistake on that PR. I just create a new one.

henriqueqc15:01:17

@adammiller: Thanks.

anmonteiro15:01:46

@nxqd: thx, it's up on clojars

nxqd15:01:03

nice :smile:

nxqd15:01:17

thanks @adammiller btw :smile:

iwankaramazow17:01:09

Does anybody know if om.next/db->tree doesn't work when keys are string?

iwankaramazow17:01:27

seems it only works w/ keywords?

oahner17:01:32

I'm a bit confused.. From what I can tell, links are handled by db->tree, so what do you do if you have a link at the root of your query?

iwankaramazow17:01:58

(def init-data { :year/current {"year" "2015"}}) vs (def init-data { :year/current {:year "2015"}}) for example as init-data

iwankaramazow17:01:44

a read-function reading {:value (om/db->tree query (get st key) st)})) seems to only read the one with :year in...

iwankaramazow17:01:57

actually nevermind, I think I found some issues in my code :upside_down_face:

zalky17:01:42

Hi, all: I've been experimenting with om.next union queries and datascript: https://gist.github.com/zalky/aca0caecb93e11ea416c The above code is very similar to the union queries tutorial, except that it uses datascript to store state. It clearly states in parser.cljc that the "Om Next query expression syntax is not a strict superset of Datomic Pull". Given that there is no mention of unions in datomic or datascript pull docs, it is therefore not surprising that the above code chokes on the union query when passed directly to a datascript pull. So: 1. I'd just like to confirm that an om.next query with a union cannot be passed directly to a datomic/datascript pull expression. I just want to make sure I'm not missing anything. 2. Is it required that we implement a recursive read of any om.next query containing a union? If that's the case, how do we implement a read for a union when the ast does not provide a query attribute for unions?

zalky17:01:53

^Should those children from the union (`:dispatch-key :narrative` :dispatch-key :table :dispatch-key :image) not have a :query and :children of their own?

tmorten18:01:03

I was working on using secretary in some shape or form with Om.Next...can anyone tell me if this seems legit in handling routing using specific path parameters? https://gist.github.com/tylermorten/24ba8c404708c452b0de

tmorten18:01:41

left out the parser for brevity

oahner19:01:26

I have a recursive parser that has to handle links like [:page/current _] at any point in a query, but :page/current is not actually in my state so I can't just use db->tree, so I call the parser again with the link, and it works fine, but then the parser returns {[:page/current _] {:title "Current page}} whereas in the same context db->tree would return {:page/current {:title "Current page"}}, which makes a lot more sense to me... Is that expected?

oahner19:01:01

Basically, shouldn't parser handle converting links into keywords?

oahner19:01:20

Hopefully my terminology makes sense...

tmorten19:01:24

@oahner: My thought was that the "link" and/or path parameters are just apart of what I consider the global state of the application. But I guess, I am just prying into how people have approached this with secretary or other client side routing.

oahner19:01:41

@tmorten: Sorry, that wasn't actually related to your question

tmorten19:01:43

@oahner: gotcha...my bad

danielstockton19:01:03

when did selector change to query in the read fns?

anmonteiro19:01:34

@danielstockton: maybe 2 months ago

danielstockton19:01:40

ok, i was on alpha22 before and just updated to 28

iwankaramazow20:01:01

Are there any examples out there for a custom merge function? apparently the default merge rewrites parts of my state with nil :see_no_evil:

chris-andrews21:01:10

Is anyone returning an ast in their read function? When I call my parser in remote mode and just return {:test ast} from my read function, I get the query wrapped in an additional vector (e.g. [[:key]] when I was expecting [:key]). I’m wondering if this is the expected behavior or not

rafd22:01:24

@tmorten I have the routing parameters as QueryParams on my RootView, which are then passed to the queries that need them

rafd22:01:22

has been working well enough for me, except that figwheel nukes the QueryParams on reload

chris-andrews22:01:28

Never mind, I think I sorted the above issue out

tmorten22:01:49

@rafd: curious, how do u feed those into your RootView?

tmorten22:01:26

set-query! ?

tmorten22:01:29

@rafd : I read this and got the feel that set-query! May be discouraged

rafd22:01:08

I thought it was pro set-query "Instead the documentation should naturally lead users to consider applying set-query! to the root component to accomplish their goal."; david also improved set-query afterwards to make it easier to use outside of components

dnolen22:01:54

@rafd it is pro set-query

rafd22:01:05

@dnolen it's been working well for me, apart from the params being reset when figwheel reloads the component... any suggestions for that?

dnolen22:01:06

@rafd (defui ^:once Foo …) is a thing

dnolen22:01:26

it prevents blowing away the class - just hot-loading methods

rafd22:01:25

@dnolen awesome, I didn't know it hot-loaded the methods; thanks

dnolen22:01:01

we do love our hot-loading in the Clojure world :wink:

tmorten23:01:02

@dnolen: so set-query! is OK at the root level then? I think perhaps I just read this wrong initially. I was trying to figure out how to get the route info into my global app state instead since that was where I thought it may belong. But @rafd way is much simpler

rafd23:01:12

I had it in my global app state initially, but it became a problem when i needed route parameters (such as an id) to be passed to a query (both in client and server)... doing it with params has solved that issue for me

dnolen23:01:38

@tmorten: yes, in the early days I would have said not, but from a routing perspective that approach makes sense

tmorten23:01:58

@dnolen & @rafd: thank you for making this clear for me. I am loving the direction that Om.next has taken!

rafd23:01:35

glad to help