This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-11-03
Channels
- # admin-announcements (7)
- # beginners (30)
- # boot (181)
- # cbus (1)
- # cider (55)
- # cljs-dev (8)
- # clojure (104)
- # clojure-dev (3)
- # clojure-japan (1)
- # clojure-russia (70)
- # clojurescript (139)
- # core-logic (4)
- # cursive (23)
- # datomic (25)
- # devcards (10)
- # events (11)
- # funcool (1)
- # hoplon (39)
- # jobs (10)
- # ldnclj (19)
- # lein-figwheel (21)
- # off-topic (4)
- # om (174)
- # onyx (46)
- # re-frame (25)
- # reagent (3)
- # yada (7)
My first Om Next project is now online: http://lisperati.com/orly
(FYI, you should be seeing a bunch of colorful tiles when visiting the demo URL- If you get a blank screen or something let me know your browser version )
Hmm, looks like om.core
has :key-fn
but om.next
has :keyfn
. Is the inconsistency intentional? I'd consider renaming :keyfn
to :key-fn
.
Probably has to do with how it's named in React
If we use datascript and all stateful components use an Ident of :db/id, what do we miss? My understanding is that one primary rerender performance boost from Om Next is from using various key names that represent component types, so that when a transact! happens on that type of component, the rerender check can be quickly narrowed down to only those same types of components. is this accurate?
I just learned a noob lesson: stating it here for anyone else who might get caught by it. My app follows the pattern shown in the “Components, Identity and Normalization” page. In that case the root query is assembled from a root component and leaf components without including the connecting component. This works in the example but….in my case I am updating local state in the connecting component and the refresh does not include it’s data
I fixed it by referencing all components in the tree when building the root query so that refreshes at any level always include the data required.
this really clarified for me how much important meta-data is built into the root query - as I stated, a noob mistake. I hope this saves someone else some time
it looks as though om.next
is missing a :require
declaration for [cljsjs.react.dom]
- noticed when rendering was failing when i used sablono and removed my :require
for om.dom
I wrote a blog about the reconciler, maybe people will find it helpful: https://medium.com/@kovasb/om-next-the-reconciler-af26f02a6fb4
@maravillas: I reported the same thing a few days ago. There’s good suggestions for cleaning this up in the discussion.
ah, excellent
i worked around it by just referencing om.dom
, even though i don't use it
...which is silly, i guess i could just depend on it directly
@kovasb: Oh wow, thanks for writing this
still trying to wrap my head around om
@kurtlazarus: that's more of a #C053AK3F9 clojure question, and the answer depends on what you want the output to look like. Feel free to message me directly for some help.
Sorry, didn’t mean to pollute the channel. If anybody else is reading this, I finally figured this out: Here’s a stack overflow where I asked (and then answered) this question: http://stackoverflow.com/questions/33491017/om-next-tutorial-correctly-calling-the-get-people-function/33491426#33491426
@kovasb: very nice overview ! Thank you. You should team up with @tony.kay to write "Om-Next Up and running" 😉
Why is mutate called twice? I put some printlns in the mutate method of the Om Next Datascript tutorial to see how it works. It seems mutate is called twice once with the starting state and once with the updated state, i.e. before and after inc. Anyone know how/why this is? Thanks.
Can you think of other great reads about Om/Next besides the following? https://facebook.github.io/relay/docs/thinking-in-relay.html https://github.com/omcljs/om/wiki/Quick-Start-%28om.next%29 https://medium.com/@kovasb/om-next-the-reconciler-af26f02a6fb4 https://github.com/awkay/om/wiki/Om-Next-Overview
@martinklepsch: https://dvcrn.github.io/clojurescript/react/2015/10/27/going-native-with-om-next.html was the only other one that I can think of
@griffio: I considered that one but decided against it because it’s very hands on and mostly React Native specific. Thanks though!
added community resources section to wiki, feel free to add blog posts, other docs here https://github.com/omcljs/om/wiki#community-resources
@dnolen: I've been looking into Phoenix framework which uses Elixir... would I be crazy in thinking Om Next and that would make a great combo?
@grounded_sage: Om Next is agnostic about the backend … so sure!
Awesome. The only other things I would love to use is Transit (which seems not yet ready for production) and Datomic but I might just have to run it through a Peer?
@grounded_sage: transit is definitely production ready and has been for a long time
@txus if you could paste an example of what’s not working it will probably be easy to spot
@dnolen: ok.. Transit website says that it may evolve and to have caution but that must just be for certain use cases. Hmm technology trade offs. So tempted by Elixir scalability and fault tolerance but so many goodies in Clojure land.
So this is the parent view:
clojure
(defui RootView
static om/IQuery
(query [this]
(let [sections (om/get-query SectionIconView)
users (om/get-query UserView)
software-updates (om/get-query software-updates/SoftwareUpdateView)]
`[{:app/sections ~sections}
{:software-updates ~software-updates}
:app/current-section
:car/remaining-range
{:app/users ~users}
:app/current-user]))
The child view that renders all the SoftwareUpdates:
clojure
(defui SoftwareUpdatesView
static om/IQuery
(query [this]
(let [q (om/get-query SoftwareUpdateView)]
`[{:software-updates ~q}]))
And the software update view component:
clojure
(defui SoftwareUpdateView
static om/Ident
(ident [this {:keys [software-update/name software-update/version]}]
[:software-update/by-id [name version]])
static om/IQuery
(query [this]
'[:software-update/name
:software-update/version
:software-update/size
:software-update/status])
@grounded_sage: the warning is just about using Transit as storage format, for wire stuff it’s definitely ready for production usage.
(only the queries, to have an idea). One weird thing I’ve noticed is that the RootView grabs onto the SoftwareUpdateView query, and the SoftwareUpdatesView does too, which seems weird. I added the query to SoftwareUpdatesView because I thought that’d fix it, but not sure what’s idiomatic in this case. Is the RootView to do all the orchestration of getting the subquery for the children software updates, or should SoftwareUpdateView do that?
Then in the SoftwareUpdatesView there’s a button that width {:onClick #(om/transact! this '[(software-updates/accept)])}
I’m not sure I understand. SoftwareUpdatesView
shouldn’t have a query then, because it doesn’t really need it, it just passes down props from the RootView
to the children SoftwareUpdateView
, yeah?
@txus there’s no need for every component to have a query, pass through components are fine
oh ok. But then if I try to om/transact!
from this pass-through component, it doesn’t work right?
okay, so in general you’d say if there’s a tree of components each with more specialized queries, the parent ones shouldn’t bypass the immediate children right?
you cannot pass props computed by something other than the query the component specified
okay. does that mean though that all children would be re-rendered any time any of the software updates’ data changes?
will do that then, sorry if the questions are basic! I’m still wrapping my head around it
@txus actually when I think about it your example (after I gave you the idea for the first fix)
I’m not sure what you mean by transact!
ing from IQuery
— I was just transacting from a button callback, not from IQuery itself
@dnolen: in your todomvc I see that parent components pass their whole props
to children, is that the preferred way? Intuitively I would’ve thought they’d cherry-pick what to pass down the line
Om Next is really more about uniform app structure and eliminating mutable observation patterns / complications
so when you mentioned that child component could be “pure”, as in receive props directly without an IQuery — is that generally not advised, as each component should specify what it needs in IQuery if possible, but then sometimes it’s okay having pure components?
there’s nothing wrong with a component that doesn’t specify props that you pass props to
back to your example, so yeah the more I think about it the transact!
restriction which was really designed to discourage people using transact!
at leaf nodes is just a bad guard-rail
hrm but the problem with relaxing this restrition would mean we would need to lift transactions to parents and re-run way more than is necessary.
so RootView is something like [{:software-updates (om/get-query SoftwareUpdatesView)}]
I was just running into a thing with the reconciler, probably the queries are wrong, but I’ve isolated this example:
(defui Foo
static om/IQuery
(query [this]
[{:foos [:foo/name]}]))
(def data {:foos
[{:foo/name "Foo"}
{:foo/name "Bar"}]})
(om/tree->db Foo data true)
; {:foos [nil nil], nil {nil {:foo/name Bar}}}
I thought that first but then I tried adding
static om/Ident
(ident [this {:keys [foo/name]}]
[:foos/by-id name])
between the docs and a couple example apps it’s definitely easy to get going, just some things I guess are a bit new but that’ okay!
and I’m starting to see that if a component is modular yet involved in transactions, it just has to implement IQuery
I’ve seen also a different approach in https://github.com/Jannis/om-next-kanban-demo where all transactions are done in the parent view
Hey, I was just looking over the above exchange. So, is the current thought to stick with the idea that any component that wants to transact!
something needs to implement IQuery
? Something I’ve been hung up on is: what if you have a component like a button, and you want to pass it (as a prop) a callback, which will transact!
something? Is that going to blow up?
Ok, that’s what I was hoping would work
Thanks for clarifying that for me
And while we’re on this line of discussion, am I correct in thinking that what is transact!
-ed is not limited to updating only aspects of that particular components IQuery
? e.g. an action can affect many aspects of the application, even if the transact-er never reads any of that data
@chris-andrews: that’s correct
@dnolen: hanks. I think I’m starting to get things. But what is the advantage of transact!
-ing on behalf of a parent component vs
sorry… vs just letting “dumb” components transact!
@chris-andrews: I don’t know what you mean
dumb component shouldn’t transact because they can’t possibly know what other keys are involved
Well, my thought was that the parser has a user-provided mutate function, so any component could transact an increment-thing
action, and the parser knows what to do with that, and how to determine which keys should be re-read
I think the gap in my understanding is what keys are used for when transacting, if the transacted actions don’t necessarily have to update only data related to the given component
Ok, it’s starting to make sense. I am due for another pass through the docs too. I haven’t read them since way back in the alpha-7 days. Thanks for the help!
"the only thing that can decide what should reread is UI code" Ah... I get why you don't use the ":values" in the mutate functions now!
Have you seen the code for the devcards though? It's really just rendering Om Next components, passing props in, not exercising the query and reconciler stuff yet.
The idea of writing and testing UI components in devcards and then combining them in more complex devcards is intriguing for sure.
I can imagine scenarios where designers would create sketches in UI cards, developers code them up roughly and then they finish them up together pair-programming-style or something. It's just so quick
@jannis yeah people actually already have really cool working setup of stuff like that
that's pretty great
I haven't ever worked with designers, because it's been mostly Linux embedded/desktop work so far. No idea what design processes look like 😉
yes because Rails has had such a huge effect a lot of people want access to Ruby designer-centric tooling
Hello, I'm playing with om-next-starter from jdubie and I'm getting a very strange behavior with figwheel... every time I modify the code and save it, figwheel updates the browser code and then I get never ending requests to the server ... not yet figured what's going on...
try changing defonce
-> def
https://github.com/jdubie/om-next-starter/blob/master/src/om_starter/core.cljs#L43
forgot the push that. just updated github https://github.com/jdubie/om-next-starter