A modern programming language that makes developers happier.

kotlinlang

second question.
based on compiler plugins with `documentTransform`, would that allow us to write our own custom clientside directives?

That is the intent but TBH the use cases are still pretty much TBD

got a couple of good ones, for tracking purposes in our app, we have  to usually query for a couple of fields, differing by some metadata fields but typically an `id` and another `entityId` field then package those up into a model class.

using:
```fieldName @trackable```
would be amazing. im thinking it would add special rules around which fields to query for and similair to declarative caching, insert fields to query for `id` , `entityId` etc and maybe get fancy with custom defined rules for each type a dev could define

another idea is implementing the `@client` directive to add computed fields only available on client schemas

<https://www.apollographql.com/docs/react/data/directives/#client>

`@client` sounds a lot less doable :sweat_smile:. That's one of the oldest feature request in the repo.

```@client sounds a lot less doable 
. That's one of the oldest feature request in the repo.```
be fun thing to think about how it could work. we’ve managed to make mock schema that is split by build variant (debug / release) that enables you to write additional schema in either flavor, in this case `debug` sources. then you can only depend on it in debug code up the chain. its a pain when you need to do something in main sources, duplicating code. but if it was simply a directive that is stripped out in operation registration existing in main sources….this would become 100x easier

now client only ones, could be an extension of that - `extend type SomeType` alongside main schema code. then you decorate the field with `@client`. then youd need to write an adapter class that gets checked at compile time (somehow) and linked to that field in that specific operation in some way

and registering it and sending its query would require stripping it out, probably difficult. these are just ideas, not POC’d or fleshed out yet :laughing:

Oh, it's "just" about stripping some field based on the presence of `@client` , I think that's actually even easier than `@trackable` .

Well, maybe same level of complexity actually because you have to use the schema (I'm assuming `@client` would be on the field definition, and not field itself?)

i think it can be any
```directive @client on FIELD | TYPE | etc```
*Full types on client only:*
```type ExtendedType @client {

}```
usage:
```someType: ExtendedType @client(adapter:"packageName.ExtendedTypeAdapter") # required otherwise will fail build```
*Existing Types*
use the same directive, but require an adapter to get registered pointing to it
```somefield: String @client(adapter:"packageName.ExtendedTypeAdapter") # required otherwise will fail build```


or some fancy “linking” mechanism where you register a query path away from schema to do it:
```@ClientAdapter(paths = ["SomeQueryName.field.someField"]) // query paths, can use multiple
class MyClientAdapter: ClientFieldAdapter<String> {
   suspend fun evaluate(...): String { // the parameter would be something about the operation document etc

   }
}```