generate client pointers entrypoints

[PatrykWalach]

Stuff to be done:

• better stable enumerate (now I enumerate all traversal results)
• fix imports in entrypoints
• prefix refetch queries (so entrypoint__0.ts has __refetch__0__0.ts, __refetch__0__1.ts, etc.)

I'd like feedback if what I've done so far seems correct

The main idea here was:

• for client fields FieldToCompletedMergeTraversalStateMap stores a single entry, the merged selection set is the same for loadable and regular fields
• for client pointers, we want one not loadable entry for reader_selection_set and an entry for each loadable since they have different merged selection sets

That's why I replaced ClientObjectSelectableId in FieldToCompletedMergeTraversalStateMap with new type ClientSelectableKey.

The ClientSelectableKey is a tuple of the ClientObjectSelectableId and either:

• None - this is non loadable selection
• Some(path) - this is loadable selection under some path, the path has a parent pointing to different key in the map

So far I've only tested this with query below and it seems to generate correct (besides the bugs above) entrypoints, and refetch query.

self {
  age
  __refetch
  self {
    tagline
  }
}

pointer Pet.self to Pet {
  debug: alt_tagline
  link
}

Part of #53

[rbalicki2]

Mind if we hop on a call so that I can understand what's going on? TBH I'm a bit lost, but it could be cause I'm really tired 😅

[rbalicki2]

What is this struct going to be used for? I'm not sure I follow, in particular, what the parent_selectable_key is going to be used for

[PatrykWalach]

Sure, we can hop on call

[PatrykWalach]

1. Right now this seems to be 90% working, refetchQuery for unnested pointer requests too many fields 😭 (but I have a feeling it'd run at runtime)
2. Also refetch queries don't have readerAst so we use selections for that, this means, we don't need usedRefetchQueries 😄

This looks really clean

[PatrykWalach]

This is fully working! 😄

[rbalicki2]

Omg I didn't notice your comment!!! Yes!!!! I should be able to finally get through the backlog tomorrow or next week

Once this lands and we add some uses of it in our demos, let's cut a release 😎

[rbalicki2]

did we discuss this? I'm a bit worried that this is the wrong move here, but TBH I feel like I would have noticed this and commented on it in the past.

Okay, so what's happening here (lol I'm literally prompting myself like I'm an LLM):

• scalar server fields, object server fields and client pointers exist in the same namespace, so there's no chance of a conflict here, that's fine
• this flows into the reachable variables. These flow into get_used_variable_definitions, so I think that's fine. Because if a variable is used in a client pointer, but not elsewhere, it should show up as a required parameter of the client pointer's loadable field type. (Does it??)

Okay, so as far as I can tell, it's not obviously broken. But does it belong? There are a few places we ignore this variant. Maybe that's indicative of it not belonging.

Okay, let's chat about this sometime.

[PatrykWalach]

I did it this way so it's easy to traverse in current_target_merged_selections when client pointer or refetch is in another pointer