meteor-base mobile-experience mongo tracker es5-shim react-meteor-data check timbrandin:fetch accounts-password
import React, {Component} from 'react'; | |
import {reduxForm} from 'redux-form'; | |
import { connect } from 'react-apollo'; | |
// you mutation code | |
@connect({ mapMutationsToProps }) | |
class ContactForm extends Component { | |
onSubmit = (...args) => { | |
const { handleSubmit, mutations } = this.props; | |
mutations['myMutation'](args); |
Currently the DX (Developer Experience) of working on apollos powered sites, apps, or the core framework is frustratingly difficult. This doc serves as a discussion point for improvements, particuarly through the idea of consolidation of apollos projects into a monolith.
- junction
- apollos-rock (sync)
- apollos-core
- apollos-give
- my.newspring.cc (site repo)
- newspring-app (app repo)
src/apollos/models/users/index.ts[18, 2]: file should end with a newline
src/apollos/models/users/mocks.ts[2, 10]: unused variable: 'MockList'
src/apollos/models/users/mocks.ts[8, 17]: missing semicolon
src/apollos/models/users/mocks.ts[12, 15]: missing semicolon
src/apollos/models/users/mocks.ts[13, 18]: missing semicolon
src/apollos/models/users/mocks.ts[17, 15]: missing semicolon
src/apollos/models/users/mocks.ts[18, 18]: missing semicolon
src/apollos/models/users/mocks.ts[22, 22]: missing semicolon
src/apollos/models/users/mocks.ts[23, 34]: missing semicolon
<h1>Regular grids</h1>
<div class=grid>
<div class="grid__item one-whole">
<p class=demo-block>Foo</p>
</div><!--
--><div class="grid__item one-half">
[[[[[ ~/Products/apollos/core/Apollos/sites/newspring ]]]]]
=> Started proxy.
| (#1) Profiling: ProjectContext prepareProjectForBuild
=> Started MongoDB.
| \
| files.stat 0 ms (1)
| files.unlink 0 ms (1)
| files.readFile 0 ms (1)
Hello wonderful people! Thank you so much for helping us make this app better. We really appreciate your feedback and have loved all of the ideas so far. We have a couple small updates and one big one for you today!
Group Finder
We believe you can't do life alone and now we want to make that easier than ever. Click the groups icon in your navigation to search for a group and see recent articles related to community. This will eventually be your home for managing your groups and all things community at NewSpring! True to beta fashion, this isn't available to anyone else yet! You're the first people to use it and we would LOVE your feedback on it.
Since Heighliner is the center point of our data across all future Apollos projects, and has the potential to inform the creating of Rock's GraphQL endpoint, efficiency at scale is critical. In order to feel instant for our users, we have a high level of caching as part of our stack.
Due to the newness of GraphQL and the new paradigms it creates, there is almost no writing about caching within a GraphQL app, nor are there any available tooling / libraries we can use. Caching (more importantly cache invalidation) is the best iterative way to get to reactive GraphQL in my opinion. GraphQL is also a declarative data system. Unlike REST API's a query could fetch from any number of data sources each request depending on the fields. Instead of interacting with the request AST, we cache the data interface level which supports cross type and varying request cache hits.
We also don't run GraphQL as the only point of data mutation in our application stack. Even in th
const Container = graphql(gql`query GetUser { person { firstName } }`)(({ data }) => { | |
const { loading, person } = data; | |
if (loading) return <div>Loading...<div> | |
return <h1>Hello {person.firstName}</h1> | |
}); |