Adding more depth on render props discusssion

meetings/contributors-weekly/18-01-09.md

@@ -40,14 +40,25 @@
 - issue: flow types are very hard to keep up-to-date (updates tend to break things)
   - possible solution is to move into flowtype repo (ask dirk/james for more detail)
   - sashko: might make sense to make compromises to automate this
+- subscriptions component implementation
+- kevin: issues with re-fetch in higher order components
+- follow up: Peggy to add various related PRs to central design document and add link here once updated 
+
+**Discussion about explicit render props** 
 - peggy: would love for us to transition to using 3 explicit render props (as opposed to child)
   - render-loading, render-error, render-data
   - more detail on this direction in original roadmap
   - sashko: what counts as loading needs to be explicit (e.g. re-fetch)
   - issue: getting recompose to work with render prop
-- subscriptions component implementation
-- kevin: issues with re-fetch in higher order components
-- follow up: Peggy to add various related PRs to central design document and add link here once updated 
+- after discussion with peggy, leo, james: 
+  - the idea we ended up with (not set in stone yet though) was  to have both ways: one beginner-friendly approach with 3 render props (which would hopefully be useful for the most common use cases), and also have an advanced 4th prop that you would use instead of those 3 and will receive all the data, error and loading info for you to handle as you want. You would use either the 3 props or that 4th one, but not both uses at the same time
+- Kevin (opinion added later): 
+  - I think either/or is fine `final-form` provides for `render` or `children`, but three render props + a fourth as children seems unnecessary. Having used render props extensively I can tell you that breaking out 3 is a mess of code from a user perspective.
+  - Bigger api surface area, more tests, more support, more new developer confusion.  Various approaches in blog posts won't add any clarity, which means more stackoverflow and more user questions.
+- Peggy: argument for 3
+  - the argument for 3 (error, loading, render) is that people today end up not handling error / loading state when they're left to handle it themselves in the HOC. these props would cover the simplest use cases (loading or error w/o data) and act as a "filter" for when the render prop fn is called. if people want to handle loading / error state in a more advanced way (on a refetch, when data is there, etc), then they would use the render prop
+  - as long as we are very explicit about what states the props cover in the docs, i think the api changes will be much more clear for newcomers
+- followup: discussion on issue?
 
 **Documentation**
 - need for more documentation of testing 
@@ -59,7 +70,7 @@
 - concern: related to types in react-apollo; some of the code is not entirely typed or strictly using typescript/ type checking, willing to contribute to fixing this
 - James: was related to release schedule, contributions are definitely welcome
 - codegen: would like to see type checking in javascript api as we’re doing in swift
-- follow up: meeting with James, Martijn and Leo on types
+- followup: meeting with James, Martijn and Leo on types
 
 ### Other meetings going on:
 - martijn / lewis - flow targets