This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-06
Channels
- # admin-announcements (10)
- # alda (78)
- # arachne (33)
- # bangalore-clj (2)
- # beginners (11)
- # boot (70)
- # chestnut (8)
- # cljsjs (5)
- # cljsrn (4)
- # clojure (212)
- # clojure-art (1)
- # clojure-berlin (1)
- # clojure-brasil (27)
- # clojure-canada (6)
- # clojure-colombia (12)
- # clojure-dev (6)
- # clojure-greece (29)
- # clojure-hk (2)
- # clojure-italy (7)
- # clojure-russia (51)
- # clojure-spec (12)
- # clojure-uk (18)
- # clojurescript (115)
- # clojurex (8)
- # component (1)
- # crypto (41)
- # css (5)
- # cursive (31)
- # datomic (17)
- # defnpodcast (7)
- # emacs (9)
- # flambo (1)
- # funcool (4)
- # juxt (29)
- # off-topic (1)
- # om (122)
- # onyx (12)
- # pedestal (1)
- # planck (10)
- # portland-or (1)
- # re-frame (30)
- # reagent (4)
- # rum (3)
- # slack-help (2)
- # specter (20)
- # sql (3)
@tmulvaney you can also do this (swap! app-state assoc :foo :bar :foobar :baz)
Has anyone ever had om removing data that you are still using when you are doing a lot of updates? I have a autocomplete component that searches for items that have an ident of [:entity/by-id z]
and I have three other collections with items that also use the same idents and when i start searching with the autocomplete it will start removing items that are rendered in the ui… Am i doing something wrong?
When I run (om/ref->components reconciler [:entity/by-id 17592186045752])
For one of my indents it will first have one component and then after an update from the autocomplete (which goes to a remote) it will return nil
Btw I am running alpha42
@dnolen thinking maybe we should also bump react to latest before beta1?
testing it locally now
@dnolen my patch to optimize recursive parsing introduced a regression
the parser
will actually be there on the first invocation so I need to find another heuristic
working on a fix
I'm pretty new to Om.Next (and Om in general) and still trying to wrap my head around some things. I think I understand most of the architecture, the reconciler, the parser and loading data from remotes. My doubt is about creating new data on the server using the UI.
Is there some built-in mechanism in which the mutate
function will talk to the remote just like the read
function may trigger the send
or I should send new data directly to the server using ajax, ws or anything else?
@samflores if you return :remote true
(or whatever the name of your remote is) in a mutation, the transaction will be sent to the server
Thank you, @anmonteiro.
so (om/transact! [(person/create! {:name “António"})])
will result in your server getting [(person/create! {:name “António"})]
means your server parser must know how to handle the person/create!
mutation
I have another question, specially for you, @anmonteiro 😄
I'm using compassus and I'm not sure how to define routes like /things/1
and /things/2
in a way the number could represent any thing id
@dnolen fixed in https://github.com/omcljs/om/pull/762 also submitted another one to bump React
@samflores right there has been some discussion about it
that concern was first brought by @cmcfarlen, and my response was that that’s not really a concern of Compassus
i.e. things like Bidi give you those parameters, which you can save to your app-state however you like
the actual thing that Compassus cares about is to switch your top-level component to Things
IMO it’s then the Things
component’s concern to know which element it wants to show
that's how I thought, but didn't managed to make it work last night. I'll keep that path. thank you
@samflores What I ended up doing that works great is to call om/transact!
and pass the pushy query parameters to a route/set-params
mutate fn that knows how to set up the state from the url information
Call om/transact!
from the pushy handler callback that is. Just before calling compassus/set-route!
@cmcfarlen seems like a pretty good idea. However I don’t like to perform 2 transactions for what should eventually just be one
maybe we could find a way to plug that transaction into the set-route!
call
feel free to open an issue to track that
@anmonteiro: sure. I'll make a simple example to demonstrate the approach so we have something to point at and discuss
awesome, thanks!
Mmh, I have an Om Next question. It's been a while. 😉
Is there any particular reason for the following difference? I.e., why is the key in the query result [:url _]
if the link is at the top level and why is it :url
if it's inside a join?
(parser {} '[[:url _]])
-> {[:url _] <value>}
(parser {} '[{:foo [[:url _]]}]
-> {:foo {:url <value>}}
Being aware of the second behavior, I was expecting the first query to result in just {:url <value>}
.
@jannis my question would be: are you using db->tree
in both cases?
hrm that just sounds odd
anyway, Links are only resolvable in db->tree
and using them at the top level just doesn’t make any sense
because you could just write [:url]
since the property is at the top level
I use a completely custom implement of read
against DataScript, so there's no denormalization etc.
My situation is more complex, as I'm wrapping read
in another function and the way the wrapping function calls the real read
makes the parser think the link is top-level even though it isn't. A slightly crude setup, I admit. At least I now understand that that's what causes the [:url _]
key in the result. 🙂
hrm I’m starting rethink the om/transact!
requirement that the component implement IQuery
I believe when I made this restriction I was focused on getting the query system right, and a component that triggers a transaction without a query was distraction
but it seems to me we can simply discard these components during render (they don’t implement query) and we’ll find the components that actually were listening for those properties anyway
@anmonteiro your opinion is welcome here ^ 🙂
@dnolen I tend to agree that we could relax that requirement
but not remove it entirely, i.e.: the root component must implement IQuery
but the above would then mean that people don’t need to structure their app so strictly for no reason
the only place that would need some love after that change would be reconcile!
@anmonteiro yes (my point about skipping those components that don’t know what they need)
oh, just skip them entirely
so what’s the difference between that and transacting agains the reconciler?
right
@dnolen gotcha, makes sense to me, but we need to document that if people transact!
against a component that doesn’t implement IQuery
, they necessarily need to provide keys to re-read
because nothing will be queued by default
@anmonteiro all om components have access to the reconciler, correct? wouldn’t it work the same way as just transacting against the reconciler?
the other alternative is to queue the first parent that implements IQuery
it would trigger a root render every time, which isn’t ideal
@ethangracer well.. get-reconciler
is supposed to be private 🙂
and I don’t see what would trigger a root render?
transact could conceivably be set up to be called on the reconciler if the component doesn’t have its own query
it’s definitely not the most efficient solution, but if they don’t provide follow on keys, their loss
transact!
always runs against the reconciler anyway
right, sorry I confused my words. without follow on reads would just trigger a root rerender
@dnolen this might be easier to implement than I thought
https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L928 we can just change this line
if it’s a reconciler or it doesnt implement IQuery
no need to mess with reconcile!
in that case I think
@anmonteiro so are you suggesting that if not iquery?
call get-reconciler
and make it the same case as reconciler?
@dnolen and as @ethangracer suggested, this will make the app always re-render from root
@anmonteiro always?
(because the queue will be empty)
that’s what I meant, sorry
me neither, it’s the same as transacting against the reconciler
it won’t actually re-render everything, we just can’t take advantage of incremental rendering there
React will still perform the diffing
definitely
another plus side is it makes for a very small diff 🙂
good if we don’t want to introduce regressions just before beta
Is https://github.com/omcljs/om/wiki/Error-Handling set before beta?
@dnolen just saw the commit, I still think we should check that at least the root should implement IQuery
calling it a night now, traveling early tomorrow
@anmonteiro hrm need to think about that - since everything is supposed to work even if you never implement IQuery (I thought we had that as a test case or something)
@dnolen but if you don’t implement IQuery
you can’t call the parser
and IMO Om Next apps should work without a parser
e.g. for plain React interop
@anmonteiro yes it should work without the parser, but where is this going to be a problem?
well it’s not a problem if people don’t call transact!
which you probably won’t anyway, so I’m fine either way
@anmonteiro ah you’re just talking about some validation here
it would just serve validation purposes, basically
maybe even an invariant
would suffice
instead of a hard assert
I wonder why passing down a state to a component that doesn't implement IQuery can't be ok even if using transact. I know it would cause the component to lose its state. But why does it have to be like this, just open thougt as user. (there is to say give a factory a map).
@anmonteiro https://github.com/omcljs/om/commit/d3a0a16e954a7619e93bc7490b588cbfe122baaf
Its not a problem as I know to implement IQuery. But if I render a component that reads a global state, but after rerender I wouldn't want to re-read that state, but still keep it like it was at mounting time. I know ways around this. But it would be nice (if that comes at no cost) to just say from root component (render [this] (factored-component {:a "state" :that "stays"])
@anmonteiro safe travels!