[1:24 PM] mezzopiano: Hi everyone!
I'm building a tree component, and would like to move from a nested representation of the (redux) state to a flat one (in which each node stores the ids of directly nested nodes) because it will make the code simpler (other components access the same data, and even for the tree itself reducers will be simpler because they do not have to traverse the entire structure).
My question is this: This will (I think) require a transformation from the flat to a nested data structure (which I'm worried would break immutability), or individual components (tree nodes) pulling data from the store directly. Which approach would you recommend? Is this a bad idea overall?
Any comments, pointers and suggestions are much appreciated. Thanks a lot!
[1:24 PM] acemarke: @mezzopiano : as it turns out, my own app uses exactly that approach
[1:24 PM] acemarke: each individual tree node is itself connected
[1:25 PM] acemarke: the parent passes in the item's ID as a prop
[1:25 PM] acemarke: the tree node looks up its own item's data in mapState, including the IDs of any children
[1:25 PM] acemarke: and then it renders its list of children, passing in their own IDs
[1:25 PM] mezzopiano: Wow, that's awesome! How's your experience been? Is your code available somewhere?
[1:25 PM] mezzopiano: (and huge thanks for your super-fast response!)
[1:25 PM] acemarke: no, it's not available at the moment. It's on my TODO list of stuff I'd like to write about at some point
[1:26 PM] acemarke: which, sadly, is a pretty long list atm
[1:26 PM] mezzopiano: ?? I know that feeling
[1:26 PM] acemarke: but yes, that approach is working great for me
[1:26 PM] acemarke: if you look in the Redux repo, you can see a very simplified version of this approach in the treeview example that Dan wrote a while back
[1:28 PM] acemarke: I actually did a bunch of looking for suitable React tree components for a while before finally building my own
[1:28 PM] acemarke: I had a couple specific needs - I really needed it to be more of a treelist (with multiple columns), and I needed a column of checkboxes
[1:28 PM] acemarke: I have seen a couple more recent components that looked like they had treeview capabilities
[1:29 PM] acemarke: although at a very quick glance, both looked like they wanted the "Big Ball O' Data As A Prop To The Root" approach
[1:29 PM] acemarke: I think
[1:30 PM] mezzopiano: acemarke: Thank you so much! You comments have been incredibly helpful (I wish I could hand you a pint of your preferred beverage through the screen ?? ).
[1:30 PM] acemarke: lemme give you a bit more info
[1:30 PM] acemarke: each individual node actually breaks down into three components
[1:31 PM] acemarke: I have a totally generic, dumb, presentational component that is solely responsible for rendering that node's icon, text, other columns, and putting any provided mouse click/move/etc handlers in the right divs
[1:32 PM] acemarke: I have a very slightly smarter component that tracks mouse hovering in its own state, renders one of the dumb base components, passes in its own onMouseEnter and onMouseLeave handlers, as well as the icon URL, label text, and other info from whoever's rendering it
[1:33 PM] mezzopiano: I had seen the redux example a long time ago and actually used it for my first experiments, but the tree components available which I used as starters all used the "Big Ball O'Data" approach, so I got stuck with that. Thanks for pointing me at this again!
[1:33 PM] acemarke: and then each of my app-specific treenode types has a mapState, knows what kind of data item it's representing, figures out icon URL for that item type, and passes down onClick handlers and such, and turns those into app actions
[1:33 PM] acemarke: and renders its list of children
[1:34 PM] acemarke: also, that mid-level component tracks the expanded state of the node
[1:34 PM] acemarke: and if it's currently closed, does not include this.props.children in the render output
[1:34 PM] mezzopiano: Cool, your approach sounds very neat indeed! I've been using react-dnd for the interaction, which I can also recommend.
[1:34 PM] acemarke: yeah, mine doesn't have any dragging aspects
[1:35 PM] acemarke: I really do want to write it up at some point, along with a few other bits from my own app I think are reasonably interesting
[1:35 PM] acemarke: but my first priority is trying to finish this "Structuring Reducers" section I'm writing for the Redux docs
[1:35 PM] mezzopiano: Ah, not having dnd makes things waaay simpler.
[1:35 PM] acemarke: which, technically, I want to be doing right now, but I'm kinda procrastinating
[1:36 PM] mezzopiano: Sorta same here, I should probably be doing something different if I think about it ... ??
[1:37 PM] mezzopiano: But don't let me keep you -- and thanks again for your support, this has been totally awesome. I'm definately unstuck now, and have all the data I need to keep going.