This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-26
Channels
- # admin-announcements (1)
- # alda (44)
- # aws-lambda (6)
- # beginners (8)
- # boot (187)
- # capetown (5)
- # cider (25)
- # cljs-dev (24)
- # cljsrn (93)
- # clojure (45)
- # clojure-austin (9)
- # clojure-canada (2)
- # clojure-greece (1)
- # clojure-mexico (3)
- # clojure-poland (3)
- # clojure-russia (1)
- # clojure-spec (12)
- # clojure-uk (13)
- # clojurescript (86)
- # cursive (9)
- # datascript (3)
- # datomic (32)
- # defnpodcast (4)
- # devcards (23)
- # editors (3)
- # emacs (5)
- # hoplon (27)
- # immutant (3)
- # lein-figwheel (9)
- # leiningen (4)
- # luminus (10)
- # om (32)
- # onyx (2)
- # other-languages (1)
- # perun (1)
- # protorepl (8)
- # re-frame (13)
- # reagent (2)
- # remote-jobs (2)
- # ring (3)
- # spacemacs (4)
- # spirituality-ethics (3)
- # test-check (16)
- # untangled (65)
- # yada (50)
@dnolen: Running into a problem with the rendering loop. happens in an application that doesn’t have queries anywhere, just using Om Next to do "plain React”
Use case is a child that has local-state, and the Root which renders things from the global app-state.
The problem is triggered by updating local-state on the child and swap!
ing the global app-state with new data.
I’d expect both the child to update with the new local state and the root to render the newly swap!
ed items. however only the child updates.
I think there should be a way to force a render to be scheduled inside the add-watch
callback whenever the root doesn’t have queries (components with queries work just fine because of the indexer). what do you think?
@anmonteiro: that just sounds like a regression, I had that working before
cool, I’ll look into it
In Om.Now can you think of any reason a set-state!
would not trigger a re-render?
(I'm not implementing any custom should-update stuff)
@dnolen: having a deeper look at the problem, it doesn’t seem like a regression, but something that you had acknowledged but not solved? https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L1767
isn’t that comment related to this problem?
@anmonteiro: hrm maybe … but I don’t think so
@dnolen: I’m still investigating, but I’m leaning towards the idea that moving root re-render batching logic to the add-watch
call both solves the problem I described and obviates the need for that comment
We just launched a public beta of our reporting tool. Built entirely in Om Next and Untangled. http://www.adstage.io/reporting/ http://untangled-web.github.io/untangled/ We've never had this much fun building an app. Thanks @dnolen, @anmonteiro and all the other contributors!
If you want to make a full stack Clojure app I recommend giving Untangled a look!
I need to create a resource in componentDidMount
and release it in componentWillUnmount
. What's the preferred way to keep a reference to it? I've seen people store that in component state, but that feels weird, since it doesn't affect rendering and it doesn't change over the lifetime of the component. I see JS React people store that in properties on the component, but it feels un-Clojurey to use set!
like that.
@currentoor: glad to hear!
Ok so I tracked down the cause. I was nesting an om component inside a non-Om component. I believe this caused app-state
here to be nil:
https://github.com/omcljs/om/blob/e04c5329fa22c893fb4433f717369e30dca2d15d/src/main/om/core.cljs#L413
@dnolen: does this ring any bell? do you happen to remember what bug it was? 🙂 https://github.com/omcljs/om/commit/08e64cc6f125f8f16886641283aff4009a6d6ad8
Is there any support for React's childContext in Om?
@anmonteiro: no I don’t remember, some possible rare edge case
@martinklepsch: no or context
either - unclear what those would be useful for in Om - happy to hear some compelling reason
any approach I can come up with seems to break the chain required by the linked code above (i.e. props containing app_state are not passed on)
@dnolen: the reasons are mostly about interop with other React stuff. I have a large-ish Om.Now codebase and am replacing bits and pieces with another React wrapper
@martinklepsch: right no support that
@dnolen: what protocol would I look at for childContext in particular? Looking at whats there in om.core
I don't see a protocol to set arbitrary properties on the React class
@martinklepsch: what I mean is you can make your own component class that replicates the Om component behavior but does what you want
pretty much everything is reusable - most of the hard stuff was done when I tried the persisted state experiment
so not small amount of work, but probably the simplest way to accomplish what you want
@dnolen: thanks for the pointers, investigating.. 🙂
@dnolen: this PR fixes that issue with root re-renders. I still left the TODO
in place because we don’t really know if there’s an issue or not. Would like to follow up on that, maybe @kovasb remembers what issue it could be?
https://github.com/omcljs/om/pull/735