Разработка угловых приложений без бэкенда с использованием MockBackend

Компонент приложения настроен для использования с селектором my-app , загружая шаблон index.html расположенный в подпапке templates . Наконец, providers сообщают DI Angular, что мы хотели бы получить экземпляр TicketService .

 ... @Component({ selector: 'my-app', templateUrl: 'app/templates/index.html', providers: [TicketService] }) export class AppComponent { 

Далее мы определяем свойство класса db , которое будет содержать набор поддельных билетов.

 // Fake Tickets DB private db: Ticket[] = [ new Ticket( '1', 'Missing Exception', 'John Smith', 'Method XYZ should throw exception in case ABC', 0), new Ticket( '2', 'Log errors', 'John Smith', 'Logs need to be persisted to a local file', 24), new Ticket( '3', 'Update AngularJS', 'John Smith', 'Need to update the App to AngularJS version 1.5', 0), new Ticket( '4', 'Border is missing', 'Jane Doe', 'The element div.demo has no border defined', 100), new Ticket( '5', 'Introduce responsive grid', 'Jane Doe', 'Implement reponsive grid for better displays on mobile devices', 17) ]; 

Конструктор теперь получает TicketService а также фальшивый TicketService . Здесь мы теперь подписываемся на поток connections . Для каждого исходящего запроса мы теперь проверяем его request.method и request.url , чтобы выяснить, какой тип конечной точки запрашивается. Если правильный маршрут совпадает, мы отвечаем, используя метод mockRespond , с новым Response содержащим ожидаемый результат в качестве тела, который инициализируется с классом ResponseOptions .

 constructor(private service: TicketService, private backend: MockBackend) { this.backend.connections.subscribe( c => { let singleTicketMatcher = /\/api\/ticket\/([0-9]+)/i; // return all tickets // GET: /ticket if (c.request.url === "http://localhost:8080/api/ticket" && c.request.method === 0) { let res = new Response( new ResponseOptions({ body: JSON.stringify(this.db) })); c.mockRespond(res); } 

При запросе одного билета мы используем определенное выше singleTicketMatcher , чтобы выполнить поиск по регулярному выражению в request.url . После этого мы ищем заданный идентификатор и отвечаем соответствующей сущностью заявки.

 // return ticket matching the given id // GET: /ticket/:id else if (c.request.url.match(singleTicketMatcher) && c.request.method === 0) { let matches = this.db.filter( (t) => { return t._id == c.request.url.match(singleTicketMatcher)[1] }); c.mockRespond(new Response( new ResponseOptions({ body: JSON.stringify(matches[0]) }))); } 

В случае обновлений и создания новых заявок мы получаем объект заявки через тело запроса вместо параметра запроса или шаблона URL. Кроме того, работа довольно проста. Сначала мы проверяем, существует ли билет, и обновляем его, в противном случае создаем новый и отправляем обратно с ответом. Мы делаем это для того, чтобы сообщить запрашивающей стороне о новом идентификаторе билета.

  // Add or update a ticket // POST: /ticket else if (c.request.url === 'http://localhost:8080/api/ticket' && c.request.method === 1) { let newTicket: Ticket = JSON.parse(c.request._body); let existingTicket = this.db.filter( (ticket: Ticket) => { return ticket._id == newTicket._id}); if (existingTicket && existingTicket.length === 1) { Object.assign(existingTicket[0], newTicket); c.mockRespond(new Response( new ResponseOptions({ body: JSON.stringify(existingTicket[0]) }))); } else { newTicket._id = parseInt(_.max(this.db, function(t) { return t._id; })._id || 0, 10) + 1 + ''; this.db.push(newTicket); c.mockRespond(new Response( new ResponseOptions({ body: JSON.stringify(newTicket) }))); } } // Delete a ticket // DELETE: /ticket/:id else if (c.request.url.match(singleTicketMatcher) && c.request.method === 3) { let ticketId = c.request.url.match(singleTicketMatcher)[1]; let pos = _.indexOf(_.pluck(this.db, '_id'), ticketId); this.db.splice(pos, 1); c.mockRespond(new Response( new ResponseOptions({ body: JSON.stringify({}) }))); } }); } 

И последнее, но не менее ngOnInit хук жизненного цикла страницы ngOnInit запустит загрузку всех билетов, когда компонент будет полностью визуализирован.

 public ngOnInit() { this.service.loadAllTickets(); } } 

В реальном производственном приложении вы бы разделили макет установки в отдельный сервис и вставили его как зависимость в AppComponent. Или, что еще лучше, вы создали бы совершенно новый модуль, содержащий ваш поддельный сервер, и добавили бы его в корневой модуль вашего приложения. Это опущено здесь для упрощения демонстрации.

Глядя на TicketComponent мы видим, что ничего интересного не происходит, кроме декоратора компонентов. Мы определяем ticket как селектор и снова указываем на отдельный файл шаблона. Теперь, в отличие от AppComponent , мы ожидаем, что тег AppComponent будет создан с атрибутом с именем title и получит визуализируемый объект.

Затем конструктор, наконец, TicketService и назначает его service свойств класса.

 import { Component, Input } from '@angular/core'; import {Ticket} from './ticket.entity'; import {TicketService} from './ticket.service'; @Component({ moduleId: module.id, selector: 'ticket', templateUrl: 'templates/ticket.html', //providers: [TicketService] < -- this would override the parent DI instance }) export class TicketComponent { @Input('ticket') ticket: Ticket; constructor(private service: TicketService) { } } 

Служба заказа билетов

Последнее, чего не хватает, — это TicketService , который используется для абстрагирования вызовов Ajax от компонентов. Как мы видим, он ожидает, что сервис http будет введен. Теперь, помня исходный файл boot.ts , мы знаем, что предоставленный экземпляр будет тем с boot.ts . Фактический запрос остается прежним, используя методы запроса служб HTTP такие как post или get , отображая результат — который в этом случае будет поддельным ответом — и продолжая использовать собственную логику приложения.

 import {Ticket} from './ticket.entity'; import {Injectable} from '@angular/core'; import {Http, Headers} from '@angular/http'; import 'rxjs/add/operator/map'; @Injectable() export class TicketService { tickets: Ticket[] = []; constructor(private http: Http) { } addNewTicket() { var headers = new Headers(); headers.append('Content-Type', 'application/json'); var newTicket = new Ticket("0", 'New Ticket', 'Nobody', 'Enter ticket description here', 0); this.http .post('http://localhost:8080/api/ticket', JSON.stringify(newTicket), headers) .map(res => res.json()) .subscribe( data => this.tickets.push(data), err => this.logError(err), () => console.log('Updated Ticket') ); } saveTicket(ticket: Ticket) { ... } deleteTicket(ticket: Ticket) { ... } loadAllTickets() { ... } loadTicketById(id) { ... } logError(err) { console.error('There was an error: ' + err); } } 

Вывод

Подводя итог, мы увидели, как внедрение зависимостей Angular может помочь нам заменить стандартный XHRBackend службы HTTP на XHRBackend . Внутри AppComponent мы затем создали нашу поддельную базу данных, перехватили каждый исходящий запрос и ответили специальным поддельным ответом. Преимущества, которые мы получили, теперь — полная независимость от серверной части и, в то же время, определенный интерфейс. Теперь, когда производственный бэкэнд будет создан, все, что нам нужно сделать, — это удалить переопределение внедрения зависимостей и фальшивый бэкэнд, и мы готовы к работе.

Эта статья была рецензирована Дэном Принсом и Раби Кираном . Спасибо всем рецензентам SitePoint за то, что сделали контент SitePoint как можно лучше!