(recapping discussion with @Blesh, who will probably correct me)
Current State
Right now, the Connection interface, which is implemented by XHRConnection, JSONPConnection, and MockConnection, has simple interface:
interface Connection {
readyState: ReadyStates;
request: Request;
response: Observable<Response>;
}
Calls to the Http service return the connection.response observable, so end users don't really interact with this interface too much in application code. In tests, however, users will be working with MockConnection instances created by MockBackend in order to create mock responses for requests.
myService.getUsers().subscribe(users => {
expect(users[0].name).toBe('Rob');
async.done();
});
mockBackend.connections.subscribe(connection => {
connection.mockRespond(mockUsers);
});
(Note that the mock responding mechanism should be further improved, but that's outside the scope of this proposal).
Proposal
Change Connection itself to be an Observable of Response, and keep request property intact. @Blesh says it aint so bad to add properties to Observables (though adding methods is a bad idea because observable methods are expected to be operators).
interface Connection extends Observable<Response> { //Observable interface doesn't actually exist yet
readyState: ReadyStates; // I would like to get rid of this property
request: Request;
}
MockConnection should extend subject, so that it can be next-ed with Responses.
class MockConnection extends Subject<Response> implements Connection {
readyState: ReadyStates;
request: Request;
}
This change is actually pretty minor from an end-user perspective, other than the change of calling next on the MockConnection rather than the current mockRespond. But internally, it reduces cruft and simplifies logic.
CC: @robwormald
(recapping discussion with @Blesh, who will probably correct me)
Current State
Right now, the
Connectioninterface, which is implemented byXHRConnection,JSONPConnection, andMockConnection, has simple interface:Calls to the Http service return the
connection.responseobservable, so end users don't really interact with this interface too much in application code. In tests, however, users will be working withMockConnectioninstances created byMockBackendin order to create mock responses for requests.(Note that the mock responding mechanism should be further improved, but that's outside the scope of this proposal).
Proposal
Change
Connectionitself to be an Observable ofResponse, and keeprequestproperty intact. @Blesh says it aint so bad to add properties to Observables (though adding methods is a bad idea because observable methods are expected to be operators).MockConnectionshould extend subject, so that it can benext-ed withResponses.This change is actually pretty minor from an end-user perspective, other than the change of calling
nexton theMockConnectionrather than the currentmockRespond. But internally, it reduces cruft and simplifies logic.CC: @robwormald