Writing a 'driver' to integrate my low level UI component library to be usable with React. My major issue was the 'rule' that a parent can't access the 'state' of it's children; this turned a 2 hour job into a 3 day job for me just trying to find a way to get access to this state through all of the lifecycle callbacks while instantiating children at the same time.
When asked in #reactjs, they said that if you need access to a child's state you should put it into the parent, which makes sense but not in my case. There is a natural way of hiding working 'upwards' through the chain, but I can't say I've seen it ever work downwards like in React, and I found that rather frustrating and difficult to work around.
One of react's core tenets is unidirectional data flow. Trying to use it in a bidirectional way is... painful. There is also a struggle with state vs props. The quick version is that state is internal to a component and is changeable directly by it, and props are given out by the parent and are not directly changeable.
Generally the way the bidirectional issue is solved is by closing the loop via dispatchers and stores. The child components send out actions to the stores, which then flow down through the parent, back in to the child. Turning what used to be a bidirectional flow to a unidirectional flow (sometimes at the cost of a bit of boilerplate for pre-existing components).
I guess the real question is, what is the use for the parent to be able to see the 'state' (the child components internal state)? The answer to that question (in my limited experience) has often been either 'to trigger an event (ex: save a form)' or 'so the parent can make some other rendering decision'. Both of which I've generally been able to solve via a flux implementation and possibly changing a 'state' into a 'prop' in the child (where the child gets a prop, some action is taken, and instead of changing state internally, an event is dispatched to the store with the new data, and the parent rerenders the child with the new 'prop').
But ultimately, hack it how you need. It's your code after all.
I had the same problem until I saw the light. The problem wasn't React: it was me.
You shouldn't merely learn React, but also unidirectional-flow architectures (like Flux, but there are many others, including better ones IMHO). Bidirectional data flow is a pain in the ass and once you understand unidirectional data flow, everything fits much easier. Of course, trying to shoehorn a bidirectional data flow in React is going to cause a lot of pain.
If you still need a bidirectional data flow, messing with lifecycle callbacks is definitely not the way to go. It seems to me you didn't have problems with React. You had problems learning React.
Unfortunately I'm not looking for a Religion, I'm just looking to get my job done. Too much structure can be just as bad as not enough when it comes to programming.
Put ref properties on the child components. Put public methods on the child components. You can then access the refs from the parent in the parent's componentDidMount or componentDidUpdate methods.
> this turned a 2 hour job into a 3 day job for me
> just trying to find a way
That basically summarizes my entire career with CSS/HTML/Javascript.
"Oh, the page you made looks great! Can you just move that image 10 pixels to the left?" Spend two days hitting my head on the desk trying to figure out why it won't align correctly
"Oh, the page you made looks great! Except in IE and the version of Chrome on Android 4.0.3" Spend two days trying to fix those browsers without breaking the others
