RFC: Adopt Relay Hooks in favor of container-based APIs for managing GraphQL data

[Ole]

Proposal

Adopt Relay Hooks in favor of the container-based APIs for fetching and managing GraphQL data in Eigen (Relay Hooks Migration Guide).

Reasoning

1. Using Relay Hooks will require less code and has less indirections than the equivalent container-based solution.
2. The Hooks API gives us the ability to configure more granular fetch policies and comes with an improved TypeScript coverage (according to the Relay documentation).
3. By extracting queries it will be easy to import them in other places of the app which can for example be used for our query prefetching implementation.
4. The Relay team suggests using the hooks API and has removed examples using the old container-based APIs in the documentation.
5. Using Relay Hooks will make it easier for engineers to rely on the official documentation.
6. The new usePreloadedQuery hook can be used to implement the "render-as-you-fetch" pattern to make data available faster.

Exceptions

The old container-based APIs are still fully supported in all new Relay versions to this point and even can be mixed with the new Relay hooks API. This means we can incrementally adopt the new API and don't need to convert already existing components.

The old container-based APIs are still fully supported in all released Relay versions and can even be mixed with the new Relay Hooks API. This means that we can introduce the new API gradually and do not have to convert already existing components.

Additional Context

After a first attempt to use Relay hooks with the relay-hooks library which was not fully compatible with Relay's QueryRenderer, we realized that it was not possible to combine the container-based APIs from Relay and the hooks from the unofficial relay-hooks library without using nested query renders. With the new official Relay hooks API, this is no longer an issue.

As soon as other clients upgrade Relay to a version that supports Relay hooks, this RFC can be applied to these projects as well.

"Introducing Relay Hooks" Blog Post

How is this RFC resolved?

We'll consider this RFC approved if 50% of the engineering team actively approves of this change or there are no major objections that require. Add a 👍 or 👎 reaction to this proposal to vote.

Next Steps

In case of approval, we will start updating all Relay-related documentation and encourage engineers to use the new Relay hooks API for all new components in Eigen.

Relay Hooks Migration Guide

Co-authored by @MounirDhahri

[Matt Zikherman]

I don't code much in Eigen, but I had a general question about this.

I was on a team working with React/Relay on the web 2+ years ago, where we were using React classes and containers (I assume you mean createFragmentContainer and the like). The containers seemed like a nice abstraction (wrapper around React classes), and I enjoyed using React classes (coming from an object-oriented background).

Now, it seems like functional components and hooks are all the rage (while classes + containers remain first-class supported citizens as well). I haven't worked much in web since then, so I'm behind, but I sort of missed the memo/blog post on why this new approach is better. I'm not sure why I need to essentially 'discard' some of that ecosystem knowledge, and learn something new in favor of hooks and functional components. The reasoning given above doesn't feel super compelling to me (although granted I am out of date and it seems like this ecosystem is pretty cutting-edge and changing often).

Can someone help explain (or post explanatory links) detailing this shift?

[Ole]

This is a very good question. Maybe this chapter from the React docs can explain what problems functional components and hooks try to solve.

There is also a post from the Relay blog that gives an overview of the advantages of the new Relay Hooks API and explains why the Relay team is moving in this direction.

[Mounir Dhahri]

I was on a team working with React/Relay on the web 2+ years ago, where we were using React classes and containers (I assume you mean createFragmentContainer and the like). The containers seemed like a nice abstraction (wrapper around React classes), and I enjoyed using React classes (coming from an object-oriented background).

This is a good point, we actually brought this into discussion a few months ago on slack (sorry non-artsy engineers readers), and we had an agreement that we liked having that abstraction serving us for the Separation of Concerns between the fetching logic and the UI logic. This same separation was not easy to achieve back with the unofficial relay hooks and we decided to stick with our containers-based approach. The situation is different now since we can achieve that using relay cooks and we can still keep a pattern that our engineers are familiar with and have a clear separation of concerns to the same granular level as before or further if we want to.
This is what an Artist screen looks like in our current approach:

This is what an Artist screen would look like in the suggested approach

---

I'm not sure why I need to essentially 'discard' some of that ecosystem knowledge, and learn something new in favor of hooks and functional components.

I think this RFC will not to discard any of the ecosystem knowledge our engineers acquired. Since we stopped having any class components inside Eigen (and also other front-end clients I believe) for the last 1.5 years, we think it won't take much time for our engineers to get familiar with relay hooks instead of the HOCs approach since they're already familiar with the approach and the react docs as well are encouraging the usage of Hooks. This migration though will help our engineers be able to get information from the official relay docs which are now almost entirely written using hooks

[Matt Zikherman]

Thanks! I hadn't realized the official documentation had been updated like that. Being able to share the stateful stuff and not rely on context and context provider and stuff is nice, you dont need to have all these HOC wrapper like WithInfiniteScroll and the like. The fact that Relay is moving more towards this (allowing the finer grained fetching options) is also enticing.

Since we stopped having any class components inside Eigen (and also other front-end clients I believe) for the last 1.5 years

@MounirDhahri I haven't done significant front-end contributions in about that long so I am really out of date in that regard! I'm still more familiar and experienced with classes and componentDidMount 😆

[Carlos]

That's going to help also when you want to debug with React Dev Tools, less HOC is a better tree view from that point of view 👍

[Ole]

It looks like we have adopted this! Gonna close 🪝 🪝 🪝