ReactJS – Componentize all the things

Been taking a look at ReactJS over the last few days, which is an interesting view library from the folks over at Facebook.  What I really like about it so far is the “componentization” of  objects on a page.  The general idea being,  any part of the page should be able to stand on its own.  Think widgets.  In theory this is a nice idea until components need to interact.  For example, a list of items with a search box that filters the results.  Component 1 is the search box, Component 2 is the list of items.  In the traditional MVC pattern, the controller would be responsible for handling this interaction.  In react, you would create a parent component which would handle the passing of state change to the list component.  It doesn’t really matter what the parent component is, just that its children are the list and the search box.

Considering the issues I have with the traditional MVC pattern for front end web apps, I’m interested in how this approach by ReactJS performs in the real world at scale.  Especially on very interactive web apps.  In past large web apps, I’ve used an event bus to facilitate the communication between components and thereby reduce tight coupling.  My initial concern is that there will be hooks and callbacks being passed through each component in ReactJS, making the code a challenge.

Time to dig in and see the real world results.

2 thoughts on “ReactJS – Componentize all the things

  1. justin says:

    I have been playing around with ReactJS for a little while now. I love it.. I love the concept of it, and for the most part it makes good sense to me.

    The one area that I would love to see more examples on is something you sort of brought up. If I build just a search component.. and someone else wants to use that to drive the filtering process of their special component.. how do I make my search component available? Do I wrap it with a parent component that maintains the state.. and the person wanting to use it has to then work their component into my parent component such that the search component updates the parent component state and thus updates their filtered results in whatever component they build? Or, do I just give the search component with some info (docs) on what to replace in my code to call their AJAX server, what to do with the response and how they should wrap my search component inside a parent component they provide to maintain state.. in which case I’d also offer up info on what state my component expects passed to it (the exact props name for example)?

    When I first read about React being extendible, I was hoping it would spring up a complete reactJS component store, so that we could find reactJS components that we’d just use in our own code… for example a pop-up dialog calendar, etc.

    They’ve recently released info on their FLUX pattern, and I don’t fully comprehend it, but I think it is similar to what I am doing.. I am using EventEmitter2 (npm module) and in a child component that changes state, I fire an event, that may top level component then listens for and updates the state that it maintains. This in turn filters down via the top-down data flow, to various components that need to be re-rendered. I do this for one reason.. I do not like having to pass down callback methods from my top level state component as props all the way down to child components. I don’t particularly care for the need to keep passing the same prop down to child components.. for example:

    top comp
    state: name->”test”

    child1 comp:

    child2 comp:

    child3 comp:
    {this.props.name}

    Sorry if that looks funky..but basically my point is, my child3 comp needs the NAME state from the top state manager component.. and the only way child3 can use/see that is for me to pass it down through child1 and child2.

    The main reason I dislike this way of doing it is it’s hard to read. If I open up child2 component (jsx file) and see a props.name being used.. I want to know where it comes from. It takes a bit of digging to figure out it came from child1, and then from top level component. I’d like to know what component it originates in quickly/easily, not have to dig through each JS/JSX file trying to figure out the prop/state/ref and so forth.

    I think the Chrome ReactJS addon helps with this.. but when looking only at the code and not running it in the browser, it’s not so simple.

    Still.. it’s my only framework I am using these days. It’s that good.

    • Tony says:

      I completely agree. Passing callbacks through each component feels extremely brittle.

      I really like the idea of using Event Emitters and a bus to pass changes and new data. It still follows their philosophy of passing data “down” the stack of components, without the need to explicitly bind each callback in each component.

      Let me know how it works out for you.

Leave a Reply

Your email address will not be published. Required fields are marked *