Aleksei Podgaev

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

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

https://docs.angularjs.org/guide/unit-testing

Я думаю, что "синтетических" проектов чисто для "портфолио" делать не стоит.

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

Если приложение не использует никаких возможностей мобильной платформы, то никаких проблем использовать один и тот же код нет - адаптивная разметка (можно тот же bootstrap и angular совместить) и cordova в помощь. Можно также посмотреть в сторону недавно появившихся WPA - там даже компилировать под платформу и выкладывать в маркет не нужно.

Если же функционал на мобильной платформе будет немного отличаться от веб версии, то всё равно, используя cordova с плагинами и разделение кода на репозитории git, можно добиться практически полного переиспользования кода, хотя и усилий придётся затратить больше.

Ionic, построенный на базе cordova и angular, тоже неплохое решение для гибридных приложений.

На свете не существует библиотеки компонентов, даже платной, которая бы удовлетворяла всем потребностям всех разработчиков. Всегда приходится допиливать. Если вы хотите создать крупный проект не написав ни строчки кода и не потратив ни рубля - вы не по адресу.

По моему опыту, чем проще изначальная библиотека, тем легче её модифицировать/допиливать до необходимого функционала. Поэтому я бы предложил связку Angular+Bootstrap. Для хитрых UI компонентов также хорошо подходит React, но к нему нужен ещё зоопарк библиотек для управления состоянием, кэширования AJAX запросов и всего остального.

Вас не смущает два вызова this.router.navigate(['/login']); в двух местах?

Зачем вы делаете перехват ошибок в сервисе авторизации? Если роутер сам за этим должен следить - пусть он и следит. Там и ставьте перехват и обработку ошибок, а из сервиса уберите.

1. Как правильно заметили в предыдущем ответе - конструктор не должен быть асинхронным. Вынесите инициализацию в отдельный метод.

2. Почему нельзя подписывать до установления соединения? Кто это сказал? Я не знаю, насчёт используемого вами клиента, но можно же свой Subject (из RxJs) объявить, на него подписаться, а он уже будет прокидывать события из сокета, когда соединение установится. Т.е. на события сокета подписывается только сервис, который его создал, после того, как соединение будет установлено. Все остальные подписываются на события этого сервиса. Сервис пробрасывает все события, которые приходят от сокета, своим подписчикам.

Ну, во-первых, а почему, собственно, хранить всё в store - не вариант? Где-то это хранить всё равно придётся. Я бы хранил в store.

Но если всё же хочется посложнее, то можно сделать под это событие свой Subject (из rx.js). Те компоненты, которым нужно знать об этом событии подписываются на этот Subject, а сервис, которые получает данные вызывает Subject.next с данными о лайке. Отличие Subject от Observable в том, что у Subject может быть сколько угодно подписчиков и все они узнают о событии. Похоже, именно это вам нужно? Единственное, что меня тут смущает - не будет ли такое решение ещё более ресурсоёмким, чем хранение всех данных в store.

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

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

Смотря какие проекты вам интереснее делать. Angular в последнее время склоняется в Enterprise, т.е. на нём вы будете делать тяжёлые админки со всякими графиками/диаграммами, сложными задачами типа ленивой загрузки и кэширования таблиц с данными и всё такое прочее. На React делают больше решения ориентированные на массового пользователя, с обилием всяких визуальных плюшек, анимации и т.п. В общем если привлекает возиться с CSS и анимацией - лучше браться за реакт. На нём, кстати, и игры, как мне кажется, легче писать.

Очень грамотную статью по лучшим практикам в первом ангуляре от John Papa предложил первый комментатор adamsafr . Полностью согласен и рекомендую к прочтению. В остальном же для быстрой адаптации в новом коллективе самое главное - не закукливаться в себя и как можно больше спрашивать у опытных коллег. Они все пониимают, что вы новичок, и всегда постараются объяснить решения принятые в процессе разработки. Лучше спросить один или два раза сейчас, чем тупить и ошибаться всё оставшееся (недолгое в этом случае) время на новом месте.

С точки зрения "лучших практик" это, конечно, плохая идея, т.к. такое решение плохо тестируется и подвержено багам. Допустим, ты решил поменять что-то в сервисе. Тогда очень велика вероятность, что всё приложение у тебя посыпется, если ты эту переменную используешь, скажем, не только в этом компоненте, но и ещё в нескольких.

Лучшим решением будет безусловно предоставление сервисом интерфейса. В описанном варианте, наверное getUsers(), который будет возвращать, готовый массив, Promise или Observable, в зависимости от необходимости. А внутренню кухню и, в частности, переменные, лучше скрывать от пользователей.

Скажу честно, в серьёзных проектах я эту связку пока не использовал. В одном из приложений архитектура после энной итерации стала очень близка к redux шаблону, так что, полагаю, связка такая вполне уместна, если есть достаточно сложная иерархия состояний. Преимущество redux в чётком понимании текущего состояния приложения - в любой момент времени ясно, какие данные есть в приложении, какие ещё не загружены, где и на каком этапе произошла ошибка. В общем, единое и неизменяемое хранилище состояния - это довольно мощная вещь сама по себе, безотносительно angular используется или react или ещё что.

Вот так не работает?
<input [attr.formControl]="control" #input>

https://angular.io/docs/ts/latest/guide/cheatsheet.html

Можно сделать по-разному. Главное с самого начала решить, кто будет вносить изменения в данные. Я бы рекомендовал, чтобы изменения вносились только в одном месте (например в указанном в примере контроллере). Если у вас данные будут менять все кому не лень - другие сервисы, директивы, другие вложенные контроллеры, то вы очень скоро потеряете контроль над тем, что происходит у вас в приложении и откуда растут ноги у изменений. Подход с единственным ответственным за изменение данных сильно облегчает жизнь в приложениях со сложной архитектурой, хотя и требует иногда лишнего прокидывания обработчиков событий вверх по иерархии компонентов.

Если хотите Angular2, то берите Ionic. Как уже было сказано выше, для интернет-магазина библиотек подобных Ionic и ReactNative хватает с головой. При определённой прямоте рук и более сложные проекты делают. Я видел как-то презентацию видеостримингового портала сделанного на Angular и Ionic (мобильное приложение). Так что было бы желание.

Согласен с предыдущим автором. Разберитесь как работают промисы и асинхронный код вообще.
Ваша функция GetResponse действительно не ждёт, пока отработает запрос, а сразу возвращает значение "foo". Так что вы получаете именно то, что написали в своём коде. Если вы будете "приостанавливать" выполнение функции, то ваши пользователи проклянут вас за повисший браузер. Лучше сделать, чтобы alert вызывался только после выполнения запроса, т.е. в success.

Необходимо немного больше данных. Blog - это просто объект или Promise? Что такое Blog.Blog? Когда и как это свойство инициализируется?