Fork me on GitHub

@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


and sure yes, fix welcome for that


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?


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. 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.


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


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:


@dnolen: does this ring any bell? do you happen to remember what bug it was? 🙂


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


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


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


@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


that said everything was protocolized


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


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