-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create repositories and basic implementations of view layer integrations #63
Comments
A big 👍 for building that, we are getting closer to an Apollo MVP! I wonder if it would be possible to customize the reactivity layer, for instance by using MobX + React, instead of Redux + React? Also there are some decisions to make on the API design, for instance I imagine that higher-order functions/components/decorators are much more recommendable these days than Tracker-like mixins. |
I wonder if you have an idea for how this would work? At the end of the day, we need a state object that can be modified by firing actions. If MobX offers that, I imagine it wouldn't be hard to integrate. Also, what's the benefit here? Is it to integrate with some kind of MobX tooling?
I think each view layer's integration should be the best practice for that view layer. So for React it will be a container component similar to Relay, not sure what people do in Angular these days. In Blaze it would probably be some kind of Tracker-enabled function. I already have a private demo app using the apollo client and React, and I built a trivial container that is used like this: const TopicWithData = createContainer({
getQuery: ({ params, loginToken }) => {
const maybeLoginToken = loginToken ? `(token: "${loginToken}")` : '';
return `
{
root${maybeLoginToken} {
oneTopic(id: "${params.id}") {
id
category_id
title
posts {
pages {
posts {
username
score
cooked
}
}
}
}
}
}
`;
},
}, Topic); This is probably the most basic thing we could build at first, if we don't want to dive into query aggregation and fragments and whatnot. (The code isn't open source yet because it's straight up just bad code, but we want to release this full-stack demo and a basic server this week or next) |
There have been a bit of discussion about MobX in apollographql/apollo#1. MobX basically does the same thing as Tracker, as it allow you to have some reactive data sources (in this case it could be a GraphQL query) and a reactive context that will be re-ran every time one of its dependency gets invalidated. With this model you are able to run arbitrary computation reactively (like with The point is that the update model is different if you use Redux (re-render the whole tree, probably use Immutable and implement a Not that this is super important in this early stage, but I just think it’s good to have in mind the various update models that people will want to use. |
One of the core ideas I'm working with for this package is versioning the entire store as an immutable object, very much in the style of Redux. I think this is the most natural approach for a store which is normalized and shared between all queries, and immutable JS will hopefully let us determine relatively easily which parts of the query result have changed. If this makes MobX integration a bit more work, for now that's just a cost we'll have to pay. For what it's worth, I think most or maybe all people should be using this library via the view connector, and not by interacting with Redux or whatever directly. So we can make that layer do the work of determining if a particular query result actually changed or not, regardless of that Redux says. |
But one’s might as well want to perform some arbitrary computation using a Apollo/Graphql query as a data source, say for instance that you want to display an HTML5 notification when a new message is posted in a thread. How would that work if it is the view connector that is determining if a query result changed or not? |
Sorry, I misspoke. It should be some layer between the Redux store and the view connector. So you could think of the MobX integration as a view connector. |
And I agree that not firing spurious events on queries when their result didn't change should be a priority! Otherwise many things would become very hard to do and people would have to build custom result diffing, which kind of defeats the purpose. |
Started a repo for React here: https://github.com/apollostack/apollo-react Also, we're going to get going on Angular pretty soon. |
Riot.js would be awesome! 👍 |
Please open a new issue about it! |
Would love to see support for Blaze 👍 |
Please open a new issue instead of commenting on a closed old one! |
Would love to see vue-apollo come together. I'll be working on this myself as mentioned in the linked thread above. Scott |
I got a vue integration running! |
Wow, that's awesome! |
Two to start with:
Other candidates, to do as people need them:
The text was updated successfully, but these errors were encountered: