Serialize and Deserialize data from/to server

[kentcdodds]

My server gives me properties with names like first_name and I don't like dealing with that in my code (I'd rather camel case it). So this is what I have:

app.config(function (DSHttpAdapterProvider) {
  // Because I don't want to deal with snake_case properties in here...
  // I convert to camel on the way in
  DSHttpAdapterProvider.defaults.serialize = function serialize(resourceName, attrs, cb) {
    cb(null, attrs.map(function snakeToCamel(s) {
      return s.replace(/(\_\w)/g, function(m){
        return m[1].toUpperCase();
      });
    }));
  };

  // I convert to snake on the way out
  DSHttpAdapterProvider.defaults.deserialize = function deserialize(resourceName, attrs, cb) {
    cb(null, attrs.map(function camelToSnake(s) {
      return s.replace(/([A-Z])/g, function(m) {
        return '_' + m.toLowerCase();
      });
    }));
  };

});

But I'm getting undefined errors on DSHttpAdapterProvider.defaults, so I've tried it without the defaults and I tried putting it on DSProvider.defaults just for fun, but it's never called in those cases. What am I doing wrong?

[jmdobry]

The serialize and deserialize methods are not asynchronous. Here is what the defaults look like:

serialize: function (data) {
  return data;
},

deserialize: function (data) {
  return data;
},

[kentcdodds]

Oh, duh! Ok, is there any way that I can tell what resource it is? Let's say I had custom de/serialization rules for my User object...

[kentcdodds]

Oh, and which is it. Is it DSProvider.defaults or is it DSHttpAdapterProvider because I couldn't get it to even be called... Though I was successfully making a find request...

[jmdobry]

I didn't think of that when I wrote it. I did that for the lifecycle methods, but not these. It looks like you were expecting them to be like the lifecycle methods.

And I think it's DSHttpAdapter.defaults.

I will document this better.

EDIT:
It's DSHttpAdapterProvider.defaults or DSHttpAdapter.defaults.

[jmdobry]

Actually, it works like $http. DSHttpAdapterProvider.defaults and DSHttpAdapter.defaults point to the same object.

[kentcdodds]

Hmmm... Well, like I said, I'm getting that DSHttpAdapterProvider.defaults is undefined in that code above... any idea why that might be?

[kentcdodds]

It looks like DSHttpAdapterProvider has a single property called $get that's an array:

0: "$http"
1: "$log"
2: "DSUtils"
3: function ($http, $log, DSUtils) {}

[jmdobry]

Oops, an entire block of code was nested one level too deep...

That's what I get for not having tests for the adapter yet. Better get those before 0.9.0.

[jmdobry]

Until 0.9.0, you'll just have to set the default in the run block

[kentcdodds]

Awesome. Glad we found that 👍 Thanks!

[kentcdodds]

While you're at it, it would be sweet to have a resourceName parameter :-) Or even be able to override the de/serialization at the resource level...

[jmdobry]

It would be useful to know the resource type in the serialize/deserialize methods, but the DSHttpAdapter API exposes its GET/PUT/POST/DEL/HTTP methods, which when called, are only passed http-related configuration. If you call DSHttpAdapter.HTTP(...), it has know idea what resource it's for.

Perhaps I put the serialization/deserialization in the wrong place. Perhaps this should happen on the DS side of the DS <-> Adapter interface. This would unify how serialization/deserialization happens across adapters.

EDIT: and then it would be simple to define serialization/deserialization on a per-resource basis.

[kentcdodds]

That makes sense to me. Plus, if I understand it correctly, if I really want to, I can put this on $http myself can't I? So this actually doesn't provide a ton of value as it is, correct?

[jmdobry]

Plus, if I understand it correctly, if I really want to, I can put this on $http myself can't I? So this actually doesn't provide a ton of value as it is, correct?

Correct.

If serialization/deserialization is moved to the DS side of the interface, then they'll start to provide more value because they'll work for all adapters, be configurable on a pre-resource basis, and tell you which resource type is being acted upon.

[kentcdodds]

💰 cha-ching!

[jmdobry]

Luckily, because of the way I wrote the resource definition system, simply by moving this over to the DS, (de)serialization will automagically be configurable globally and per-resource.