-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow for easier calls to included data #109
Comments
I am not sure if you mean you’ve already looked into https://github.com/mattpolzin/JSONAPI-ResourceStorage but if not then that’s the direction I would point you. Although that isn’t as polished of a library as my main JSONAPI library, it does show two alternative approaches to storing and retrieving information found in JSONAPI documents. The reason I don’t plan to integrate a solution into this main JSONAPI library is that I can see benefits to totally different approaches and I don’t want this library to make that decision for the end user. Personally, I like leaning into values and avoiding classes so I’ve mostly used the approach that the above-linked library calls So it isn’t so much about what Swift allows as it is about how Swift makes it possible to lean heavily on value types if you want to, but value types don’t allow for the type of code you wanted to write above. The nice thing about the extra library that implements the two strategies is that it really doesn’t contain many lines of code — feel free to use the library if it works as is, or use the ideas, or rip the code out of it and modify it to be exactly what your ideal solution would be. Let me know if you have more questions or if I’ve not quite answered this one! |
Hi Matt, Thanks for your response. I tried the library and it works fine for most parts. However, I tried a larger include (Include13) which is not supported. So I added extension for 12 and 13. But now it complains about the following but I am not sure which library here is at fault or what I missed.. Referencing instance method 'resourceCache()' on 'EncodableJSONAPIDocument' requires the types 'Poly13<...>` and Poly0 be equivalent. Not sure where to go from here. Could you perhaps put me in the right direction? Thank you so much. |
I suspect the problem is in your resource cache code or possibly a bug in that library. Can you share your ResourceCache type and Materializable conformances? Or at least the Materializable conformances for the primary resource and the 13th include type in the case where your above error is thrown? |
Well, from the docs I assumed I only needed to cache all the includes and not the primaryResource.. I now added it.
And this is the Include13
If I dive into the function resourceCache I see that it goes to
While I think that it should go to the one with includes? |
Yeah, that's a good lead. I tried to throw together the simplest possible reproduction of your situation I could to see where typealias Doc = JSONAPI.Document<ManyResourceBody<EntryResource>, NoMetadata, NoLinks, Include13<TypeResource,TypeResource,TypeResource,TypeResource,TypeResource,TypeResource,TypeResource,TypeResource,TypeResource,TypeResource,TypeResource,TypeResource,TypeResource>, NoAPIDescription, UnknownJSONAPIError> It's nonsensical to make every type of include the same, but I just wanted to reproduce the compiler error you were seeing. |
this is how it looks for me
|
Nothing stands out as obviously problematic so instead of just asking for even more of your source code, how about:
|
Hi Matt, I debugged for quite a bit until I noticed that I did not have everything implementing Materializable. 😅 after fixing that it seems to work better. |
Oh, gotcha. I wish the error were clearer but that does make sense. |
Hi Matt,
We are using this library intensively. However, one thing that is very cumbersome somehow, is working with relationships and included object.
We are looking for way to expose the relationships included data easier. Something like this
And maybe something like this for the entire array?
I have seen the examples of all the caches etc but it results in a lot of boilerplate code and messy code imo. Is something like above possible or is this some limitations we have in Swift currently? I would also love to help with a PR myself if you could give some advice on how to approach this :)
Love to hear your thoughts!
The text was updated successfully, but these errors were encountered: