Greetings. I am writing a client library for an API who can read various datasets, each of which are essentially (the JSON analogue of) structs but often having nested structs. In every case, the API can limit what fields it returns, filter using the fields, and sort using the fields. In the case of the field of a nested struct, the API uses dots to separate each name component (same notation as frunk's path macros). There are often so many fields that fetching all of them is prohibitively expensive, but I cannot know in advance which subset of the fields my users will want.
What I can already do, is publish a LabelledGeneric struct containing every possible field, let the user specify their own type of which they will receive deserialized instances, and require that the user's data type can Transmogrify from the "every possible field" struct.
This has two weaknesses: (a) in order to give the API the list of what fields are contained in the user's data type, I must use runtime reflection via serde-reflection crate, which does all the work at runtime not compile-time; and in order to take in filtering/sorting requests, I must rely on the user to not make typographical errors in string data. (Every other "get me all the fields of the struct" type of procedural macro I can find, does not consider nested structs or, if it does, it flattens the field names making it impossible to place the dot separators.)
If, on the other hand, for any LabelledGeneric I could obtain an iterable collection holding all of the possible Lenses for that LabelledGeneric type, then I could stringify them to eliminate weakness (a); and I could require the user to provide filters+sorts as Lenses and test all of them for membership in the collection, thus converting weakness (b) from sending bad data to the peer to failing internally at runtime. What is the best path forward to this state?
Greetings. I am writing a client library for an API who can read various datasets, each of which are essentially (the JSON analogue of) structs but often having nested structs. In every case, the API can limit what fields it returns, filter using the fields, and sort using the fields. In the case of the field of a nested struct, the API uses dots to separate each name component (same notation as frunk's path macros). There are often so many fields that fetching all of them is prohibitively expensive, but I cannot know in advance which subset of the fields my users will want.
What I can already do, is publish a LabelledGeneric struct containing every possible field, let the user specify their own type of which they will receive deserialized instances, and require that the user's data type can Transmogrify from the "every possible field" struct.
This has two weaknesses: (a) in order to give the API the list of what fields are contained in the user's data type, I must use runtime reflection via serde-reflection crate, which does all the work at runtime not compile-time; and in order to take in filtering/sorting requests, I must rely on the user to not make typographical errors in string data. (Every other "get me all the fields of the struct" type of procedural macro I can find, does not consider nested structs or, if it does, it flattens the field names making it impossible to place the dot separators.)
If, on the other hand, for any LabelledGeneric I could obtain an iterable collection holding all of the possible Lenses for that LabelledGeneric type, then I could stringify them to eliminate weakness (a); and I could require the user to provide filters+sorts as Lenses and test all of them for membership in the collection, thus converting weakness (b) from sending bad data to the peer to failing internally at runtime. What is the best path forward to this state?