These are chat archives for orbitjs/orbit.js

10th
Jun 2016
Mitch Lloyd
@mitchlloyd
Jun 10 2016 02:50

Everything above makes sense to me. I think erring on the side of fewer objects and less abstraction is the safest path, so eliminating network seems like a good move.

As far as merging this PR "sooner rather than later", let's prioritize public facing changes over this PR. I'm fine with a rebase here and there as I'm getting a lot of value just from running through this exercise.

I do not like any methods on schema that mutate data, so initializeRecord on the schema feels bad to me. For now we can put the onus on the serializer to co-ordinate these interactions as suggested. When people start building their own serializers however this could become a burden.

Although it might seem like a pedantic request, I think it would be nice to use a strategy pattern and not fall into the "base serializer" approach that Ember Data has. It would be nice to have a clear delineation between what every serializer must do and what is specific to each serializer strategy. A battle for another time perhaps.

Dan Gebhardt
@dgeb
Jun 10 2016 02:55
@mitchlloyd I'm glad you agree about holding off on Network (perhaps indefinitely). Also I appreciate your willingness to rebase a bit. For my part, I'll try to avoid sweeping gratuitous renaming refactors until we can land your work ;)
I also don't see the need for a "base serializer" like Ember Data's. I think we might want to export some helper functions from a common module instead.
Anyway, feel free to move some logic directly into JSONAPISerializer for now if the abstractions don't feel clean. We can always let them emerge as we introduce more serialization strategies.