Split @component into two steps

[rbalicki2]

@component does two things:

• causes the reader AST to not be immediately read. i.e. It is not read along with the parent fragment, meaning that the parent fragment field doesn't suspend if the child field is missing data.
• wrapping it in createComponentCache (where the child field's fragment is read, and may suspend)

So, there are four cases:

• read as part of the parent, not a component (current eager reader artifacts)
• not read as part of the parent, not a component (not currently possible, but useful)
• read as part of the parent, component (of dubious usefulness)
• not read as part of parent, component (current @component)

---

I have to think about this more, but my hope is that "call this function in a cached component" can be entirely separate from the rest. So, that gets rid of a lot of the awkwardness related to components.

But I have to think about that more.

---

This might work as follows:

• If we have an eager reader artifact, things behave as they currently do
• If we have a DeferredReader artifact, then we also call the same hooks: useReadAndSubscribe, useState(readButDoNotEvaluate), useRerenderOnChange, useEffect(subscribe)
  • However, this the read-out value will never change (i.e. is stable), so the state will never be updated, the useResult caller will never re-render, etc. subscribe is a no-op.
• The DeferredReader artifact will have a resolver function that defaults to an identity function which is passed some read function (() => ReadDataResult<TReadFromStore>). For @component fields, this resolver function calls `getOrCreateCachedComponent(thatReadFunction)

---

Anyway, hopefully this gets us closer to splitting the component cache entirely from the "core" of Isograph, since it is a React-only thing.