{"action":"created","issue":{"url":"https://api.github.com/repos/code-corps/code-corps-ember/issues/33","labels_url":"https://api.github.com/repos/code-corps/code-corps-ember/issues/33/labels{/name}","comments_url":"https://api.github.com/repos/code-corps/code-corps-ember/issues/33/comments","events_url":"https://api.github.com/repos/code-corps/code-corps-ember/issues/33/events","html_url":"https://github.com/code-corps/code-corps-ember/pull/33","id":122543697,"number":33,"title":"Profile route","user":{"login":"begedin","id":1925540,"avatar_url":"https://avatars.githubusercontent.com/u/1925540?v=3","gravatar_id":"","url":"https://api.github.com/users/begedin","html_url":"https://github.com/begedin","followers_url":"https://api.github.com/users/begedin/followers","following_url":"https://api.github.com/users/begedin/following{/other_user}","gists_url":"https://api.github.com/users/begedin/gists{/gist_id}","starred_url":"https://api.github.com/users/begedin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/begedin/subscriptions","organizations_url":"https://api.github.com/users/begedin/orgs","repos_url":"https://api.github.com/users/begedin/repos","events_url":"https://api.github.com/users/begedin/events{/privacy}","received_events_url":"https://api.github.com/users/begedin/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/code-corps/code-corps-ember/labels/awaiting%20review","name":"awaiting review","color":"5319e7"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-12-16T16:22:29Z","updated_at":"2016-01-15T07:17:36Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/code-corps/code-corps-ember/pulls/33","html_url":"https://github.com/code-corps/code-corps-ember/pull/33","diff_url":"https://github.com/code-corps/code-corps-ember/pull/33.diff","patch_url":"https://github.com/code-corps/code-corps-ember/pull/33.patch"},"body":"Closes #20, #22 when done\r\n\r\nThis PR, in the current state, mostly servers as a proof of concept for using integration tests for components and ember-mirage in conjunction with acceptance tests.\r\n\r\nAfter my experiences today, I'm leaning against using ember-mirage, at least no in the current, stable 0.1 release. At some point in the future, it will be great, but I don't think it is right now, without a lot of overhead we need to handle.\r\n\r\n* server.create('type') doesn't create a DS.model, just a plain object payload (something the server would return as a response), so we can't use moel instance directly (for the purposes of unit/integration testing, for example).\r\n* json api isn't supported, so we need to wrap all of our requests in proper formats. this means we can't use any of the verb shorthands.\r\n* request wrapping means we need to basically manually implement a patch method since it needs to\r\n  * find and update the affected record in mirage's database\r\n  * return a proper response\r\n* it's a pain to use mirage outside of acceptance tests in general, since we need to manually load mirage test helpers\r\n\r\n\r\nA good alternative would be ember-data-factory-guy. It's not without it's issues, but the server requests/responses, at least, are handled automagically.\r\n\r\nIn my opinion, at a later point in development, mirage will be the way to go, but right now, ember-data-factory-guy, in conjunction with, perhaps, ember-cli-faker, would be the simpler approach."},"comment":{"url":"https://api.github.com/repos/code-corps/code-corps-ember/issues/comments/171890444","html_url":"https://github.com/code-corps/code-corps-ember/pull/33#issuecomment-171890444","issue_url":"https://api.github.com/repos/code-corps/code-corps-ember/issues/33","id":171890444,"user":{"login":"begedin","id":1925540,"avatar_url":"https://avatars.githubusercontent.com/u/1925540?v=3","gravatar_id":"","url":"https://api.github.com/users/begedin","html_url":"https://github.com/begedin","followers_url":"https://api.github.com/users/begedin/followers","following_url":"https://api.github.com/users/begedin/following{/other_user}","gists_url":"https://api.github.com/users/begedin/gists{/gist_id}","starred_url":"https://api.github.com/users/begedin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/begedin/subscriptions","organizations_url":"https://api.github.com/users/begedin/orgs","repos_url":"https://api.github.com/users/begedin/repos","events_url":"https://api.github.com/users/begedin/events{/privacy}","received_events_url":"https://api.github.com/users/begedin/received_events","type":"User","site_admin":false},"created_at":"2016-01-15T07:17:36Z","updated_at":"2016-01-15T07:17:36Z","body":"@JoshSmith This still isn't ready for merge, but it's much better than it was. With the mirage update, mocking the `GET /users/:id` request works just fine.\r\n\r\nThis comment should serve both as a checklist for myself and as something we can base our discussion on.\r\n\r\nFirst of all, is this a general user's profile page, or the current user's profile page? Right now, I'm approaching it as the current user's profile page, which can be edited if the the current user is the user being viewed, but that behavior isn't really implemented yet.\r\n\r\n* [ ] Make it so that the profile is editable only if the current user is the user being viewed. Take into account the possibility of this power being extended to admins by making it some sort of `canEdit` property.\r\n\r\n\r\nBased on #20 - Profile page should include\r\n* Basic information \r\n  * [ ] name\r\n  * [x] username\r\n* [ ] Photo\r\n* [ ] Skills - this one probably won't be added in this PR, since we don't have skills yet\r\n* [x] Website\r\n* [x] Twitter\r\n* [x] Biography\r\n* [ ] Contributions - again, probably not added with this PR\r\n\r\nBased on #22, we should also add editing capabilities. This is what can currently be edited\r\n* username\r\n* website\r\n* twitter\r\n* biography\r\n\r\nI'm not sure skill should be editable from the profile, or a separate page, but that's for a different PR, not this one.\r\n\r\n* [ ] Should the username be editable? I'm actually thinking no, at least for now, because I'm not sure if that will complicate things too much on the API side.\r\n* [ ] I still need to add in the option to edit the user photo, once it's shown here, but considering we'll probably need some library for that, it might be a good idea to put it in a separate PR. We can display the photo in this one, but make it editable in another one."}}