Не хочется кидать камни — но ведь автор явно в начале статьи описывал причину его отказа от `max-height`, или я не прав?..
Конечно, в 90% случаев, думаю, обычного `max-height: 5000px` вполне хватит. Но когда Вы разрабатываете переиспользуемые компоненты с четко описаными требованиями и динамическим контентом — не факт, что Вы не будете в числе 10%.
Если есть интерес — могу предложить для примера заглянуть в статью, которую я переводил пару месяцев назад — habrahabr.ru/company/infopulse/blog/338910… Этот пример конечно больше является руководством, которое старается объяснить принцип работы, но оно может также показать, как реактивное программирование может работать при связанных задачах…
Если говорить к примеру про ангуляр и его связку с rxjs — думаю можно было бы привести к примеру какуе-то задачу по типу таблиц с разнообразным фильтрами для пользователя и реакцией отображения на какие либо действия, асинхронные данные и тд…
Нет. Он не хранит в себе «все» данные всех потоков, а лишь «накопленный» результат… К примеру если функция вызывающаяся оператором scan() делает «X + 1» и первым значением туда прийдёт «1», то scan() будет хранить в себе «2». Что бы посмотреть что же в итоге там лежит можно просто вставить console.log(previous) в nextDirection…
Тоесть он не хранит массив всех поступиших в неё данных… Хотя это конечно зависит от реализации :)
А что именно Вас смущает? Фактически оператор работает как reduce для массива (в статье об этом упоминалось)… И момент когда в оператор будет приходить новое значение — он будет хранить в себе лишь последнее значение (к примеру если говорить о потоке direction$ он будет хранить последнее изменение направления)… Таким образом если на 14:59 нажать влево, то scan() в себе будет хранить { x: -1, y: 0 }…
Судя по описанию шагов, думаю поток direction$ отправил именно последнее событие после тика (движение влево) и поскольку Вы двигались перед этим вправо — сработала проверка коллизий и она вернула true (голова решила вернуться и врезалась в тело)…
Идея этой статьи, и соответственно сама реализация Змейки, преследует лишь цель «объяснить доходчиво на простом примере» принцип подхода реативного программирования…
Есть вопрос возможно банальный и неуместный, но всё же… Бывали ли у Вас случаи и если да — решалось ли как-то, что кто-то из команды разработчиков желает работать на другом проекте в компании, но это может навредить команде?
И исходя из «Лид-разработчик начал назначать задачи по специализации.» — Вы не боялись, что это может привести к ситуации с незаменимыми игроками? Когда потеря любого сотрудника может очень сильно подкосить…
Мои навыки в javascript немного хромают и я только начал заниматься Vue.
При всём моём уважении, не подумайте, что хотел обидеть, но — так может стоит не с Vue начинать, а закрепить знания самого языка? Я не хочу писать много слов, мне кажется даже статья когда-то проскакивала, что сейчас люди учат фреймворки, а не пытаются понимать их…
Ведь если Вы будете понимать принципы «ссылочных» объектов, замыканий и жизненного цикла события в доме — всё будет куда проще… Там и поймёте почему стали использовать redux или упомянутый в комментариях vuex…
Можете заглянуть по этой ссылке — github.com/angular/angular/commit/37797e2.
Кратко — избавляет Вас от необходимости использовать сервисы обёртки, которые разработчики пишут каждый по своему…
Из часто используемого — благодаря релизу теперь у Вас есть тип ответа JSON по умолчанию, и возможность обработки запросов (добавление хедеров, обратка ошибок и тд) более структурированно…
Заранее прошу прощения, если заметки будут не к теме самой архитектуры, но может Вам будет интересны мысли (исходя из фразы «Поэтому любую критику относительно кода и логики, приму как дружеский совет.»).
Думаю здесь (и в других подобных кусочках Вашего кода) стоит использовать новый сахар касающийся свойств с идентичными значениями — ({ username, password}). Значение хоста «localhost:8080» вынести в отдельную константу, если она Вам вообще нужна. Перед map сделать манипуляции .filter(res => res.status === 200).map(res => res.json()).map(data => ...).
Вещи связанные с получением самого токена и проверкой на то, является ли пользователь авторизованным…
sessionStorage.getItem('accessToken')
… стоило бы вынести в Ваш AuthService как отдельные методы isAuthorised и getAccessToken… Это позволяет не привязываться к месту хранения (вдруг Вы заходите переехать на ngrx?..)
Постарайтесь избегать использование сравнений с приведением типов…
if (token != null && refToken != null)
… это не есть хорошей практикой и часто приводит к ошибкам… В данной ситуации у Вас токены undefinedЫ.
Ещё хочу сказать, что возможно Вам стоит взглянуть на практику связанную с созданием класса-обёртки над ангуляровским http. В нём Вы можете единоразово настроить обратку ошибку, парсинг ответа и ту же работу с добавлением хедеров в Ваши запросы (кое что будет неактуально с новыми релизами фреймворка)…
Я задам возможно неправильный вопрос — но если Вы принимаете ко вниманию ситуации, когда Вам необходимо создавать даты с вероятно невалидными данными, возможно стоит все-таки изначально делать соответствующие проверки? Мне кажется это будет более правильная логика чем работать далее с Invalid Date…
Вы всегда можете помочь читателям Хабра и опубликовать эти более полезные статьи. Либо же оставить ссылки на оригиналы для заинтересовавшихся людей.
Автору же в любом случае спасибо за потраченное время и приложенный труд.
Я считаю, что еще стоит добавить в этот обзор библиотеку http://leafletjs.com… Функционал очень большой и библиотека очень качественная. Недавно был новый релиз… Возможность работы с разными провайдерами карт, интерактив, есть уйма плагинов, в том числе для работы с популярными фреймворками типа angular…
Конечно, в 90% случаев, думаю, обычного `max-height: 5000px` вполне хватит. Но когда Вы разрабатываете переиспользуемые компоненты с четко описаными требованиями и динамическим контентом — не факт, что Вы не будете в числе 10%.
Если говорить к примеру про ангуляр и его связку с rxjs — думаю можно было бы привести к примеру какуе-то задачу по типу таблиц с разнообразным фильтрами для пользователя и реакцией отображения на какие либо действия, асинхронные данные и тд…
Тоесть он не хранит массив всех поступиших в неё данных… Хотя это конечно зависит от реализации :)
И исходя из «Лид-разработчик начал назначать задачи по специализации.» — Вы не боялись, что это может привести к ситуации с незаменимыми игроками? Когда потеря любого сотрудника может очень сильно подкосить…
При всём моём уважении, не подумайте, что хотел обидеть, но — так может стоит не с Vue начинать, а закрепить знания самого языка? Я не хочу писать много слов, мне кажется даже статья когда-то проскакивала, что сейчас люди учат фреймворки, а не пытаются понимать их…
Ведь если Вы будете понимать принципы «ссылочных» объектов, замыканий и жизненного цикла события в доме — всё будет куда проще… Там и поймёте почему стали использовать redux или упомянутый в комментариях vuex…
Кратко — избавляет Вас от необходимости использовать сервисы обёртки, которые разработчики пишут каждый по своему…
Из часто используемого — благодаря релизу теперь у Вас есть тип ответа JSON по умолчанию, и возможность обработки запросов (добавление хедеров, обратка ошибок и тд) более структурированно…
Думаю здесь (и в других подобных кусочках Вашего кода) стоит использовать новый сахар касающийся свойств с идентичными значениями — ({ username, password}). Значение хоста «localhost:8080» вынести в отдельную константу, если она Вам вообще нужна. Перед map сделать манипуляции .filter(res => res.status === 200).map(res => res.json()).map(data => ...).
Вещи связанные с получением самого токена и проверкой на то, является ли пользователь авторизованным…
… стоило бы вынести в Ваш AuthService как отдельные методы isAuthorised и getAccessToken… Это позволяет не привязываться к месту хранения (вдруг Вы заходите переехать на ngrx?..)
Постарайтесь избегать использование сравнений с приведением типов…
… это не есть хорошей практикой и часто приводит к ошибкам… В данной ситуации у Вас токены undefinedЫ.
Ещё хочу сказать, что возможно Вам стоит взглянуть на практику связанную с созданием класса-обёртки над ангуляровским http. В нём Вы можете единоразово настроить обратку ошибку, парсинг ответа и ту же работу с добавлением хедеров в Ваши запросы (кое что будет неактуально с новыми релизами фреймворка)…
Автору же в любом случае спасибо за потраченное время и приложенный труд.