Our Data Approach

[youknowriad]

With the work being done in the editor chrome. We need to fetch media by id, we'll have to fetch categories, tags... I think we should settle on our data approach.

By our data approach, I mean answer the following questions:

• Where do we make the fetch calls?
• Where do we store the fetched data?
• Should we think about persistence?
• How do components declare their data needs?

Options:

1- Fetch and store data in the components them selves: Quickest solution but doen't scale well!

2- Follow something similar to Calypso's approach to data which means (read this)
- Storing Data in the redux store (with opt-in reducer persistance)
- Thunk (or whatever) action creators to fetch and normalize the data
- Factorize data fetching in QueryComponents
- Use the Combo (QueryComponents + Selectors) to declare data needs in the components
- (I explicitely avoided to mention the data-layer and the http-layer to avoid the so many abstraction levels)

3- More advanced data fetching
- Storing Data in the redux store (with opt-in reducer persistance)
- Thunk (or whatever) action creators to fetch and normalize the data
- Describe the data fetching as a graph (GraphQL) (see https://github.com/youknowriad/react-graphql-redux and read the blog post)

---

I really appreciate the approach 3 myself, but the approach2 has proven to be solid.
I think we should have this discussion on the CoreJS meeting because this should be shared across all the different projects (and we may even reuse the same store?), but we need at least to settle on a way to do this for Gutenberg for now, and we'll merge with the Core decision at a later point.

[aduth]

Related: #691

Component state: I think it could also vary depending on the context. For example, we've seen a couple cases of blocks which need to fetch their own data when initialized (#754, #870). I wouldn't expect those blocks to need to interact with the global state at all, since their data needs are not useful outside their own instances. I don't know that this means we shouldn't necessarily have some pattern, especially because it's often overlooked that a component instance may no longer be mounted by the time a request completes. We could consider having a pattern for individual block stores, or push block implementers toward leveraging setAttributes with the assumption we'll gracefully handle component unmounting on their behalf.

Persistence: I'm not sure we ought to worry too much about persistence at this point, or perhaps at all. Since we have a server context, we could instead prepare all data needs before the page loads, to be rehydrated into the store upon initialization. Or similarly a cached set of API responses to be consumed instead of a full network request.

GraphQL: I like GraphQL as much as the next, but worry of the approachability impact it could have on block implementers. Then again, if we try to avoid needing special data considerations for blocks at all, we could at least isolate these effects to core code only. One of the problems I'd had with the implementation of react-graphql-redux, at least in combination with selectors, is that it's an increasing set of layers from Reducer -> Selector -> Resolver, all of which are operating on the same data.

Selectors: I suppose you might not need selectors at all in a greenfield GraphQL approach, but then again, one thing that's growing on me about selectors is they would be very straight-forward to document (example).

[aduth]

Related: #894

The featured image case is interesting. I don't know how useful the media entity would be outside its usage in the <FeaturedImage /> component, so this could be a case where we'd be fine with leveraging component state. One consideration is if we did want to preload this data on the server before displaying the page, it's more challenging when contained in the component than if we were to have a bulk rehydration pattern for global state.

[jasmussen]

As a quick note on the Featured Image panel, I wouldn't want you to optimize too much for that remaining a panel forever. We've kicked around some ideas that are still unfinished, where making an image featured is a "star" button on an image. I.e. you insert an image, click a star, and now it's "featured". But the flow is not fully figured out, and the mockups aren't solid, so that's basically an idea that's punted at this point.

[nylen]

This is a cool idea! Maybe the image block should also be moved to the beginning of the post when it is "featured" like this.

[nylen]

Regarding data needs specifically, can we make use of the WP REST API's _embed parameter to cut down on the number of requests needed?

[BE-Webdesign]

Regarding data needs specifically, can we make use of the WP REST API's _embed parameter to cut down on the number of requests needed?

We could run an embed request to put in place of _wpGutenbergPost server side, then potentially normalize it. That would give the author, terms, featured media etc, on top of the post data. That would cover most of the "rehydration" needs for initializing the editor right? ( If I am understanding rehydration correctly ).

[youknowriad]

We could run an embed request to put in place of _wpGutenbergPost server side, then potentially normalize it

That's probably a good thing, but not sufficient. We need to load media not attached to the blog (on switching for instance), we need to load categories, tags (probably paginated). Thus, I think we should settle on something more generic on how to fetch, store and persist (though, this could be left for later when we really feel the need) data.

[BE-Webdesign]

That's probably a good thing, but not sufficient. We need to load media not attached to the blog (on switching for instance), we need to load categories, tags (probably paginated). Thus, I think we should settle on something more generic on how to fetch, store and persist (though, this could be left for later when we really feel the need) data.

I meant more for the "rehydration" portion (bootstrapping the initial render). We will definitely need to settle on a standard for data interactions.

[youknowriad]

We have several network requests in several components right now, we need to settle on something here. I'd love the GraphQL approach but maybe it's not battle tested yet. Should we go for Calypso's QueryComponents + effects (same as the current effects)?

[mtias]

@youknowriad do we have something actionable here or should we close for now?

[youknowriad]

We have the withAPIData which addresses this partially. We also use refx for other side effects. Things may move further if we split the "editor" module (post editor) I think we can close.