This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-01-06
Channels
- # admin-announcements (266)
- # alda (20)
- # announcements (1)
- # aws (16)
- # beginners (16)
- # boot (288)
- # brevis (7)
- # cljs-dev (40)
- # cljsjs (32)
- # cljsrn (5)
- # clojars (23)
- # clojure (169)
- # clojure-art (2)
- # clojure-czech (3)
- # clojure-finland (1)
- # clojure-italy (3)
- # clojure-norway (1)
- # clojure-russia (88)
- # clojure-sg (3)
- # clojurescript (300)
- # clojurewerkz (8)
- # community-development (14)
- # component (4)
- # core-matrix (1)
- # cursive (9)
- # datavis (26)
- # datomic (44)
- # devcards (3)
- # funcool (1)
- # hoplon (7)
- # jobs (4)
- # ldnclj (11)
- # lein-figwheel (1)
- # nyc (2)
- # off-topic (4)
- # om (149)
- # onyx (1)
- # overtone (1)
- # parinfer (15)
- # proton (3)
- # re-frame (9)
- # reagent (45)
- # yada (2)
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?
@esnunes the solution isn't official, but dnolen has stated that this is a good idea and might incorporate in future Om
thanks @jethroksy
I’ve noticed some inconsistent sample code for generating the tempid map in a remote parser. If you compare https://github.com/awkay/om-tutorial/blob/6cae13ebd704b02254e443897b7963dcab35304c/src/main/om_tutorial/simulated_server.cljs#L36 against https://github.com/akmiller78/tut-omnext-tempids/blob/3334db2f08a68b022a51548a74b0af3fc9ff3507/src/om_a_1/core.cljs#L126 you can see the difference
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?
@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
mine is using the built in migrate functionality
that being said i don’t believe there is any reason they have to be ident’s….mine is because i’m using idents
@adammiller: thanks for that. In that case I’ll follow Tony’s since it keeps the clients ident structure out of the server code.
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
@raphael: depends on what your use-case is
you can have an Om version and an Om Next version of your project in the same repository if that's what you mean
and share whatever common utility code you have
sharing code across Om & Om Next in terms of components / lifecycle is not possible
@raphael: I've got an example project which has two versions, one in Om and one in Om Next
they share the same repository
in case you're curious: https://github.com/anmonteiro/deathrow
@anmonteiro: thank a lot
anyone got nice resources on testing om.core state?
I'm nicely testing component outputs, but now I just want to test my transaction helpers and don't know how to do it
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 😞
@nxqd: try (js/React.createElement cell "props" "children")
"props"
and "children"
should obviously be replaced by the props and the component's children
@iwankaramazow: #C0DT1AZD3 isn't regularly checked
why doesn't my query compose to root?
I think I'm using get-query at every stage
the query is working, when opening the website, it loads all data just fine
changing params of a query however seems to trigger a problem
should I file an issue?
@iwankaramazow: your RootView is stealing ThResultTableView's query
this is a no go
what does 'stealing' mean in this case?
that RootView is using ThResultTableView's query as its own
it should be under a keyword
ah yea, that makes sense
I'll check it out right now
Anmonteiro, Jethroksy Thanks for the response, it seems I resolved the issue
Thanks a lot! (I'll check out that tutorial)
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.
@geraldodev: there are a number of things that can be going wrong; a gist is more helpful in getting people to help
@anmonteiro: I'm using last om (making the gist atm),
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.
Another solution would be to remove the temporary datum before transacting the permanent one, meaning there is no need for any migration
Please disregard the render function building the form using the keys from get-query and using local state.
what's gconn
?
some datascript connection?
@geraldodev: In the gist you're not passing down any props to (cliente)
. Is that intended?
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
@jannis yes it is intended
@geraldodev: that's what's causing it to receive nil
You have to pass query results down to children via props. That's not happening magically.
@anmoneiro but why just on 1st pass
@jannis makes sense but why on the 2nd pass it receives the value ?
@jannis even without being explicitly passed as suggested
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.
Fix your (cliente ...)
call anyway, that should make it work. If you don't, that's an issue in your own code.
Thnx @jannis and @anmonteiro
hey pals, any resources on using om next with REST endpoints before migrating backend to understand the query language?
@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 😄
@nxqd: glad you solved it
@hugobessaa: have you seen https://github.com/omcljs/om/wiki/Remote-Synchronization-Tutorial#building-a-simple-auto-completion-widget ?
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
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
@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?
@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
for instance @henriqueqc a common pattern (when using component state is this:
(dom/input #js {:type "text"
:placeholder "Firstname"
:value (om/get-state this :first-name)
:onChange #(om/update-state! this assoc :first-name (.. % -target -value))})
@anmonteiro: I got this error while trying your lein template for om next goog.dom.DomHelper is not a constructor : line 34 history.cljs
@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?
@nxqd I got that too, had to require goog.dom and changed it to (let [dom-helper (gdom/DomHelper.)]
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
@adammiller: cool, thanks 😄
can also use app-state if you prefer to keep it all there and avoid local component state
@nxqd: @adammiller will update accordingly, thx
@anmonteiro: yeah, sorry i should’ve submitted a pull request when i noticed it the other day
@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.
@anmonteiro: I just send the pull request
@nxqd: @adammiller: actually open to PRs if you've got it working
@henriqueqc: right so here is an example form i had https://gist.github.com/akmiller78/e14bb779cb8950405e98
@nxqd: you just closed your own PR.
was that intended?
@adammiller: Thanks.
@nxqd: thx, it's up on clojars
thanks @adammiller btw 😄
no problem
Does anybody know if om.next/db->tree
doesn't work when keys are string?
seems it only works w/ keywords?
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?
(def init-data { :year/current {"year" "2015"}})
vs (def init-data { :year/current {:year "2015"}})
for example as init-data
a read
-function reading {:value (om/db->tree query (get st key) st)}))
seems to only read the one with :year
in...
actually nevermind, I think I found some issues in my code 🙃
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?
^Should those children from the union (`:dispatch-key :narrative` :dispatch-key :table
:dispatch-key :image
) not have a :query
and :children
of their own?
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
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?
@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.
when did selector change to query in the read fns?
@danielstockton: maybe 2 months ago
ok, i was on alpha22 before and just updated to 28
Are there any examples out there for a custom merge function? apparently the default merge rewrites parts of my state with nil 🙈
@iwankaramazow: try this https://github.com/stevebuik/om-next-ideas/blob/73e22ec9cab12d0caded6b012d74b80c14a9d1a2/src/cljs/om_next_ideas/app/core.cljs#L47
Thanks!
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
@tmorten I have the routing parameters as QueryParams on my RootView, which are then passed to the queries that need them
has been working well enough for me, except that figwheel nukes the QueryParams on reload
Never mind, I think I sorted the above issue out
@tmorten: david's post inspired it: https://github.com/omcljs/om/wiki/Routing-Support
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
@dnolen it's been working well for me, apart from the params being reset when figwheel reloads the component... any suggestions for that?
@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
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
@tmorten: yes, in the early days I would have said not, but from a routing perspective that approach makes sense