maybe throw something if observe returns a promise in the result object rather than a query?
I was calling first() instead of limit(1) and it took me a while to figure out XD
We try to print out a warning if you subscribe to something that doesn't support the subscribe() interface: https://github.com/ParsePlatform/ParseReact/blob/master/lib/Mixin.js#L125
Warnings only print when you're using a development-mode (read: non-minified) version of the library. What version of the library were you using?
Hey @andrewimm thanks for responding. I really like ParseReact. I've been able to get rid of some many stores/actions and so much boilerplate; I love it.
I'm using parse-react from npm but it's going through watchify, browserify and babelify (pretty much copied from https://github.com/ParsePlatform/ParseReact/tree/master/demos/todo.
The erroneous code looks like:
dish: (new Parse.Query('Dishes'))
.equalTo('objectId', props.dishId)
.include('restaurant')
.first()
Glad to hear it's making a difference in your development cycle!
Hmm, seems like I need to rethink the code behind warning(). Originally when we released the library, the npm module simply imported the development version of the prebuild library, and around v2.0 we switched to importing files from /lib.
I think the best approach will be to replace if (process.env.NODE_ENV === 'development') with if (process.env.NODE_ENV !== 'production'), and tell developers that they should use something like Envify when building production apps where they don't want to have warnings surfacing.
Could you also remove the /* @flow */ from the files in lib? I get like a hundred errors from flow that things are missing annotations :P Maybe produce flow declarations for the typed code if it's easy? Those are definitely things that aren't hard to live with/without, though.
We can definitely produce standalone declarations for third party apps to use. It never occurred to me that the babel compilation wouldn't remove those flow annotations. You can track this in #71 and #72