Demian Smith

if (["Andy", "Vasjya", "Petya"].includes(name))

Когда будите работать над Http Interceptor, как посоветовал Ivan Stroykin, проработайте обработку ошибок как следует. Интерсептор не должен возвращать null в случае ошибки. Он должен делать return Observable.throw(error).

Еще одно общее наблюдение: старайтесь функции, не использующие this выносить в отдельный файл (не сервис). Т.е. делать как-то так:

// get-data-response.ts
export function getDataResponse<T>(response: IResponse<T>) {
    if (response && response.data) {
      return response.data;
    } else {
      return null;
    }
  }

Так намного больше шансов на то что функция будет переиспользована где-то еще и не захламлена ненужными подробностями. Да и юнит-тестировать такой код гораздо проще.

В коде интерсептора перепутан респонз и реквест.

Что сейчас происходит:

1. Интерсептор перехватывает объект реквеста
2. Интерсептор добавляет в реквест { body: {data: messages} }
3. Интересептор передаёт реквест дальше на обратоку

Я так понимаю, идея интерсептора в том, чтоб ловить реквест и вместо передачи реквеста дальше на обратоку, возвращать ответ.

Попробуйте как-то так:

import {
  HttpRequest, 
  HttpEvent,
  HttpHandler,
  HttpInterceptor,
  HTTP_INTERCEPTORS
} from '@angular/common/http';

import { Injectable } from '@angular/core';

import { Observable } from 'rxjs/Observable';

import { messages } from 'src/fake-backend/data/messages/messages';

import { of } from 'rxjs/observable/of';

@Injectable()
export class FakeBackendInterceptor implements HttpInterceptor {
  constructor() { }

