Да, я помню тоже искал помещение для своего отдела (на 40 человек). Нашел очень хорошую площадь по стоимости и расположению, но оно представляло собой одну очень большую комнату. Делать перекрытия хозяин помещения отказался напрочь, переговоры ни к чему не привели. Когда пытались сами рассмотреть варианты с установкой перегородок (в том числе, с не самыми дорогими съемными пластиковыми), нам насчитали столько, что в головном офисе просто покрутили пальцем у виска и сказали искать помещение дальше, сразу со всем необходимым.
Да, конечно, для небольших скриптов, типа *.sh, это подходит. Но я имел в виду разработку более серьезных приложений. Поэтому, раз уж заикнулся о преимуществах статической типизации, то вкратце их перечислю:
вы всегда уверены что написанный метод и результаты его работы используется вами правильно;
ошибки класса «сравниваем несравниваемое» или «пихаем невпихуемое» исключаются на стадии компиляции;
после перехода на ST (например, при переходе с JS на TS) вы с большой вероятностью обнаружите, что таких ошибок у вас дофига; и даже не ошибок, а скорее досадных опечаток, которых ваш замылившийся глаз в упор не замечает;
нет необходимости заниматься лишними проверками типов самостоятельно; вообще, переход на ST — это довольно дешевый способ повысить качество кода, особенно когда кодовая база растет быстро за счет большой команды;
ваш IDE станет намного дружелюбнее по отношению к вам; а если вы все еще пишете в блокноте, то это дополнительный стимул перейти на IDE;
рефакторинг перестает быть нудным и кропотливым занятием, после которого частенько появляются новые баги; поправив какой-нибудь метод вы не пропустите какое-нибудь место, где он вызывается в дебрях вашего проекта — компилятор услужливо вам напомнит;
В основном в коробке идёт красивая анимированная пальце-тыкательная хромая замена стандартным контролам браузера
Вы наверное про Angular Material 2? Но она не совсем в коробке, просто Google продвигает данную тему (Material Design) и поэтому рекомендует по-умолчанию. На самом деле UI систем много, часть из них перечислены тут angular.io/resources в разделе UI Components. Рекомендую приглядеться к Semantic UI, Clarity Design System и Prime NG.
Я лично чаще всего использую голый bootstrap.css без bootstrap.js/jQuery (4 версия наконец-то собирается из SCSS, что делает более простой сборку с помощью Angular CLI).
Похоже, вы просто не нашли времени познакомиться с TS и прочувствовать на себе преимущества статической типизацией. А если рассматривать сравнение с динамической типизацией, то выяснится, что у DT нет никаких преимуществ перед ST, кроме сомнительного «более низкий порог вхождения в ЯП».
1. Это действительно очень грустно, так как Angular запущенный в dev-режиме не устанет вам напоминать об этом в консоли, а самый простой способ от этого избавиться, используя Angular CLI, запустить с этим самым ключом. Ну и dev/prod-конфиги в папке environment должны наводить на какие-то мысли. Грустно, что разработчики использующие angular, не могут в документацию.
Я сам использую Angular с 2-rc.1 версии, когда никаким CLI еще не пахло, и уже тогда интересовался, как правильно производить prod-сборку. В официальной документации был и есть на это ответ, с полным описанием разницы между JIT и AOT.
2. По заверению разработчиков, не будет. Все, что скоро должно устареть, будет помечаться как deprecated и выводиться соответствующие оповещения об этом при сборке.
3. Я абсолютно не согласен с вами, что разработчики angular-а настолько плохие специалисты, что постоянно делают нам плохо. На мой взгляд, они создали наиболее удобный и универсальный фреймворк, благодаря которому fronted-разработка сильно упростилась и перестала походить на обмазывание BE-костяка скриптами и библиотеками. Да и вообще, большинство претензий как автора статьи, так и комментаторов мне абсолютно не понятны и попахивают вкусовщиной.
Ну и npm update не переведет ваш проект с 4 на 5 версию автоматически. Предполагается, что при смене мажорной версии, любой разработчик изучает changelog и советы по переходу на новую версию, а не делает это с закрытыми глазами на проде.
Про ошибки в шаблонах, которые не отображаются при JIT-компиляции. Насколько я читал, разработчики ангуляра к пятой версии хотят сделать быстрые инкрементальные сборки для AOT и выпилить JIT совсем.
Навскидку:
1. Использовать Transclusion
2. Использовать вторичные роуты (якоря на заголовки на странице глючат, поэтом если вас перекинет не туда, сделайте поиск по странице: «Displaying multiple routes in named outlets»).
DIR-300 на картинке, мой первый роутер, всплакнул. Кстати, до сих надежно исполняет свои обязанности дома у родителей. Слегка капризный, но при должной настройке работает как швейцарские часы (в смысле надежности, а не что только время показывает).
Да, при том, что Microsoft держится в сторонке от всей этой VR-движухи. В отличие от той же Sony с ее PS VR.
Хотя по слухам вроде бы обещают подружить XBOX и всякие окулусы/вайвы, но это не точно.
Там разные типы «эксклюзивов». Перед некоторыми играми идет фраза «Xbox One & Windows 10 Exclusive», а перед другими «Xbox One & Windows 10 Launch Exclusive», что значит, игра выйдет на других платформах через несколько дней/недель/месяцев.
Я там в конце сделал сноску, что в редких случаях все же допускаю их использование. Но только в тех случаях, когда реально без этого не обойтись, как правило для сессионных данных. Ну хотя бы тот же токен пользователя надо как-то хранить, а не заставлять его авторизовываться заново, если ему приспичит нажать F5.
Очевидно, своей простотой и поддержкой браузерами по-умолчанию. Плюс, грамотное использование localStorage решает вопрос, когда пользователь в вашем SPA-приложении пытается открыть ссылку в новой вкладке.
При создании SPA, те самые элементы, которые на серверных языках я бы реализовывал через хранение данных в сессии (тот же профиль пользователя), приходится использовать storage-ы и модели, которые получают данные из них.
Т.е., поставленную вами задачу я бы решал следующим образом: создал отдельный компонент Layout, который будет показываться по-умолчанию на страницах и содержит компонент c шапкой, в котором отображаются данные авторизованного пользователя, которые берутся из сессии (т. е. из storage-а). Обновлять данные в шапке можно по ngDoCheck, а чтобы это никак не сказалось на производительности, в механизм нашей сессионной модели несложно добавить проверку на последнее изменение по Timestamp-у.
Конкретно всё это безобразие можно реализовать и другими способами (от предложенного общего сервиса, до синглтона-хранилища-состояний). Но у использования того же localStorage в данном конкретном примере очевидны свои плюсы.
Но это, опять же, если я правильно понял ваш пример. Часто годятся и «оутпуты до корня». Пример: личный кабинет пользователя — корневой компонент. При создании загружает актуальные данные о пользователе и хранит их в себе. Имеет два дочерних компонента: Presentational — лэйаут (использую в нем transclusion посредством ng-content) отрисовывающий шапку, футер, и место, куда будет помещен второй дочерний компонент с формой редактирования данных пользователя. По сути, в данной схеме будет использован всего один output — от компонента с формой редактирования до корневого личного кабинета. Который после получения новых данных о пользователе тут же отобразит их в лэйауте (в шапке, без всяких ngDoCheck). И в такой схеме я вообще не вижу необходимость какого-то глобального стейта.
Вот у вас есть несколько несвязанных компонент, каждая из которых подтягивает копию некоторого стейта с бекенда
Исходя из моих принципов, у меня в любой момент времени нет нескольких несвязанных компонентов, общающихся с бэком. Всегда есть только один корневой (грубо говоря, текущая страница) привязанный к текущему роуту. Если роут меняется (не путать с изменением параметра роута), то этот компонент уничтожается, и создается новый компонент согласно новому роуту. И уже он грузит свой актуальный стейт с бэка.
Не использую общий глобальный стейт и придерживаюсь обычно следующих принципов:
деление компонентов по типу Presentational и Container Components (https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0)
каждый «корневой» компонент (как правило, привязанный к опредленному роуту) получает свое актуальное состояние с бэка при инициализации или изменении параметров роута
корневые компоненты между собой не общаются, только через бэк
корневой компонент как правило является Container Component-ом и для отрисовки передает/получает свойства своего состояния через цепочки input/output дочерним Presentational Component-ам (или, если куски большие, разбивать на несколько дочерних Container Component-ов
Как правило, если все сделать грамотно, деревья не получаются слишом многоуровневыми и никаких проблем при передачи состояния вглубь и получения изменений через output-ы лично у меня не возникает.
Эти принципы подробно описаны в официальной документации Angular-а и, как мне показалось, являются тем самым angular way.
В редких случаях, допускаю хранение некоторых глобальных флагов и пр. в storage-ах.
Вы наверное про Angular Material 2? Но она не совсем в коробке, просто Google продвигает данную тему (Material Design) и поэтому рекомендует по-умолчанию. На самом деле UI систем много, часть из них перечислены тут angular.io/resources в разделе UI Components. Рекомендую приглядеться к Semantic UI, Clarity Design System и Prime NG.
Я лично чаще всего использую голый bootstrap.css без bootstrap.js/jQuery (4 версия наконец-то собирается из SCSS, что делает более простой сборку с помощью Angular CLI).
Я сам использую Angular с 2-rc.1 версии, когда никаким CLI еще не пахло, и уже тогда интересовался, как правильно производить prod-сборку. В официальной документации был и есть на это ответ, с полным описанием разницы между JIT и AOT.
2. По заверению разработчиков, не будет. Все, что скоро должно устареть, будет помечаться как deprecated и выводиться соответствующие оповещения об этом при сборке.
3. Я абсолютно не согласен с вами, что разработчики angular-а настолько плохие специалисты, что постоянно делают нам плохо. На мой взгляд, они создали наиболее удобный и универсальный фреймворк, благодаря которому fronted-разработка сильно упростилась и перестала походить на обмазывание BE-костяка скриптами и библиотеками. Да и вообще, большинство претензий как автора статьи, так и комментаторов мне абсолютно не понятны и попахивают вкусовщиной.
Ну и npm update не переведет ваш проект с 4 на 5 версию автоматически. Предполагается, что при смене мажорной версии, любой разработчик изучает changelog и советы по переходу на новую версию, а не делает это с закрытыми глазами на проде.
1. Использовать Transclusion
2. Использовать вторичные роуты (якоря на заголовки на странице глючат, поэтом если вас перекинет не туда, сделайте поиск по странице: «Displaying multiple routes in named outlets»).
Хотя по слухам вроде бы обещают подружить XBOX и всякие окулусы/вайвы, но это не точно.
Т.е., поставленную вами задачу я бы решал следующим образом: создал отдельный компонент Layout, который будет показываться по-умолчанию на страницах и содержит компонент c шапкой, в котором отображаются данные авторизованного пользователя, которые берутся из сессии (т. е. из storage-а). Обновлять данные в шапке можно по ngDoCheck, а чтобы это никак не сказалось на производительности, в механизм нашей сессионной модели несложно добавить проверку на последнее изменение по Timestamp-у.
Конкретно всё это безобразие можно реализовать и другими способами (от предложенного общего сервиса, до синглтона-хранилища-состояний). Но у использования того же localStorage в данном конкретном примере очевидны свои плюсы.
Но это, опять же, если я правильно понял ваш пример. Часто годятся и «оутпуты до корня». Пример: личный кабинет пользователя — корневой компонент. При создании загружает актуальные данные о пользователе и хранит их в себе. Имеет два дочерних компонента: Presentational — лэйаут (использую в нем transclusion посредством ng-content) отрисовывающий шапку, футер, и место, куда будет помещен второй дочерний компонент с формой редактирования данных пользователя. По сути, в данной схеме будет использован всего один output — от компонента с формой редактирования до корневого личного кабинета. Который после получения новых данных о пользователе тут же отобразит их в лэйауте (в шапке, без всяких ngDoCheck). И в такой схеме я вообще не вижу необходимость какого-то глобального стейта.
Исходя из моих принципов, у меня в любой момент времени нет нескольких несвязанных компонентов, общающихся с бэком. Всегда есть только один корневой (грубо говоря, текущая страница) привязанный к текущему роуту. Если роут меняется (не путать с изменением параметра роута), то этот компонент уничтожается, и создается новый компонент согласно новому роуту. И уже он грузит свой актуальный стейт с бэка.
Как правило, если все сделать грамотно, деревья не получаются слишом многоуровневыми и никаких проблем при передачи состояния вглубь и получения изменений через output-ы лично у меня не возникает.
Эти принципы подробно описаны в официальной документации Angular-а и, как мне показалось, являются тем самым angular way.
В редких случаях, допускаю хранение некоторых глобальных флагов и пр. в storage-ах.
В данный момент: Проголосовало 152 человека. Воздержалось 150 человек. Полагаю, эти 50% пользователи как раз таки «не используют» redux.