apollo/meetings/contributors-weekly/18-02-06.md

February 6, 2018 at 10am Pacific Time

Attendees

• Dirk
• Evans, Sashko (in SF)
• Peggy
• Daniel

Agenda

Update on React Async Rendering (Peggy)

• Overview on the changes that will be coming w/ React async rendering, starting w/ 16.4

React-apollo

• Discuss progress v2.1 of react-apollo w.r.t. Mutation and Subscription component and their current status.
• Discuss the tasks that that still need to be done for the v2.1 release of react-apollo and how we can best keep track of progress.
• Thoughts on supporting the new react context API in v2.1.
• Thoughts on creating a monorepo (as mentioned in roadmap or merging react-apollo with the existing apollo-client monorepo (which will simplify coordination across modules).

Graphql-js

• How many version of graphql-js to support?

Opportunities to Collaborate

• apollo-link-mock: accepts a schema and returns values for every field in your query
• apollo-link-sw-cache: caches get requests with a service worker
• apollo-link documentation: the link specific docs don't currently do a good job of describing capabilities
• brainstorm how to make these meetings more accessible

Notes

Async Rendering

• Yesterday Peggy met with React team
• Async rendering fiber
• today setState is synchronous, processed in a queue
• fiber the updates can be prioritized, rendering can be paused or interrupted
  • problems for libraries that take data flow out of react
  • mobx, apollo
• not a big deal, apollo is well prepared for the change
• suggest a record of updates that are coming
• we do it with optimistic UI
• can't measure level of muation tearing until fiber arrives in 16.4
• new features to test in beta in about 4 weeks
• what mean by mutation tearing
  • can't benefit from prioritization
  • can't garuntee what the order of changes are if you use priorities
• could maybe use react api's to manage cache state
• Redux, Mobx will need to update
• What about a migration guide?
• Redux maintainers are a bit conflicted
• Migration path will be easier for Apollo users
• Much bigger update that original React 16
• Changes with lifecycle methods
• 16.4 will add asyncboundaries
• warnings about lifecycle methods
• Apollo is working closely with React
• React excited to make sync rendering work with everyone

Context Change

• new context changes will be release in the next week or so
• don't have to worry about ShouldComponenntUpdate
• polyfill by James Ryan -> use for beta
• Apollo consumer components generate provider and consumer components
• won't need many new changes just with new API

Strict Mode

• James: try strict mode? to make sure we are async ready
• It's in 16.3? opt in to see if we'll have things break when 16.4 hits
• The blog post should be out this week, James will post to maintainers group

React-apollo

• Good progress
• Concerns about Mutation component
• many mutations in sequence
• update to force component to return most recent data (last week)
• James handles the 80% use case
• can manage outside state on your own
• return Promise from mutation
• makes the error/loading state much more explicit

Subscription Component

• Daniel has global subscriptions to update data used across all views
• Subscriptions component in the repo
• Push pause on Sub component, since may be issues with re rendering thousand of times
• remote operation
• Documentation needs to be updated for 2.1
• Peggy internal doc about docs that will be shared to improve documentation
• Heard that apollo is hard to get started with
• imporving getting started guid
• improving apollo-client-preset
• one stop shop that is easy to get started
• done by middle of next week
• list of topics of basics goes on forever
• tech debt with AC 2, so need to make documentation up to date
• Refactoring to render props is a good
• uses react-apollo and graphql-tag together, so should export them together
• right now have to install separately
• with .graphql files won't need to use graphql-tag?
• may be able to split out graphql-tag with turning on a side-effects flag
• gql does not require a build step
• create-react-app can bring in .graphql files
• write a blog post!
• add graphql-tag into react-apollo
• get react-apollo out of beta next week(Wednesday to get it out)
• monorepo is not needed, so keep them separate for now
• include react-apollo inside of the apollo-client repo?
• Sashko => disadvantage since there is a split, due to the communities around other view layer integrations
• type upgrade in react apollo and some of the apollo-client was incorrectly typed -> would have been nice to do directly
• nightly builds of each view level integrations becuase can use cron jobs on Travis CI
• open issues automatically
• can do custom build scripts
• keep things in master in about a week(5 day release cycle at max)

Action items: write a blog post about create-react-app, react-apollo out of beta Wednesday next week, documenation refactoring

Graphql-js

• Should really be on a non 0.x
• also test on the master of graphql-js with our automated travis-ci nightly
• most recent and the previous version
• Daniel: unless there is a new feature that we need, then stable software is the best
• two options: time horizon or version nubmer
• 6 months back or 2 versions previously
• James proposal: prior to 1.0 we support the last two version at minimum
• if gets to major, then we support the most recent major package
• There is a changelog now!
• 2 breaking changes
• came up with subscriptions library
• instanceof check is the issue

Action items: talk to Lee, possibly support two version back, and nightly builds (need to have an announced strategy)

Wanted: unit test library where you could change the version of single dependency

Opportunities to Collaborate

• Community may be doing something similar to apollo-link-mock, Peggy will be in touch