Closed rbishop closed 10 years ago
I understand this is the way that backbone does this, but I don't really understand this need to name everything 'model' or 'collection'? What's the advantage over calling it 'todo_items' or 'task'? I think one of the great advantages of using react is that you're not bound to just one model and/or collection, and personally don't think that we should push people in that direction using react.backbone. (but this is my personal opinion, and I know the package already supports model/getModel; but I think this should be something to go away from, not move towards)
Sorry, that came out a bit more negative than I meant it. I find it important to discuss the direction of this project, but this PR contains a lot of worthwhile changes. Thanks very much for it!
You can still add more descriptive keys such as todo_items
or task
. This just adds a better API if what you're passing in is a collection instead of a model. It felt weird accessing a Backbone.Collection
using this.getModel()
.
You raise an interesting viewpoint that never really occurred to me, though. I tend to develop Backbone+React applications through the lense of "React is a stand-in for Backbone.View" so I was seeking more descriptive accessor methods. But React's point of view seems to be: anything that gets passed in is a model.
PS: You're making the world of open source feel really small to me when I run into a fellow Ruby Rogues Parley member on a repo for JavaScript
I'm everywhere ;) Btw, if you're using this in a rails app, are you aware of https://rails-assets.org/ ? That way you can use this library directly as gem.
Thinking about it, I think this does make sense for the createBackboneView, and doesn't disrupt the BackboneMixin usage. Personally I started only using the latter, as it makes me use react more 'reacty'. I will look into the code a bit more in depth. I agree about model vs collection, and that it doesn't make much sense to use model to get a collection.
If you could look at the two comments, otherwise this looks good to me. Again, thank you :)
On a sidenote, I noticed you also interacted with backbone-react-component. Do you use/evaluate both? If so, any reason why you like one over the other, or why one doesn't suffice?
I evaluated both and used backbone-react-component. I was intrigued by its interface (Backbone.React.Component.extend()
)but ultimately things fell apart when I couldn't use that in the latest version of React due to the library using some private APIs of React. This lead to me digging through the source and seeing a pretty complicated wrapping of React.
react.backbone on the other hand is barely 100 lines of code and is only using the well documented public APIs of React. I'm not good at fitting a ton of implementation details in my head, so I'll always take the more simple solution.
No, I havent used rails-assets yet, but I probably should. I'll take a look at it later this weekend. I've been increasing interested in integrating bower into a Rails app so this seems like it does it for me. The next step I would want to do is replace Sprockets with something like Gulp.
Btw, regarding 'extend', React is moving towards supporting ES6 classes, so you'll probably have that functionality in future versions of React. Otoh, react is very good in composition, so I rarely feel the need for inheritance. I agree on how small this is, that's exactly the reason I started using it.
That's good to know, thank you for sharing. I agree about composition, and that's how I've been using React, too.
It would be nice when using a component with a
Backbone.Collection
to be able to pass the collection in under thecollection
key and access it usingthis.getCollection
.React.BackboneMixin
into the component with support forBackbone.Collection
getCollection
andcollection
methods toReact.BackboneViewMixin
README.md