parse-community
Query without observe in react native
Hi,
I want to do a Query without the observable patern in react native. Just a query and execute. Like the mutations. Sadly I find no hint in the documation if this is even possible. :(
I need this, because I manage the state of my application via redux. Thanks
This is my little query:
Parse.Query('Project').containedIn('code', subscriptions)
Also, it is hard to mutate without beeing able to execute a query.
ParseReact.Mutation.Set(Parse.Query('Project').containedIn('code', mycodes), {
archived: true
})
.dispatch()
.then(function(ob) {
console.log('then');
console.log(ob);
})
.fail(function(err) {
console.log('error');
console.log(err);
});
Hi Klaus. We started using redux too, and we found that things got a lot easier when we dropped ParseReact and just use the vanilla Parse JS SDK. It's straight-forward to write Redux middleware that handles ParseQuery and ParsePromise as an action payload, so then you're just dispatching actions on the Redux store and write idiomatic Redux/React while still using Parse as your backend. If you look at the source code for the Thunk and Promise middleware for Redux, writing a middleware for Parse becomes obvious.
Rick
On Nov 27, 2015, at 8:45 AM, Klaus Breyer [email protected] wrote:
Hi,
I want to do a Query without the observable patern in react native. Just a query and execute. Like the mutations. Sadly I find no hint in the documation if this is even possible. :(
I need this, because I manage the state of my application via redux. Thanks
This is my little query:
Parse.Query('Project').containedIn('code', subscriptions) — Reply to this email directly or view it on GitHub.
@RickDT I was thinking the same thing. The only thing which bothers me is that I would want to include my extended subclasses of Parse.Object inside the redux store, but they are mutable and so aren't recommended. How would you solve this? One approach is to get any data from the parse object in the reducer, and hold only raw data in the store, but I rather work with actual Parse Object subclasses, as I did in Java. :)
@DeDuckProject Technically, all JS objects are mutable if you're writing pure JS (not transpiled from something like Typescript). If you're going to adopt Redux, then it's just a matter of doing mutations by dispatching actions, rather than mutating the objects directly.
Personally, I would reduce the Parse objects down to raw data in your state. We've done that and it works well. Essentially, the Parse SDK becomes a way of loading/sending data to/from the server. The project becomes more "Redux oriented" rather than "Parse oriented" however, so it's not a tradeoff to take on lightly if you're already very invested in Parse subclasses.
@RickDT I see what you mean. Currently I'm using Redux with Parse in the following way: action for queries are dispatched, and a promise-middleware takes care of the async part. When a query is done and the promise is fulfilled, the reducer takes that query and just puts the array as is, in the redux store. This makes my store mutable and maybe misses some of the redux point. But the gain is, as we said, that I can use Parse subclasses as is. also, Parse takes care of my Parse Objects so they stay in sync and so on. One drawback is that I have to manually set a certain query to "dirty" in order for it to do another find() the next time... I'm not sure how bad that all "mutable objects in state" is gonna be as I move forward, currently it seems ok. I'm still not sure which way is better. All I know is that the Parse subclasses let me do more things easily (maybe that's because I came from Java...)