This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-01
Channels
- # admin-announcements (1)
- # aws (1)
- # beginners (14)
- # boot (19)
- # cljs-dev (10)
- # cljsrn (2)
- # clojure (64)
- # clojure-android (4)
- # clojure-dev (5)
- # clojure-greece (7)
- # clojure-italy (10)
- # clojure-russia (42)
- # clojure-spec (117)
- # clojure-uk (78)
- # clojurescript (160)
- # cloverage (1)
- # conf-proposals (1)
- # cursive (8)
- # datomic (93)
- # editors (8)
- # editors-rus (5)
- # figwheel (1)
- # flambo (14)
- # hoplon (95)
- # jobs (2)
- # jobs-rus (1)
- # lambdaisland (4)
- # lein-figwheel (6)
- # leiningen (3)
- # om (106)
- # onyx (33)
- # planck (6)
- # proton (3)
- # protorepl (2)
- # random (2)
- # re-frame (9)
- # reagent (5)
- # ring (1)
- # untangled (61)
- # yada (50)
@anmonteiro your advice was spot on! Thanks man
@anmonteiro: at @tony.kay’s suggestion I tried replacing my recursive query with explicitly defined defuis. So I went from a query like [:db/id :tag/name {:tag/child ‘…}]
to [:db/id :tag/name {:tag/child (om/get-query Tag2)}]
. Limits the recursion but it’s exceptionally faster. Rerendering with the recursive query took 3.5 seconds. With the chained joins, it took 0.8 (with the exact same data set). Not sure what’s going algorithmically with path-meta
and db->tree
but seems like they could use optimization. Should I file an issue? Not sure what would be helpful in terms of documentation
@ethangracer huh, is this a sort of 'trampoline' likeTag1 Tag2 Tag1 etc.. or just recursive Tag2 joins?
Tag1 -> Tag2 -> Tag3 -> Tag4 -> Tag5
I just stopped after 5 levels
@selfsame I could’ve been clearer about that above
So even though my database supports infinite nesting, the UI would only unroll the first 5 levels with this implementation. But obviously huge performance benefits
@ethangracer and this is benchmarking the initial render?
@selfsame correct, it’s not a re-render of the subcomponent but the first complete render of that view. Though subsequent rerenders are slow with recursive queries too
super interesting, guessing that recursive om/get-query
isn't possible and this only works when you have a limit to node depth
@ethangracer 3.5 seconds definitely needs some kind of optimization 🙂
I’ve already spent some time optimizing path-meta
in the past
so for me to go and look at it again I’d really appreciate a minimal case showing the slow path
@selfsame I think it’s a call stack issue, I can’t image what else would cause that kind of performance difference in such a small data set
@anmonteiro awesome, thanks — i’ll let you know
I notice that alpha42 has been on github for a month but alpha41 is the most recent version on clojars
Based on https://anmonteiro.com/2016/01/writing-om-next-reloadable-code-a-checklist/, is there ever a reason not to (defui ^:once …)
your components?
Looking at the property-based testing material (https://github.com/omcljs/om/wiki/Applying-Property-Based-Testing-to-User-Interfaces), would I want to remove the references to :remote in the mutate functions?
hrm I’m surprised no one has been bitten by om.next/transform-reads
discarding parameterized reads
@anmonteiro have you run into this ^
@dnolen I don’t have for habit to use parameterized reads that much, at least not recently
where did this come up?
I just needed a parameterized remote read in a transact!
and I saw it was getting lost
could it be because of the indexer somehow?
I’m currently not looking at the code
@dnolen since you’re around, these issues can probably be closed: https://github.com/omcljs/om/issues/536 https://github.com/omcljs/om/issues/643
@dnolen well those keys don’t really belong to any component that the reconciler knows of
i.e. there’s no backing indexer
garbage in garbage out
it could just not touch those keys
(I’m just discussing this before I decide anything to make sure I’m not way off base here)
I only see one problem with leaving those untouched
which might not even be a problem at all
the user’s parser might not know how to handle those keys
but it’s really just a matter of adding support for that… so as I said, probably not even a problem
if you’re providing keys with no parser and no components - then something is definitely not right
I didn’t understand you were talking specifically about this scenario
right, at least I’d expect transform-reads
to return those keys untouched
but I haven’t needed to transform-reads
in that case
by curiosity, do you find that you need this use case?
or is it just something you want to make right?
@anmonteiro I think it’s just wrong and surprising, in my particuarly case someone wrote a super simple routing thing without bothering with union queries or anything like that
it’s definitely surprising, I can agree with that
I don’t want to mess with what they’ve done since it works just fine - except for this disappearing keys problem
no argument here
@dnolen btw just rebased the self-host PR
re: beta1, would be nice to include that one^
and probably the docstring one (I could put something together tomorrow)
@anmonteiro ok, I’ll cut an alpha today, and cut a beta after that one
that sounds good
thanks
@dnolen go ahead for beta: https://github.com/omcljs/om/pull/754
@anmonteiro nice! I still to fix this other thing, might have to wait till tomorrow
@dnolen yeah, no rush for me
I’m still wondering about error handling
wasn’t that supposed to be up for beta?
@anmonteiro the design is mostly there already actually
also wondering about Routing support, is there anything else that you’re thinking about adding or do routing approaches just need to be documented?
(looking over the beta1 milestone)
I’ve been building an app for a couple months now so I have a sense of what might need work, but the current set of features is workable and not a huge problem
was all that just re: error handling or routing too?
also integration in the app lifecycle too I think?
is there a way to get at it currently?
yea that what I thought
@dnolen I have been thinking about something for a while now that I forgot to mention.
It’s only supported in some newer browsers (so it would need polyfilling or at least checking if available), but I was thinking that we could hook up window.requestIdleCallback
in some non-critical places
could potentially bring perf benefits
Opening an issue to track that