Make SubscriptionValue public

[liam923]

SubscriptionValue is seemingly needlessly private at the moment, and it is the only implementer of LeafAction that is private. This pr makes it part of the public api.

I have found this to be necessary for the use case of implementing subscriptions with a materialized schema. Without SubscriptionValue being public, the only way to make a resolver that can return a stream is via Field.subs. Thus, creating a fake field and then taking its resolver (Field.subs(...).resolver) is an unfortunate consequence of SubscriptionValue being private when using a materialized schema.

[yanns]

Thanks for the PR.
Do you think we could add a test to show this use-case? Would https://github.com/sangria-graphql/sangria/blob/main/modules/derivation/src/test/scala/sangria/streaming/StreamSpec.scala be a good place for that?

[liam923]

Thanks for the PR. Do you think we could add a test to show this use-case? Would https://github.com/sangria-graphql/sangria/blob/main/modules/derivation/src/test/scala/sangria/streaming/StreamSpec.scala be a good place for that?

I went ahead and added a test as suggested. Unfortunately, it is a bit more involved that I had initially realized. Field.subs also adds a SubscriptionField tag to the field's tags, and without it, sangria raises a match error at at sangria.execution.Resolver.$anonfun$collectActionsPar$1(Resolver.scala:713). This pr thus likely requires creating an AstSchemaResolver that can add tags or modifying execution code to not require the tag.

[liam923]

Or an even better solution would probably be creating some sort of SubscriptionFieldResolver to complement FieldResolver, which could deal with the tagging.

[yanns]

Thanks for the test! It's looking good and helps understanding the use-case.

[yanns]

I'm still trying to understand what is possible and what not.
And I'm not sure it's possible to add tags on the AST level.