Quite. Apollo Client is the problem, IMO, not GraphQL.
Though Relay still needs to work on their documentation: Entrypoints are so excellent and yet still are basically bare API docs that sort of rely on internal Meta shit
Though Relay still needs to work on their documentation: Entrypoints are so excellent and yet still are basically bare API docs that sort of rely on internal Meta shit
It's the unfortunate situation where those who know, know, and those who do not, blasphemy the whole thing based on misunderstanding.
Super unfortunate, which could be solved by simply moving a little money over to Relay's docs, and working on some marketing materials.
If you're interested in entrypoints without the Meta internals, you may be interested in checking out Isograph (which I work on). See e.g. https://isograph.dev/docs/loadable-fields/, where the data + JS for BlogBody is loaded afterward, i.e. entrypoints. It's as simple as annotating a field (in Isograph, components define fields) with @loadable(lazyLoadArtifact: true).
I’ll have a play though, sounds promising :)
Oh this is interesting, sort of seems like the relay-3d thing in some ways?
And if you also combine this with the fact that JS and fragments are statically associated in Relay, you can get: - entrypoints - 3D (if you just defer components within a type refinement, e.g. here we load ad items only when we encounter an item with typename AdItem https://github.com/isographlabs/isograph/blob/627be45972fc47.... asAdItem is a field that compiles to ... on AdItem in the actual query text)
And all of it is doable with the same set of primitives, and requiring no server support (other than a node field).
Do let me know if you check it out! Or if you get stuck, happy to unblock you/clarify things (it's hard for me to know what is confusing to folks new to the project.)