Interesting, I get what you're saying. Honestly would be amazing to see your codebase to get architectural ideas. I've never seen anyone pull what you describe off, so honestly a very intriguing possibility. In any case I think I have enough to at least dig further into the framework and see if I can keep things simple.
We use Vue/Vuetify/Vuex and a custom library I’m working on called vuex-jsonapi (https://github.com/arcreative/vuex-jsonapi.git). The library needs documentation, will see if I can hammer that out today since it’s really hard to get an idea of how wonderful it makes life on the client-side. It’s not perfect—the store implementation feels a little clunky right now, and it could use pluggable serializers and deserializers, but I’ve been really slammed for time developing a new app that’s both behind schedule and was never on our company’s roadmap. Since building an MVP, though, it’s been allowing me to absolutely FLY through my projects. Actual implementations are proprietary, but I’ll see if I can throw together a couple model/resource examples for some context.
The main crux of this library is that most Vuex implementations use a huge, messy store with hundreds of explicit states/mutations/actions, but I’ve abstracted all of that into “channels”. Want to load users on some sort of contacts index? Fire
this.$store.dispatch(‘find’, ... and just map the channel to make it accessible to your component(s). Literally zero changes to your Vuex store, and it automatically handles loading/error messages/attribute errors/no records as well as emits events for reloading related models/channels or displaying app-wide success/error messages, all while maintaining perfect reactivity. Want to save? Just dispatch a save and listen for didUpdateRecord or didUpdate<modelType>
Thank you!!
Once there's an official update for support in the spec, work can begin to add support to jsonapi-resources.
You can follow progress on json-api/json-api#795
AFAIK, JR doesn’t distinguish base from a regular attribute because it well could be an actual one
Gotcha. I still like it on the resource from the perspective that I can assume it’s always a user-friendly error for client-side display, but maybe I’ll take a look at raising a request-wide error instead. It’s just that adding an error to the model is easier and more compatible with the normal workflow and doesn’t violate separation of concerns by ether raising the error outside the resource, validating outside the model, or having to bubble and rescue some other type of error.
Sorry, that was supposed to say “adding a validator”
We have a lot of logic built into our models and resources to make common things easier, like
static_attribute :foo which sets up validations for us.
Will have a to take a deeper look
The permissions stuff is minimal for us, but definitely applicable
I’m using jsonapi-authorization gem, but it gets tricky on create since you don’t have access to the attributes
It’s also sub-optimal sometimes since a straight up 403 error doesn’t give great context for what’s not allowed. Our client application needs more-than-reasonable knowledge about authorization concerns at times, would be nice to let the validator provide more verbosity
Or base error, in this case. Thanks for sharing that!
We have
UserService which tells us exactly what a user can view, edit, delete. We use records to call into the methods and do 90% of our checks.
That allows us to give detailed responses, and handle things like returning a 404 if the resource exists, but you don't have permission to view it.
Hello, I have a request that I seem to be able to fulfil only by monkey patching the URL builder. We have multiple services deployed each in with their own url path: e.g
api.company.com/<service_name>/<resource>. The links to self return me api.company.com/<resource>/<id>. Is there a way to configure JSON api to specify the service name?
digging the source code, I found this: https://github.com/cerebris/jsonapi-resources/pull/1137/files, but I'm unsure how to use this...
Or alternatively a scope—if that works it’ll be less work since you won’t have to namespace all your classes
so if I add the scope, I would have the request pointing
api.company.com/<service_name>/<service_name>/<resource>
I ran into an issue with eager_load_on_include using jsonapi-resources (0.9.10) on Rails 5.2.3
I have a PersonResource that has_one: preferences, eager_load_on_include: false , where preferences is a non-AR resource
if I call {{url}}/people/#{id}/?include=preferences I run into join issues"Can't join 'Person' to association named 'preferences'
as a functional workaround when I set it to polymorphic (which it is not) has_one :preferences, polymorphic: true it does work , as I am defining the record_for_preferences in the PersonResource
looking at the gemcode I see that for polymorphic relations it skips the join which is actually what I expected for
eager_load_on_include to happen :|
specifically this section
https://github.com/cerebris/jsonapi-resources/blob/v0.9.10/lib/jsonapi/resource.rb#L1283-L1288
inspired me to try polymorphic: true even though the documentation does point to eager_load_on_include for my exact usecase
if this is considered a bug I'll try to file it , though I should ask here before :D
is it possible to make strong params for creating or updating a resource?
If you need the params, you can grab it most places from the context
You specify the allowed attributes in the resource with
self.creatable_fields and self.updatable_fields
found the GH issue related to what I posted and added my comment there cerebris/jsonapi-resources#1169
Hi, I’m trying to select a ST_Distance() (using postgis) as an extra field and present it as a meta attribute on my resource. But not sure how to go about it. the filter selects it, but then when it comes to serializing, there’s a second SELECT that pulls them back through without the extra field. What should I be doing?
@arcreative Regarding the base vs non-base (sorry didn't see the message before). Rails treats base a bit differently than non-base. In the JSON:API spec, errors on the object itself rather than an attribute are to be represented differently.
https://jsonapi.org/format/#errors
pointer: a JSON Pointer [RFC6901] to the associated entity in the request document [e.g. "/data" for a primary data object, or "/data/attributes/title" for a specific attribute].
That's where I got my idea from.