WIP: hit backend api #85
Conversation
| pageDescription: 'Some description.' | ||
| } | ||
| }; | ||
|
|
There was a problem hiding this comment.
I think these moved to locality, but yeah, this is the right idea.
|
Looks like we're on the right track. Is there a corresponding backend branch that can be used to test this against? |
|
Thanks @adborden for the notes! With caciviclab/disclosure-backend#149 , I finally understand the frontend/backend interaction. Once I get caciviclab/disclosure-backend#149 squared away, I will update here. |
|
@adborden Just one quick question: is the |
|
On Tue, 2016-01-26 at 08:27 -0800, Ben Cipollini [email protected] wrote:
Mostly. I think the nickname would also include the '.list' or I should also mention that the Aaron Borden |
|
@adborden This is updated, corresponding to backend PR caciviclab/disclosure-backend#177 |
| locality_id: $stateParams.locality_id | ||
| }).then(function(ballot) { | ||
| disclosureApi.ballot.summary({ballot_id: ballot.ballot_id}); | ||
| }); |
There was a problem hiding this comment.
@adborden This is more complex than before; I like the way this API is defined, but not sure if this is the right way to chain API calls.
There was a problem hiding this comment.
This works, but your hunch is right. angular ui-router cleans this up for us:
resolve: {
locality: function($stateParams, disclosureApi) {
return disclosureApi.locations.get({locality_id: $stateParams.locality_id});
},
ballot: function($stateParams, disclosureApi) {
return disclosureApi.locality.current_ballot({locality_id: $stateParams.locality_id });
},
ballotSummary: function(disclosureApi, ballot) {
return disclosureApi.ballot.summary({ballot_id: ballot.ballot_id});
}
}
| expect(ballot).to.have.property('ballot_id'); | ||
| expect(ballot).to.have.property('ballot_items'); | ||
| }); | ||
| }); |
There was a problem hiding this comment.
I would just use a known-good locality id. Otherwise it's testing too much IMHO.
|
This is great! The tests are a bit too complicated IMHO, so I'd like to swap the chained calls for known good IDs. As soon as the build is green I'll merge this. |
|
@adborden I'm not sure there are known good IDs that will be common to every system. It will depend on what data has been added to the backend. Perhaps simply refactoring the tests, so that they're easier to read, would keep the flexibility of running these tests on systems with different data, but make the tests easier to grok? |
I stubbed each API function in the back-end, so that the front-end can actually hit them. I'm 90% sure I'm doing this wrong, but hopefully I can get a pointer or two so I can learn how to do this for myself!