Fork me on GitHub
#om
<
2016-07-26
>
anmonteiro15:07:07

@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?

dnolen15:07:49

@anmonteiro: that just sounds like a regression, I had that working before

dnolen15:07:57

and sure yes, fix welcome for that

anmonteiro15:07:27

cool, I’ll look into it

martinklepsch16:07:42

In Om.Now can you think of any reason a set-state! would not trigger a re-render?

martinklepsch16:07:42

(I'm not implementing any custom should-update stuff)

anmonteiro16:07:42

@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

anmonteiro16:07:09

isn’t that comment related to this problem?

dnolen16:07:40

@anmonteiro: hrm maybe … but I don’t think so

anmonteiro16:07:05

@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

currentoor17:07:01

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!

currentoor17:07:08

If you want to make a full stack Clojure app I recommend giving Untangled a look!

peeja18:07:54

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.

peeja18:07:03

I'm inclined to go with set!, though.

martinklepsch19:07:24

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

anmonteiro19:07:43

@dnolen: does this ring any bell? do you happen to remember what bug it was? 🙂 https://github.com/omcljs/om/commit/08e64cc6f125f8f16886641283aff4009a6d6ad8

martinklepsch20:07:20

Is there any support for React's childContext in Om?

dnolen20:07:23

@anmonteiro: no I don’t remember, some possible rare edge case

dnolen20:07:38

nobody’s reported anything yet so I don’t recall now

dnolen20:07:36

@martinklepsch: no or context either - unclear what those would be useful for in Om - happy to hear some compelling reason

martinklepsch20:07:10

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)

martinklepsch20:07:33

@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

dnolen20:07:02

@martinklepsch: right no support that

dnolen20:07:12

that said everything was protocolized

dnolen20:07:23

you could provide your own Om wrapper thing and add support for whatever you want

martinklepsch20:07:14

@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

dnolen20:07:46

@martinklepsch: what I mean is you can make your own component class that replicates the Om component behavior but does what you want

dnolen20:07:24

pretty much everything is reusable - most of the hard stuff was done when I tried the persisted state experiment

dnolen20:07:58

so not small amount of work, but probably the simplest way to accomplish what you want

martinklepsch20:07:08

@dnolen: thanks for the pointers, investigating.. 🙂

anmonteiro21:07:40

@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