This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-08-11
Channels
- # admin-announcements (1)
- # aws (2)
- # beginners (32)
- # boot (147)
- # capetown (1)
- # cider (11)
- # cljs-dev (45)
- # cljsrn (57)
- # clojure (187)
- # clojure-russia (5)
- # clojure-spec (97)
- # clojure-uk (33)
- # clojurescript (33)
- # cloverage (17)
- # clr (4)
- # conf-proposals (93)
- # core-async (6)
- # cursive (9)
- # data-science (1)
- # datomic (24)
- # defnpodcast (1)
- # devcards (3)
- # emacs (3)
- # hoplon (95)
- # jobs (1)
- # off-topic (7)
- # om (97)
- # onyx (32)
- # overtone (1)
- # parinfer (4)
- # pedestal (1)
- # proton (1)
- # protorepl (13)
- # re-frame (4)
- # reagent (10)
- # specter (14)
- # untangled (40)
I'm debugging what looks like a server-side transit encoding issue. While debugging, I want to create an edn literal that includes an #C06DT2YSY/id tagged literal. Here's what I'm trying:
(def edn-body
{some/new-item {:tempids {#om/id["2e486bfc-aacb-4736-8aa2-155411274e84"] 852154481843896390}}})
When I do so, I'm getting No reader function for tag om/id
Is there a way to quote this so the compiler ignores it? Or include a reader?It looks like componentWillReceiveProps
receives a next-props
that doesn't include children. Is that right? And if so, what's the correct way to get the incoming children?
@grzm You might want to check in the #C03S1L9DN channel for more info about readers. I don’t think you can quote literals; they need to be defined
@peeja what are you trying to do with the incoming children in componentWillReceiveProps
?
these are the child components, not props?
(not too familiar with the what children are in om)
It's specified in a special way when you create the element, but it comes in as this.props.children
But Om appears to pull it out, and then doesn't give you a way to access it before it's available as (om/children this)
Not sure how much this helps, but I think componentWillReceiveProps
behaves a bit differently in om.next than react
I thought one of the great things about om.next was that you had access to the real React lifecycle
You can access them, but you might not be able to rely on setting state in response to the incoming children like you’re after
There are other people here who probably know this better than me, but my understanding in the past at least was that the lifecycle is slightly different because om.next renders asynchronously and batches changes
I think it does to some degree, and I think that means that setting state in your lifecycle isn’t quite the same as how it works in react
I believe there was talk about removing componentWillReceiveProps
at one point for this reason
because it basically exists in react so that you can set state and guarantee that your state will be updated properly in time for the rest of the lifecycle
I thought the correct way to handle that was to use defui
and only implement the lifecycle methods
You can rely on the lifecycle methods being called in the right order and everything, but the local state in om is just a bit different
My workaround was just to put an atom in local state and swap!
the value in the lifecycle
Oh, I'm not too concerned about that, then, I think. I'm actually going to be pushing it into a core.async channel
Well, that's not entirely accurate. When it comes out of the channel, the element will have to go into the state to be rendered
So the impression I got was that when you call the om functions to update state, they are really queuing that state update, and it seemed like you might not be able to count on state and props updating in lock-step like with react
I think you should be able to accomplish what you need by using the lifecycle but just staying away from om/set-state
or whatever the exact fn name was
That actually shouldn't be a problem for me: I need a props update (new children) to give me a chance to put the new child in a channel, and when I pull it off the channel I need to put the child in the state and cause it to render. Getting state and props to update in lockstep doesn't matter to me.
yeah, basically the other lifecycle methods ended up being my go-to
@peeja: Om Next renders incrementally in some cases, which means that componentWillReceiveProps
will not be called in those cases
There's a patch to address this that is waiting to be merged
To be clear, componentWillReceiveProps
is currently only called when rendering from the root
oh, thanks for clarifying that
So I would first check if it is being called at all
Only then try to get at the children
What does rendering incrementally mean in Om Next? I saw some mention of that, but I assumed it was about compatibility with React Fiber.
Rendering incrementally means that only the subtree rooted at the transacting component will be re-rendered
Along with any other places in the app that query the same data
In which case the transacting component wouldn't get componentWillReceiveProps
, but its children would, right?
Queries + the indexer give us the knowledge to do this
@peeja: yes that's right
My proposed patch addresses just that: https://github.com/omcljs/om/pull/743
@peeja: right so if you're not using an Om Next reconciler you shouldn't be worried about these problems
Because even though you have an Om Next component you're using om.core
's rendering loop
I don't think there's an obvious way to do that
Probably not
@peeja: you might want to open an issue to track that, but I'm not entirely sure how to solve that one in a clean way
Probably have the children be a computed
property in next-props
, not sure
I'm also not in front of a computer so can't really look at that right now
is there a tempid guide/documentation somewhere? it’s not “Just Working” and I have no idea how to debug
@calvis: I think as a starting point this one is somewhat insightful: https://github.com/awkay/om-tutorial/blob/master/src/cards/om_tutorial/om_specs.cljs#L14
@chris-andrews: It's actually on the server side. I ended up using the tempid constructor rather than the reader literal.
@calvis: that one is really just an example to prove it works I've got a complete working example with a Datomic backend here: https://github.com/anmonteiro/talks/tree/master/2016-berlin-meetup
@anmonteiro: thanks I like how minimal that is — is :id-key
required? what if I had tempids for multiple idents coming back
id-key
is required and is normally the thing by which all your entities are identified
Usually :db/id
I don't think there's a way around that
@calvis: probably worth having the same key for all your IQuery
components so that tempid migration can work
Actually there's probably a way around that
yeah, I don’t have that issue atm (just one ident) just kind of wondering about the restrictions
You'd need to override :migrate
in the reconciler
@calvis: is your state normalized?
so I copied om/default-migrate
into my repl and checked the intermediate values, the call to db->tree
returns a denormalized state with only the old tempids even though the pure’
expression has the new ones
@calvis: a number of things could be going wrong, happy to look at a minimal case though
@anmonteiro: in case you’re curious, I was using two different keywords for the :keyfn
and the first value of the ident vector, making them the same fixed the issue. is that bad style?
or maybe my :id-key
in the reconciler should have matched the :keyfn
and it would have been fine
@calvis: :keyfn
in factory should have nothing to do with it?
@anmonteiro: I’m probably conflating things that don’t need to be conflated, I made an example:
https://gist.github.com/calvis/31d895a924b888e8fff0e89d1cd7d8aa
(essentially I picked the wrong :id-key
)
for some reason when I enable simple optimizations some of my components fail to crawl the parent links and it leads towards null