bromzh

Нет, естественно надо указать только то, что будешь внедрять непосредственно в сам компонент. А можно даже не указывать ничего, если сервис ты регистрируешь глобально в функции bootstrap.

Вообще логика такая: все сервисы, которые внедряются, должны каким-то образом быть зарегистрированы. Те сервисы, которые ты зарегистрировал глобально в функции bootstrap будут доступны глобально во всех компонентах. Их необязательно описывать в поле providers. Если сервисы не регистрируются глобально, то нужно регистрировать в компоненте. Причём сервисы будут доступны и в дочерних компонентах.
Вообще, у каждого компонента свой инжектор зависимостей. Таким образом, для каждого компонента можно настроить провайдеры сервисов по-своему. Если сервис не зарегистрирован у компонента, то его ищут вверх по иерархии компонентов.

https://angular-ui.github.io/bootstrap/#/pagination

https://github.com/angular/universal-starter
В файле src/server.ts все ответы. Суть такая:
1) создаём express-приложение
let app = express();
2) настраиваем обработку .html-файлов на ангуляровский рендерер из universe

app.engine('.html', expressEngine);
app.set('views', __dirname);
app.set('view engine', 'html');

3) Создаём функцию-обработчик, которая будет рендерить ангуляр-приложение на сервере, если пользователь зайдёт по определённым ссылкам

function ngApp(req, res) {
  let baseUrl = '/';
  let url = req.originalUrl || '/';
  res.render('index', {
    directives: [ Html ],
    ...
  }
}

4) В этой функции каким-то образом надо подключить корневой компонент App. В приведённой ссылке это делается так: создаётся компонент Html (src/server-only-app/html.component.ts), который содержит полностью весь код index.html (кроме тегов html). Можно было просто в функцию ngApp указать в поле directives корневой компонент.
5) Запускаем приложуху

app.use(express.static(root, {index: false}));

// Routes with html5pushstate
app.use('/', ngApp);
app.use('/about', ngApp);
app.use('/home', ngApp);

// Server
app.listen(3000, () => {
  console.log('Listen on http://localhost:3000');
});

1) Что за фронтенд-сервер? Типа только статика?
2) Статику надо отдавать через nginx штатными средствами
3) Сервер фласка нужен только для разработки. Запускать его в прод очень плохо. Flask-приложение реализует стандарт wsgi, так что его можно запустить на любом wsgi-сервере (рекомендую uwsgi). Причём желательно не выставлять его наружу, а поставить "позади" nginx, т.е. надо проксировать с nginx на uwsgi.

Можно настроить вебпак соответствующим образом.
См. в этом репозитории на файл spec.bundle.js. В настройках кармы подключается только этот файл. В самом же файле:
1) Создаётся функция-контекст. require.context составляет список файлов в соответствии с параметрами (1-й - корневая директория, где будут искаться файлы, 2-й - рекурсивно или нет искать файлы и 3-й - регулярка-фильтр)
2) У полученной функции-переменной (context) есть метод keys, который возвращает список всех найденных файлов (их имена).
3) Для каждого найденного файла вызывается рекурсивно функция context, таким образом, все импорты в тестах разрешаются правильно.

В итоге, ты можешь либо фильтровать вручную по ключам, либо передать в функцию require.context такие параметры, чтобы находился только 1 файл. А в самом файле подключать нужные спеки.

ui-grid.info
lorenzofox3.github.io/smart-table-website
ng-table.com

Я пользовался первой, но идеальной нет, везде свои недостатки. Если все данные приходят с сервера, и пагинация, сортировка и фильтрация тоже серверные, то легче тупо вручную делать.

Да, ты не понимаешь асинхронность в JS и MVC.
Нужно рендерить после получения данных. Например, можно вызывать функцию render в колбеке getJSON. Ещё лучше вернуть промис и вызывать рендрер в колбеке then.
Но это всё равно ни разу не MVC.

А не могли бы вы помочь, как это делать в парадигме MVC?

Ну тут всё не так просто. Если ты хочешь использовать MVC-фреймворки, то смотри, как там всё организовано у них. Примеры реализации простого MVC приложения см. тут.

Если же забыть про тонны готовых MVC, то можно сделать всё самому. Тут важно понимать, что:
1) Модель - это вся бизнес-логика. И она не знает ни про View, ни про Controller. В классическом MVC модель оповещает всех подписчиков об изменении своих данных.
2) Вид (view) должен знать про модель, но не про контроллер. В классическом MVC вид подписывается на события модели и при возникновении события он перерисовывается.
3) Контроллер знает про вид и про модель. В классическом MVC он связывается с каким-то видом и при определённом действии пользователя что-то делает. Например, он может вызывать какие-то методы у модели. А может и изменять состояния вида (хотя так лучше не делать в идеале, так как повысится связность системы, что плохо).

Итак, вот тебе пример. Немного корявый, но суть должна быть ясна.

Сперва посмотри в script.js.

Там есть класс-модель. Чтобы связать Model и View обычно применяют паттерн проектирования observer. У модели есть список слушателей. Каждый слушатель - просто функция-коллбек, которая принимает 1 аргумент - данные этой модели. При этом, сама модель не знает вообще ни про какой View. Слушатели в модели - это просто массив функций, которые будут вызваны.
В модели есть метод для добавления слушателя и для оповещения всех слушателей о получении новых данных. Метод getData эмулирует асинхронный запрос данных. В этом методе создаётся промис. Если данные найдены, то вызывается метод оповещения всех слушателей и промис резолвится. Если данные не найдены, то промис реджектится.

Далее, небольшая иерархия view-классов.
Класс BaseView. Там есть конструктор, который связывает экземпляр класса с DOM-элементом; метод subscribe, который добавляет к модели простого слушателя. Слушатель вызывает метод render с данными, которые нужно отрендерить и записывает полученный из метода render HTML в элемент. В самом классе BaseView метод render выплюнет ошибку, так что нужно написать несколько классов-наследников.
Класс ListView наследуется от BaseView и просто добавляет вспомогательный метод, который просто обрамляет каждый объект из массива с данными в элемент .
Ну и наконец, есть 2 класса, которые непосредственно реализуют метод render.
В итоге, класс UlView генерирует из массива данных ненумерованный список, а класс OlView - нумерованный.

Теперь в самом index.html можно увидеть всё в деле. Создаём модель и 2 view. Каждый view инициализируем соответствующим div-элементом. Далее,
При нажатии на кнопку вызывается коллбек, который вызывает метод модели. Если модель смогла получить данные, то подписанные на эту модель вьюхи рендерят эти данные, причём каждый view делает это по-разному. Как тут можно заметить, модель вообще никак не зависит от view. Можно связывать сколько угодно вьюх без какого-либо изменения самой модели.

В общем, как-то так. Это конечно очень простой и довольно корявый пример (например, тут нет возможности связать контроллер и сам view, это уж сам изучи), так что не следует этот код использовать где-то в своих проектах.
Ну и почитай ещё про MVC, посмотри реализацию TodoMVC на разных фреймворках.

Самое простое - подключить moment.js, потому что стандартные средства для работы с датами фиговые.
Или использовать что-то типа этого.