Dolerum

NgModuleRef это объект представляющий модуль (экземпляр NgModule), как написано в документации:

NgModuleRef - represents an instance of an NgModule created by an NgModuleFactory. Provides access to the NgModule instance and related objects.

В примере от Степана Суворова мы берем NgModuleRef для AppModule, главного модуля приложения, сохраняем привязанный к нему ресолвер фабрик компонентов, получаем с его помощью фабрику компонентов, а уже с помощью этой фабрики создаем компоненты

const newStr = str
  .split(' ')
  .map(function([...word]) {
    const sorted = word.filter(this).sort((a, b) => b.localeCompare(a));
    return word.map(n => this(n) ? sorted.pop() : n).join('');
  }, RegExp.prototype.test.bind(/[a-z]/i))
  .join(' ');

Как есть, так и типизируй.

Как минимум:

state.books.filter((book: { id: string }) => book.id !== id)

А лучше:

interface Book {
  id: string;
  // ...
}
state.books.filter((book: Book) => book.id !== id)

А ещё лучше:

interface Book {
  id: string;
  // ...
}
interface State {
  books: Book[];
  // ...
}
const state: State = ...

state.books.filter(book => book.id !== id)

[...credits.cast, ...credits.crew].map((person) => person.name)

Добрый день.

Отвечая на ваш вопрос - "Почему в проектах для react частенько используется ts-loader, а не babel-loader?" - они взаимозаменяемы, т.к. оба являются транспайлерами, отличаются только входные данные.

Отвечая на - "Не проще ли, чтобы все вместе разбирал babel?" - нет, не проще, бабель не производит проверку типов и все равно потребуется установка tsc и, соответственно, настройку вебпака для использования tsc для проверки типов перед сборкой кода через бабель. Несмотря на некоторые соприкасающиеся фичи, typescript является скорее другим языком программирования, тогда как babel берет за основу современные версии ecmascripta. Иными словами, js до компиляции бабелем можно запускать в современных или будущих браузерах, тогда как typescript никогда нельзя будет запускать напрямую в js среде без компиляции. И отсюда возникает вопрос, зачем использовать babel для компиляции синтаксиса typescript'a в js без проверки типов и иных фич tsc, когда у typescript'а есть свой транспайлер? На этот вопрос я предлагаю ответить вам.

Вот ссылка на реализованные фичи в разных средах.

Сетка нужна, в первую очередь, дизайнеру. Чтобы выстроить элементы дизайна ровненько, по феншую, на всех страницах одинаково — блоки на скачут в положениях и размерах.

Верстальщик, в свою очередь, видит, что дизайн выстроен по сетке, и решает упростить себе задачу верстки. Он пишет базовые классы для разметки на странице колонок и размещает блоки в них. Отсюда отпадает необходимость сидеть с линейкой и выравнивать блоки по дизайну.

Всё остальное — следствие. Верстальщику становится мало просто классов для описания раскладки макета. Он решает приправить их медиа-запросами, чтобы и базовая адаптивность страницы была что называется "из-коробки". Опять же для упрощения и ускорения своего труда. Потом решает еще что-то добавить, к примеру смещение колонок и т.п.

Так появились типовые сетки, типа бутстрапа. Так как они предназначены для универсального использования, в них сделали возможности для настройки основных параметров — количества колонок, промежутков между ними, ширин контейнеров и т.д.

Потом появились дизайнеры, которые стали рисовать свои макеты "под бутстрап" =) Ничего плохого, это ускоряет (а значит удешевляет) разработку конечного продукта. Но нужно понимать, что дизайн первичен. А сетку можно любую сделать.

.top-slide {
padding-top: 120px;
background-image: url("..img/slider.jpg");
}

а картинки лежат в папке img? а сама папка img лежит на одном уровне с index.html? Если да, то удалите лишнюю точку и допишите знак "/" вначале пути background-image: url("./img/slider.jpg"); или удалите точки перед img: background-image: url("img/slider.jpg");