janic
If I take the example in your article I think this model solves the problem nicely. Let’s say you want to include a cart component that was created by a completely different team, in another part of the app, all you have to do is to add the fragment to the query that already exist in your screen and everything just works thanks to composition.
Then when someone adds features to the cart and for example fetch the full list of items then all screens that render that cart component will have their query update accordingly since they include the cart fragment.
Thinking in graphs and query languages like GraphQL makes building for change a lot easier. Your api now defines all the possible data types and their associations (think nodes and edges). This completely eliminates the need to write data management code as a graphql client library can take care of fetching, normalizing and providing the data to components since it knows about the data schema.
Queries can also be composed from fragments which goes very well with the React component model. This allow each component to define the data it needs and then all those fragments can be composed to generate a query. This query will only fetch the exact data it needs for what is displayed wherever the data comes from.
It does move back a bit of the complexity to the backend (defining schema, fetching connections between the different data types) but this is a lot easier to implement since you have full access to all resources. It is also easier to iterate on the implementations since code shipped to client apps can be hard to update when considering mobile apps.