DRY out the code base: part 1

[lottspot]

Right now, the code base is full of copy/pasta, and consequently painful amounts of repeated boiler plate code. Our code base would benefit a lot from identifying these areas that have lots of this repeated boiler plate and consolidating it into reusable code. This thread will be used to identify the modules that we want to target to make more DRY.

[kgdiem]

I see you guys started to implement ES6, nice addition.

I'd say that lib/objects/* is redundant. It's a nice idea in theory, like those classes are an interface that provides some type safety, but JS is not a typed language.

Even if we were to check isPrototypeOf in the controller there's no guarantee that the resulting objects have any or all of the properties in the "class" definition. Any one of the attributes argument's properties could be undefined and no error would be thrown.

For example, the following code runs just fine:

function CampaignInfo (attributes) {
  this.campaign_id = attributes.campaign_id;
  this.election_year = attributes.election_year;
  this.election_cycle = attributes.election_cycle;
  this.candidate_id = attributes.candidate_id;
  this.candidate_position = attributes.candidate_position;
  this.candidate_party = attributes.candidate_party;
}

CampaignInfo.prototype.toJSON = function campaignInfoToJSON () {
  return {
    campaign_id: this.campaign_id,
    election_year: this.election_year,
    election_cycle: this.election_cycle,
    candidate_id: this.candidate_id,
    candidate_position: this.candidate_position,
    candidate_party: this.candidate_party
  };
};

var x = new CampaignInfo({});
var y = new CampaignInfo("");
var z = new CampaignInfo([]);

x.toJSON();
y.toJSON();
z.toJSON();

So, rather than turning JSON objects/object literals into an Object with a toJSON method I propose we just use the object literal that would be passed as the attributes argument.

Rather than two function calls, constructing the object and later turning it into JSON, there could be a single function that takes attributes and returns an object literal/JSON object that ensures the properties we want are there, ex:

 function toCampaignInfo(attributes){
  return {
    campaign_id: attributes.campaign_id,
    ...
    candidate_party: attributes.candidate_party,
  }
}

Could also just return the following to ensure consistency:

{
  campaign_id: queryResponse.campaign_id,
  ...
  candidate_party: queryResponse.candidate_party,
}

[lottspot]

Your points are totally valid, and I think that a post-MVP discussion of the role of the API objects is quite warranted. The reason I thought, and continue to think, that having the API objects is worth it is two fold:

1. In-code definition of the API object spec: Defining the API objects allows the code to have a self-contained definition of the API specification. I think there is a lot of value in being able to read the code and easily ascertain what the data being passed to the user looks like.
2. Attaching methods to our data: By pushing our data into our defined API objects rather than pushing the raw data directly to the user, we can easily attach methods to those objects. I'm already thinking about the usefulness of something like a .verify() method, which could verify that the object has all of the data it's supposed to, and takes some action for us if it doesn't (log/throw/etc).

you have any thoughts @modpluz?

[modpluz]

I like having an "object transformer" for database records, which ensures that we are not returning the database columns "as is" back to the user (as also pointed out by @lottspot).

That being said, the structure of our object presently does not show any real value of using "transformers" at the moment because they have identical properties.

I propose that we apply the YAGNI principle here, we can then start worrying about transformations/object verifications when we deem it necessary.

P.S. Verifying the object properties would be a good place to start, perhaps a schema-like representation of an object that we can check attributes against.

P.P.S. We should also consider switching to strict mode.

[lottspot]

As far as the YAGNI principle is concerned, I would contend that we are in fact at a point where we need to verify our API objects. The discussion of "why" probably deserves its own thread, but as it concerns the API objects we have now, one possible way to do that is to implement a .verify() object method.

It sounds though like you think it would be a good idea if we restructured our API objects so that they would be useful as "transformers". I can't purport to totally know what you mean-- Can you give an example?