meta/meeting-notes/2016-08-30-team-sync.md
Starting with this meeting, we're trying a new format. Instead of giving individual progress updates on what we're each working on, we're going to discuss the major areas of activity and our progress towards them.
Goal: here is to make it possible for most components to be written with Relay 2 syntax/APIs and have them work either in Relay 1 or Relay 2. Implementation detail: use of a so-called "compatibility container".
Status: @kassens is working on compiler for Relay 2 to Relay 1 queries. @yuzhi is working on implementing lifecycle methods (shouldComponentUpdate/componentWillReceiveProps etc) in the compatibility container. Goal for next week is to pick a highly used leaf component like a text with entities (emoticons, links etc) component and start converting that.
Points of contact: @kassens, @yuzhi
Goal: here is to convert a couple of significant views in a production app which will exercise major facets of the framework such as pagination and mutations.
Status: Have been talking with potential collaborators internally to identify products which would be good initial test beds for Relay 2. Want to make sure performance instrumentation is fully in place before we start, so that we can compare before and after numbers. Effectively blocked on that happening, but we have other work to proceed with in the meantime.
Points of contact: @yuzhi
Goal: is to finish the API for basic server and optimistic mutations (initially not connections, then connections).
Status: diffs landing for optimistic mutations queue and the ability to apply and rollback. Next steps are server mutations integrated and working with the queue, hoping to get everything except connection mutations implemented this week.
Points of contact: @josephsavona/@wincent
Goal: is to support easy pagination in Relay 2.
Status: Underlying primitives are done ("handle fields" and handlers), now need to build a higher-level pagination API on top of it with some GraphQLRange-like capabilities. In the absence of this you can still manually build out pagination with some manual refetching or even just rendering additional root containers. By next week should have a prototype of a simple "load more" pagination API.
Points of contact: @josephsavona
Goal: is to have easy refetching in Relay 2, analogous to current setVariables API.
Status: We have a proposed API involving a RelayRefetchContainer and the ability to use this.props.relay.refetch(variables); just need to implement it and try it out, which we plan to start this week.
Points of contact: @wincent
Goal: have fast (scalable) and convenient builds for codebase using Relay 2.
Status: No action yet, but meeting scheduled.
Points of contact: n/a
Goal: ship Relay 2 powered Pokes Dashboard to 100% of production users.
Status: Pokes Dashboard is ported to Relay 2 but not shipped yet. We have an upstream GraphQL dependency that we are currently waiting on, but once that is done (hopefully this week) we will flip the switch, starting with employees.
Points of contact: @kassens
Goal: collect metrics and publish internal report.
Status: Native disk cache is working in internal app, but still need to collect the metrics (want to compare pure JS with native disk cache implementation) for internal feed app prototype.
Points of contact: @JenniferWang/@kassens
Status: @wincent is on call this week and is merging PRs, closing issues, preparing the package releases for this week.
Points of contact: @wincent
Status: @yuzhi landed a change that makes it such that queries triggered by setVariables use query names based off route in which they were fetched as opposed to first route to fetch that root call. This is relevant (specifically, more accurate) for people relying on query names in their logging infrastructure.