refactor to make way for easy feature adding

[NullVoxPopuli]

Big methods can be hard to work with.

Since there are upcoming changes to the json adapter, I figured I'd make things a little easier to digest (especially re: recursion).

[bf4]

it's an internal thing that uses that value instead of a serialized attribute. e.g. there's no serializer for Ruby arrays, so it would just use the array as the virtual value. see #962

[NullVoxPopuli]

ah ok, cool.

I'll add a comment about that to help future contributors.

[bf4]

💯 Some thoughts:

• I think all the new methods should be private so that we can change them with impunity, and would need to opt-in any we want to be part of the public interface
• Would be good to take a look at the json api adapter for any common themes, but not required esp if all the new methods are private

thoughts?

[NullVoxPopuli]

• I think some of the methods could be private
• There is def some overlap in functionality of some methods (at a high level) between these refactored json methods and the json_api methods.

I'll see what I can do to mimic json_api's naming and flow.

[beauby]

I know the terminology comes from the json_api adapter, but I think add_to_many_relationship and add_to_one_relationship are more intuitive name than the confusingly similar add_relationship/add_relationships.

[NullVoxPopuli]

I agree, should json_api's naming change as well? - I am not as familiar with json_api though

[joaomdmoura]

This is really nice. I'm closing it because it was already ported on #1114