This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-04-15
Channels
- # admin-announcements (10)
- # aws (2)
- # beginners (27)
- # boot (3)
- # cbus (4)
- # cider (1)
- # clara (6)
- # cljs-dev (3)
- # cljsrn (14)
- # clojure (98)
- # clojure-boston (1)
- # clojure-brasil (1)
- # clojure-czech (3)
- # clojure-dusseldorf (11)
- # clojure-greece (3)
- # clojure-japan (3)
- # clojure-korea (1)
- # clojure-russia (138)
- # clojure-uk (11)
- # clojurescript (76)
- # component (2)
- # core-matrix (1)
- # cursive (25)
- # data-science (3)
- # devcards (1)
- # euroclojure (4)
- # events (3)
- # funcool (1)
- # hoplon (219)
- # immutant (40)
- # juxt (8)
- # leiningen (1)
- # off-topic (34)
- # om (148)
- # onyx (10)
- # overtone (2)
- # proton (1)
- # re-frame (8)
- # reagent (3)
- # ring-swagger (5)
- # spacemacs (17)
- # untangled (47)
- # yada (19)
is there a core.async
-based implementation for om.next.server
?
@marianoguerra: you can check the error from the send function. If you want to interact with the app, just assoc some error message to the next state, and it will be merged to the app.
@settinghead: core async based server ? what do you really want from it ? I'm curious
I was thinking about 'async read' when considering localforage, which has a callback API. I switched to directly using the synchronous localStorage API instead of thinking more about it
I have an opportunity to transfer one little part of a codebase to Om Next though it’s not using Om (using dommy) where should I start? Afraid it might conflict with Om now code being used elsewhere.
strange: this doesn’t actually work for me https://github.com/omcljs/om/wiki/Thinking-With-Links! - the linked item current-user
is always nil
@urbanslug: what i did is to have some front end routes that need om.next, and some that need om now, and then added logic to mount and unmount om versions as needed
isak: another quick one did you encounter any issues with having both dependencies on the same project i.e did the different versions of react conflict?
oh and for react i just excluded it, because we were already using it before using om at all
I am trying to figure out how links (https://github.com/omcljs/om/wiki/Thinking-With-Links!) are intended to work. After reading the links page a few times, I expected the parser to invoke my read method at the root with the link key. This does not seem to be the case (my read method is not invoked with the link key). I am using a datascript db as my application state. As an example, if I specified the query of a component deep in the hierarchy as
'[:id :title [:current-user _]]
, I would expect the parser read method to be invoked similar to (parser {:state conn} '[[:current-user _]])
, which is not the case.Are links the right option to use when I need a portion of a component's query to be looked up at the root?
Are there known issues with Om Next where components suddenly have an omcljs$reconciler
that is nil
?
@symfrog: I really struggled with that tutorial because of this: https://github.com/omcljs/om/issues/670
Having said that, however, after getting the dependencies right in the tutorial, I then couldn’t get Links to work in my own project (outside the basic, basic tutorial). Still stumped as to why.
alpha24 seems to be the release in which Links start working.
I have this one component, where omcljs$reconciler
, omcljs$parent
etc. are nil
about 50% of the time. It happens with no other components. It's really odd.
@kendall.buchanan: thanks, I am using alpha32 at the moment and seeing the behavior described after following the tutorial, does that issue mean that there is different documentation to use links somewhere that I am not finding?
@jannis we had an om gotcha the other day where if you do (om/get-query MyComponent), but then you tamper with the result, you lose (meta) information required by om
I never mess with get-query
results for that particular reason (breaking meta data). I think this may be a problem between Sablono and lazy children created with for
.
Yep, it seems like forcing children with doall
or mapv
solves the problem. There are good reasons why Om Next forces children by default. Sablono might not.
@kendall.buchanan: FWIW, I found this related issue: https://github.com/omcljs/om/issues/501
@symfrog: No idea. I’m also using alpha32, and can’t for the life of me get Links to work in my non-tutorial project. If I wasn’t so lazy (and there wasn’t a non-links workaround) I’d go back and do the tutorial over again in alpha32 rather than 24. But yeah, I’m not using datascript, so no insights from me there.
Ah, sorry, now understood your question: the issue I posted on om.next about documentation was simply pointing out the difference version dependencies between the two tutorials. So, no, I don’t know of any alternative documentation.
@kendall.buchanan: no problem, already helps to know I am not the only one struggling with it, thanks
@kendall.buchanan: links are supposed to "just work" but you need to be using the default db format and db->tree
@anmonteiro: By default db, you simply mean passing a map of data as your state (as opposed to datascript)?
by default db I mean normalized data
Okay, right.
Okay, I just refreshed my memory as to what about it didn’t seem right...
If I understand correctly, links should be available to subcomponents without being referenced in the root component...
correct
Om was requiring that I provide a read
function in spite of the ident syntax (e.g. [:user _]
).
So I resorted to [:user]
, and provided a read function.
your queries might not be correctly composed
or structured
I don’t doubt I’ve done something wrong; it just hasn’t been obvious.
happy to have a look at the component query
Thanks, lemme see if I can provide something that doesn’t take up too much space...
Annnnnnnnd…
right
so the query for Assessment
is wrong
it’s not a link...
should be '[[:user _]]
K, I fat fingered that in my scissoring...
Updated it; still produces the same error.
Good catch, though.
core.cljs:9856 Uncaught Error: No method in multimethod 'course.component.reconciler/read' for dispatch value: :user
@kendall.buchanan: what does your parser look like
i.e. what multimethod keys does it have
Pretty standard, :read and :mutate.
Sorry, I hate to vomit my whole app into your lap. Thanks for looking at this.
@kendall.buchanan: I should have been more explicit
I meant what keys does the read dispatch on
Quite a few...
Is there a chance there’s overlapping coupling?
well, the ones that are related to that path
Do you mean related to the :activities/current
path?
To be clear, nothing in the app operates on the :user
key, which is at the root of the state.
you’re most probably using recursive parsing
Yes, definitely.
where you should be using db->tree
in the :activities/current
multimethod
Ah, I see...
Perhaps the recursion isn’t adequate to support a link?
I’m not exactly sure why you would use recursive parsing in that case?
just returning :value (db->tree …)
should work?
I’m really new, and this might stem from me hoping to use Om in a fundamentally flawed way...
What I showed you was a stripped down version of the component. In reality, I’m using queries to compute a variety of different fields.
That’s the more complete version… but you can see it’s conj’ing on from another multi-purpose query.
:answers/chosen
and :questions/current
, I also want computed.
Hence the recursion. Perhaps I’ve missed something simple?
@anmonteiro: I might simply need more experience with Om before the answer becomes clear, cause I might just be slaughtering the queries, for all I know.
the structure seems OK from a high level standpoint
but you might be able to get your result by just using db->tree
anyways, if you’re recursing the parser, maybe remove what has been computed by db->tree
already
in this case, the :user
link
Sweet! Removing recursion fixed the link.
Of course, I’ve broken my app, but that solved the mystery.
Thanks for entertaining that, @anmonteiro.
@nxqd: i checked the code for the server-side parser for om.next, and it seems that it assumes that mutation function that was passed into it is synchronous. in other words, i can’t have a mutation function that returns a core.async
channel. in my mutation function, i’ll have to block my thread to get the results, and return it
Hi, I was wondering if someone can help me clear up a confusion I have with om-next. I'm having difficulty getting the app to only re-render components whose state has changed---instead it always re-renders everything on every state change! Unless I'm missing something fundamental, this isn't supposed to happen, right?
ok that's interesting---I had thought om/Ident was only for normalisation; i'll give it a try
@thomasa: not sure I understand your problem, it seems to me that all those components are supposed to re-render
hmmm... I've added static om/Ident
methods to each component and the app still works, but the same undesirable behaviour continues
@anmonteiro: surely only the first of the two BooleanBox
s should re-render? the contents of :b
hasn't been changed.
ah right
I’ll try your example in a bit and get back to you
i remember reading earlier that when you transact, it will use the ident and query of the component you send in in order to determine what to re-read. but i don't see that in the api docs anymore
@isak: I don't think I can---in this case the transact is fired by a button on the root component so it doesn't have the BooleanBox to hand
I'll give it a try with the transact coming from a different place, but I feel like it shouldn't matter where it comes from---the rendering process should only depend on the old state and the new state, surely?
ah I've been messing around with trying different things, and I've suddenly fixed the problem
well i think determining what to re-render based on the query and ident of the invoking component was added as convenience, but you can also specify additional keys
https://github.com/omcljs/om/wiki/Om-Next-FAQ#why-is-my-component-not-rerendered-after-transact
After the transaction, Om implicitly updates the initiating component based on its query.
i could see how it creates a problem for your app, but i'm not sure if that often comes up in real apps
Right, I see what you mean about using the originating component as a convenience; thanks for all your help. I've basically convinced myself now that the issue was entirely because I was using an old version alpha-22
rather than the latest... apologies to everyone---it was silly of me not to check that before asking here.
Hi, is there any kind of information on how tempids are intended to be used yet? (documentation/blog post/etc)
@drcode: there’s an example here: https://github.com/awkay/om-tutorial/blob/master/src/cards/om_tutorial/om_specs.cljs#L14
also happy to clarify any real-world doubts you might have
Thanks @anmonteiro- That makes it very clear for now. BTW, I'm still getting back to you as we discussed, just super busy atm...
for sending data to the server, what do people usually do? do you basically send back data that looks like what you'd get as a response from a query?
hi, I’d like to generate an ul/li
list for pagination. for the li
I need to have keys, as I see in om-next there is a way to define keyfn
but for a whole component. I started to decompose my paginator component, but it feels overcomplicated. Is there a way to define keys for the li
generated inside of render?
@fifigyuri: (dom/li #js {:key 1})
@anmonteiro: I use sablono that simple scheme did not seems to work
@fifigyuri: so [:li {:key 1}]
should work
or something like that
@anmonteiro: works, thank you. I noticed something I can not explain yet. I have this pagination component on the top and bottom of the page. Both are the same hanging on the same query. When I click on any of it (top or bottom) it updates, but the other one does not. But when I go to the other one and click prev or next it skips to the place where it should. So it seems like the other component is not re-rendered, only the one where the transact was issued.. Any ideas why that can be?
@fifigyuri: transact!
will queue the component that called it for re-render
you need to specify keys to be re-read after the transaction call such that the components that hold those keys are correctly re-rendered
https://github.com/omcljs/om/wiki/Om-Next-FAQ#why-is-my-component-not-rerendered-after-transact
thanks, that explains that, but I’m wondering why the other pagination component is not queued too, although it’s outside the component of the transact!
, but it’s declaring the same keys
@fifigyuri: by keys I mean the query keywords, yes
Om will queue the component instance
so the other instance that has the same keys won’t be queued
this makes sense because not every instance of a component needs to be re-rendered in most cases