  intercept(req: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {

    console.log('HTTP REQUEST INTERCEPTED BY THE MOCKED BACKEND');

    return of(new HttpResponse({body: {data: messages}}));
  }
}

Полезность итераторов в том что это открытый интерфейс для любой структуры данных. Как вы уже поняли, любой класс/объект в JS может обладать интерфейсом итератора. Идея итератора в том чтобы скрыть внутреннее представление структуры данных от потребителя этих данных. Например, если вы работаете с какими-либо замысловатыми структурами данных, типа бинарных деревьев. Пользователю совсем не обязательно знать как ваш класс/объект хранит бинарное дерево. Пользователь просто его получает и проходит по всем его элементам в цикле. В дальнейшем, вы можете, при необходимости, заменить одну структуру данных на другую, не меняя самого пользователя. Например, вы можете заменить бинарное дерево на б-дерево прозрачно для самого пользователя (пользователь не будет знать что вы подменили структуры, он по прежнему получает что-то что можно проитерировать и ему этого достаточно).

Для того чтоб глубже понять суть вопроса, можно погуглить про инкапсуляцию и SOLID (в вашем случае, принцип Open/closed).

Уберите строчку require('owl.carousel') из gulp.js, потому что это не часть процесса сборки. И подключите owl.carousel тем же способом, каким подключаются и другие клиентские библиотеки. Например, попробуйте разобраться как подключается jQuery и подключите карусель таким же образом.

ngFor не работает с объектами, которые нельзя проитерировать. Нужно привести data['in'] к массиву. Попробуйте так:

this.listers = Object.values(data['in']);

Вообще, вся эта история с умными/глупыми компонентами, - о том как эти самые компоненты переиспользовать. Правило левой руки такое: если код зависит от внешнего состояния, то такой код становится сложно переиспользовать. Это относится не только к компонентам, но и к любому коду. connect добавляет зависимость от внешнего состояния, поэтому компонент, завязанный на connect преиспользовать и сложно.

Но вполне нормально юзать connect на любых компонентах. И, если коннект затрудняет переиспользование какого-то конкретного компонента, то всегда можно отвязаться от connect'a и передавать пропсы напрямую из компонента-родителя. Эдакий способ разработки снизу-вверх.

То с чем обычно удалённо работают админы:
Облака: AWS, Azure, Digital Ocean и т.п.
DevOps: CI/CD, Heroku и вот это всё
Наверняка что-то еще.

Когда сам фрилансил, то даже не брался за настройки серверов и релиз процессов, всегда убеждал заказчика нанять квалифицированного специалиста для этого. Долгое время работал с человеком, который брал 50 баксов в час за свою работу, но потом повысил планку и мы расстались, но продолжали общаться время от времени. По его словам, недостатка в работе он не видел. Так что по собственному опыту скажу что админ-фрилансер - это очень возможно.

Такие дела.

HttpClient работает так, что в функцию map прилетит уже готовый распаршенный json ответ, а не Response.

вот тут я немного коснулся менеджмента состояний в ангуляре:

ангуляр не предоставляет никаких средств для менеджмента состояния и попытки запихнуть состояние системы в переменную сервиса (это первое к чему приходят почти все разработчики на ангуляре) обычно заканчивается непредсказуемым поведением системы по мере её разрастания и невозможностью переиспользовать компоненты.

На сложном проекте без толкового менеджмента состояний очень легко наломать дров.

В принципе проект можно начать без редакса и прикрутить его по мере необходимости.

Вот полезная статья, которая многое проясняет https://medium.com/@dan_abramov/smart-and-dumb-com...

Идея в том чтоб каждый вопрос находился в своём компоненте и этот компонент был "тупым". Имеется ввиду что сам компонент на хранит ответ пользователя и не знает как его получить извне. Он получает предыдущий ответ пользователя через @@Input и отдаёт новый ответ пользователя через @@Output. Само состояние никогда не хранится в компоненте-вопроса.

Весь список вопросов менеджится внешним компонентом и внешний компонент решает какой вопрос показывать. Так же внешний компонент собирает и хранит ответы пользователей из @@Output компонентов-вопросов. И при переходе назад на предыдущий вопрос предаёт этот ответ в @@Input компонента-вопроса для того чтоб тот корректно отобразил предыдущий ответ пользователя.

Еще ангуляр не предоставляет никаких средств для менеджмента состояния и попытки запихнуть состояние системы в переменную сервиса (это первое к чему приходят почти все разработчики на ангуляре) обычно заканчивается непредсказуемым поведением системы по мере её разрастания и невозможностью переиспользовать компоненты. Вообще это полезное правило для любого ООП фреймворка, а не только для ангуляра: не допускайте появление состояний в сервисах, если хотите когда-то их переиспользовать. Хорошая новость: можно научиться писать так чтоб состояния в сервисах не появлялись никогда и не под каким предлогом. Это будет достойный код.

Если вернуться в к Ангуляру, с его полной неспособностью менеджить состояния из коробки, то советую взглянуть на https://github.com/ngrx/platform. Это редакс для ангуляра. На данный момент юзаю его на нескольких проектах, полёт нормальный. Не серебряная пуля, конечно, но многократно лучше чем то ничего, которое предлагает ангуляр из коробки. Если не знакомы с редаксом, то придется поуродствовать сначала. Но это окупается. Ну и не понимать редакс - как-то не комильфо для соврменного продвинутого программиста.

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond expr "%{tolower:%{REQUEST_URI}} =~ /(.*)/"
RewriteRule [A-Z] %1 [R=301,L]

Хозяйке на заметку: заглавные буквы в именах файлов считается дурной практикой в мире веб разработки, потому что почти всегда сайт будет работать на линукс сервере, файловая система которого чувствительна к регистру. Т.е. /ABC.js и /abc.js будут восприниматься линуксом как разные файлы. Строчные буквы, в свою очередь, стали стандартом в адресах ресурсов и очень высока вероятность того что на каком-то из этапов ввода или обработки адреса, регистр будет потерян, как, например, в вашем случае.

Поэтому вместо того чтоб решать проблему путём модификации .htaccess, правильнее будет привести все имена файлов в файловой системе к малому регистру. Тогда любые запросы будут приводиться к малому регистру и файлы будут гарантированно доступны. Такое решение применяется один раз является стопроцентным, в отличие от решения по поддержанию имён файлов в разных регистрах, за которое придется платить не один раз.

Да, возможно.

1. Создаёте компонент angular.module('Monorythm').component('monorythm', {})
Вот документация по компонентам https://docs.angularjs.org/guide/component

2. На html странице указываете место, где будет рендериться компонент

3. Затем бутстрепите прилажение angular.bootstrap(document.body, ['Monorythm']);

Вуаля.

Набрасал для вас пример
https://jsfiddle.net/sneas/gtrwzsn1/525/

а вот этот нашел в интернете при помощи поисковой системы Гугл
https://jsfiddle.net/langdonx/gtrwzsn1/