Fork me on GitHub

@ajs, I've started to use r/children exclusively


it's useful for wrappers:

(defn wrap-in-div []
  (into [:div]
        (r/children (r/current-component))))


You can use is like :div, but of course the wrapper fn can be customized, especially with lifecycle methods


@pesterhazy that’s an interesting example


one thing that is confusing coming from Om, where children and props are quite explicitly different, is in Reagent the args to a component could be either props or children, which feels odd to me


i wonder if that means at runtime Reagent needs an extra step when mounting a component to determine what’s a prop and what’s a child based on the args


I agree it's confusing


especially given that reagent extends React so that you can >1 function argument


The old way when component fns only took three explicit args seems clearer


The lifecycle fn signatures are also not clear


What do you mean by "the old way"? I don't think remember a 3-argument restriction.


Been working in Om for several years, I like its explicit React interface a lot more. So clear, even if a bit more code to write.


Reagent component fns used to always accept three args, props, children and this


It was changed in 0.4


ah I didn't know that


yeah a simple props map plus children is best in most cases


The other thing is suppose you pass arbitrary args to a component fn but they are just used in the function for calculation, they are not included in the hiccup vector and therefore are not children. Reagent still interprets them initially as children anyway?


Not for Reagent, but I've been using spec to pull children out of hiccup like structures.


I'm moving my own thinking down the route of "there are no components, there are just functions embedded in the tree that generate more tree" though.


(s/def ::node (s/cat :name keyword?, :attrs (s/? (s/map-of keyword? string?)), :children (s/* ::node))) for example.


@ajs, not clear on that

Petrus Theron14:11:40

Tricky Rendering Problem: I’m trying to render an HTML <table> with many <tr> rows where each row represents a node in a tree. Each node may have zero or more children nodes with no depth limit. For HTML display purposes, I need to render these children as siblings after the parent node (not as children inside the <tr> DOM element). Given that React components must return a single root element, how would I recursively render a flat list of <tr> given an arbitrary tree? Is it even possible to do this lazily, or do I need to do some packing/unpacking magic?

Petrus Theron14:11:58

Hmm, I see that React v16 supports returning an array. Does Reagent work with React 16?


I would say change it from a tricky rendering problem into a tricky data manipulation problem: first turn your tree data into a flat vector of row-data-objects. Then you could just render same as you would any other sequence of rows in a table.


Yes (Reagent works with React 16), and fragments are usable with Reagent, though no helper fn function is included yet

Petrus Theron15:11:33

Thank you @juhoteperi, works perfectly!

Petrus Theron14:11:01

Thank you, guys! How do I enforce React 16 in my Cljs Reagent project?


@juhoteperi have you looked into much? I’d be willing to help out with it — I could really use it.


how would rendering with JVM clojure work? your 3rd party react components written in JS would not work


@tatut good question. I think it’s predicated on your rendering functions being implemented as cljc.


then you would have to do everything yourself (without any help from the react ecosystem of components)


I think nashorn based server side rendering is a better way to go


I think you’re right, there is a limitation to the usefulness of this approach.


I’m mostly thinking about testing. Firing off a sequence of events, then inspecting the results. I suppose you really don’t need to render the view to do that, you could simply take a look at app state.


Er, apologies, I’m thinking about this from the perspective of a ReFrame application.


I’ve seen a few blog posts on it, where people provide a Clojure based translation of reframe/reagent hiccup-formatted data to actual hiccup (recursively calls nested rendering functions, etc)


@mccraigmccraig No. That looks like a big chunk of it though. That’s more or less what I think I want to do. I’d like to render the view as well, but yeah, that’s the majority of it right there.