Singular Resource Handling (read/write operations)

[bilouw]

Hi Everyone !

Problem: If you try to save a Spraypaint model, it will automatically add the ID of the resource at the end of the url. With Singular Resource in rails, we don't need id to update a resource.

Solution:

export default class User extends ApplicationRecord {
  static jsonapiType = 'users'
  static singularResource = true
}

I want to improve Spraypaint to be able to use it with Singular Resource.
For now, i do some tricks to handle singular resource reading.

Today, i just want to unlock write operations.

Instead of: PATCH /api/user/:id -> PATCH /api/user

So i added an singularResource attribute to Spraypaint models. If this attributes equal true, then making an update will call the endpoint without id in url.

If i have more time, i will use this singularResource attribute in the future to fully handle Singular Resource in Spraypaint.

It's my first PR ever, so tell me if i'm doing a terrible thing :). (or if my idea is good or bad)

[richmolj]

Thanks @bilouw ❤️ ! I think this looks good but @wadetandy might have a better idea?

[bilouw]

Thanks for your feedback @richmolj ! I just added two features:

1. Problem: We can't call .find() without id to fetch singular resource.

Solution: I made the id argument optional and id will not be merge in endpoint if it's present and if singularResource = true.

2. Problem: Let's say we have a singular resource User with jsonApiType = 'users'. We want to call enpoint '/user' and not '/users'., without overriding the endpoint variable.

Solution: The url() function (model.ts) should singuralize model name (/user instead of /users) to build endpoint if singularResource = true.

What do you think about that @richmolj ?

[wadetandy]

I think the functionality of this whole PR is good, but as it's an uncommon case I don't love the type change of making id optional to find here, as for 99% of projects a missing id is incorrect and will result in confusing errors that the type system could easily catch. Perhaps we can come up with a parallel method that is only used for singular resources? findOnly() load, i'm not loving those but I'm open to other ideas.

[bilouw]

My idea was to let the singularResource variable determine the way the find() function behave. But i understand your point, i thought about making a parallel method too. does get() suit you for the method name, or is it too generic ?

Also, with my changes calling find('someId') will construct an endpoint url without id if singularResource = true, so maybe another method is not necessary and we could just use the method like this: find('whatever') leaving the id of find() mandatory.

[wadetandy]

what about findSingle?

[bilouw]

I'm agree with this name. I just made the change, can this be merge ?