ember-data-github
ember-data-github copied to clipboard
elwayman02
Add Files Model
This is currently treated as a blob object in the tree model: https://github.com/elwayman02/ember-data-github/blob/master/addon/models/github-tree.js#L6
If we can define its shape, we should do so.
This seems like a more useful 1.0 candidate than supporting entirely new APIs that we haven't begun implementing yet.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
Once https://github.com/elwayman02/ember-data-github/pull/140 lands this model will exist and it can be wired up to the tree model as well
Looking at this and https://github.com/elwayman02/ember-data-github/issues/136 some more I'm not sure that Files or Directories are actually models that relate to trees. The current logic pulls the path and sha out of the tree for trees and blobs respectively. I'm not sure what use this information is to consumers, but it might make more sense for these to be computeds on the tree model and not actual relationships to actual models themselves.
As a comparison, the files array that comes back from a single commit makes sense as a model but does not match anything that comes along with trees
"files": [
{
"filename": "file1.txt",
"additions": 10,
"deletions": 2,
"changes": 12,
"status": "modified",
"raw_url": "https://github.com/octocat/Hello-World/raw/7ca483543807a51b6079e54ac4cc392bc29ae284/file1.txt",
"blob_url": "https://github.com/octocat/Hello-World/blob/7ca483543807a51b6079e54ac4cc392bc29ae284/file1.txt",
"patch": "@@ -29,7 +29,7 @@\n....."
}
]
That's fair. If there are inconsistencies in the API, seems reasonable to make a model for the commit "files" and leave the trees one out of it.
In this case I think github is being consistent, I'm just not sure what this addon was trying to accomplish with how it has things setup.
In any event, the file model does exist for commits and that seems to be working ok at this point.