4 ms·

I got started with React on a project last week. It's magic when it works, but initially it takes some thinking to figure out how all the components should fit

by feifan 13y ago

I got started with React on a project last week. It's magic when it works, but initially it takes some thinking to figure out how all the components should fit together, and where the interactions should take place. It took me a while to figure out that my interactions on one component might trigger a method that should belong on a parent component a few levels up, and to have to pass that method down in the props for the child to call. React provides a syntax called JSX that looks a lot like regular HTML, but is transformed into native JS before it hits the React engine. It's brilliant, but requires node somewhere along the line to do the transformation. I got stung by this — building a Rails app, and Rails on Heroku ships with an ancient version of Node that causes the transformer to error out. Solution in the works (https://github.com/heroku/heroku-buildpack-ruby/pull/177 https://github.com/heroku/heroku-buildpack-ruby/pull/177), but if you're using Rails and Heroku, stay away from JSX for now

acjohnson55 13y ago
In a Backbone project I'm working on, every app component and view passes a context object down to any children it creates, which is a copy of the context object it received upon creation, optionally augmented with methods it contributes from itself and other providers. So it's basically a component tree, with an API that grows as you descend down the branches (yet remains distinct between branches). In essence, the context forms a sort of scope that subcomponents can use to communicate with others. By convention, components "import" API calls into themselves in their constructors. This makes it very clear what the dependencies are. The beauty of this setup is that intermediary objects don't have to worry about explicitly mediating the interface between their ancestors and descendants. The only components that have to do any mediation are common ancestors of components that need to communicate across branches, but this mediation can be contained, rather than polluting the entire hierarchy. It's also trivial to mock out the context methods during testing. Similarly, you can use a sort of name-based polymorphism to provide alternate implementations of the context methods, dependent on configuration or parent component, perhaps. It seems to me that a similar scheme would fit nicely with React's model.

by feifan 13y ago

acjohnson55 13y ago

In a Backbone project I'm working on, every app component and view passes a context object down to any children it creates, which is a copy of the context object it received upon creation, optionally augmented with methods it contributes from itself and other providers. So it's basically a component tree, with an API that grows as you descend down the branches (yet remains distinct between branches). In essence, the context forms a sort of scope that subcomponents can use to communicate with others. By convention, components "import" API calls into themselves in their constructors. This makes it very clear what the dependencies are. The beauty of this setup is that intermediary objects don't have to worry about explicitly mediating the interface between their ancestors and descendants. The only components that have to do any mediation are common ancestors of components that need to communicate across branches, but this mediation can be contained, rather than polluting the entire hierarchy. It's also trivial to mock out the context methods during testing. Similarly, you can use a sort of name-based polymorphism to provide alternate implementations of the context methods, dependent on configuration or parent component, perhaps. It seems to me that a similar scheme would fit nicely with React's model.