Мне нравятся задания в стиле "Отрефакторите представленный код".
В нем ты показываешь что надо поменять, а главное - обосновываешь почему так надо сделать. При этом, зачастую именно в объяснении "почему", мы приходим к основам JS и пониманию языка на низком уровне.
Так же видны знания и понимание необходимого для работы стека технологий, что на мой взгляд важнее "задрачивания" задачек с литкода.
Особенно мне нравятся секция алгоритмов при собесах на позицию фронта.
Да да, мне обязательно на фронте пригодится уменее написать свою сортировку, которая будет работать быстрее всроенного Array.sort(). И разумеется, мне крайне необходимо уметь на лету оценивать сложность каждого написанного метода по Big O.
На фронте вообще не должно быть потребности в больших вычислениях, все расчеты ведуться на бэке и отдаются на фронт порционно. Мы же хотим, что бы наши прилажки работали у всех клиентов, включая бедняг с Intel Atom и 2Gb DDR или смартом с 1Gb памяти на борту. Какой бы классный я ни написал алгоритм, он всеравно упрется в вычислительные мощности клиента на каком-то объеме данных.
Лучше бы на собесах отдавали больше времени на знание / умение пользоваться определенным набором фрэймворков / библиотек.
Нет возможности обмена файлами — только JSON (если без всяких костылей)
Сложность обработки ошибок. Спецификация подразумевает то, что все запросы, которые могут быть обработаны сервером — возвращаются с статус-кодом 200. Как типичный пример — когда мы не совершив авторизацию обращаемся за данными. Вместо привычного ответа 401, мы получаем 200 с длинным описанием в json. Да, в тело ответа можно прокинуть статускод, но все-равно это добавляет лишних проблем. В примере с авторизацией, когда у нас JWT AccessToken+RefreshToken в интерсепторах не получиться использовать error handling, тк все ошибки у нас будут со статусом 200, а придется в каждом запросе лезть в его тело и искать статускод.
Async pipe - отличная вещь, но только в простых компонентах (с простым шаблоном и без бизнес-логики).
Когда появляется много структурных детектив - использовать пайп становится весьма затруднительно. Особенно учитывая то, что забаиндить значение стрима в шаблонную переменную возможно только через использование структурной детективы ngIf или ngFor.
А в статье не рассмотрен гораздо более правильный способ отписки внутри компонента, по сравнению с переменными для подписок.
А именно заведение одной переменной типа Subject и использование возможностей RxJS - takeUntil.
private unsubscrib$e: Subject<void> = new Subject<void>();
Считаю верными 1, 3 и 4 способ
1 — когда есть единственная подписка
3 — async pipe весьма спецефичен. Довольно редко получается его использовать в проде, так как логика внутри компонента в большинстве случаев завязана на получаемые значения из подписки. Но если в компоненте подписка влияет только на шаблон, то это идеальный вариант
4 — самый универсальный способ, постоянно его тспользую и уже на автомате добавляю в компоненты свойства private unsubscribe$: Subject = new Subject(); и имплементируюсь от OnDestroy
2 способ жизнеспособен, но takeUntil мне как-то ближе
5 и 6 — тянуть дополнительные библиотеки ради отписок? Серьезно?
Уважаемый автор, искренне не понимаю вашу ненависть в Angular 2+ )
Да, это не чистая CA, но это один из немногих фрэймворков, который диктует свою архитектуру из коробки, а не порождает зоопарки, извините, говнокода.
Вы написали замечательную статью, но на практике ей вдохновятся единицы, а большая часть сообщество React/Vue так и продолжит порождать в каждом новом проекте новую архитектуру. Раздувать одну бибилиотеку кучей других, потому что из коробки функционала не хватает для большинства real-world проектов.
Как пример — из коробки в React нет TS. Половина будет юзать старый добрый JS, половина перейдет на TS. Дальше хуже — Redux, MobX, просто на хуках. Инструментов великое множество, и каждый такой инструмент зачастую приводит к разнице в архитектуре.
Из-за этого зоопарка, переход между проектами на React/Vue разных команд/компаний очень сложен, так как каждый выстраивает архитектуру как хочет / как умеет. Напротив, при переходе между разными проектами на Angular, вы не ощутите большой разницы и вряд ли встретите какие-либо сюрпризы.
По поводу Angular 1.x (AngularJS) вообще стоит забыть как о страшном сне, это была ошибка, но она привела к созданию Angular 2 =)
Если хотите производительности, то используйте D3. Тем самым вы избавитесь от лишних фич/наворотов крупных библиотек. К тому же, D3 подходит для коммерческих проектов, в отличии от всех остальных либ.
Для прореживания данных советую использовать алгоритм Вращающейся двери (SwingingDoor). Он сохраняет общую динамику графика. Но с параметрами тоже придется поиграться, что бы добиться наилучшего результата.
При локализации, мне кажется, текущий код языка пользователя (в мультиязычном приложении) должен отправляться на сервер с каждым запросом (куки/заголовок). Соответственно сервак должен отдавать уже локализированый ответ.
А плодить кучу запросов, мне кажется совсем не верным решением.
Не соглашусь.
Мне нравятся задания в стиле "Отрефакторите представленный код".
В нем ты показываешь что надо поменять, а главное - обосновываешь почему так надо сделать. При этом, зачастую именно в объяснении "почему", мы приходим к основам JS и пониманию языка на низком уровне.
Так же видны знания и понимание необходимого для работы стека технологий, что на мой взгляд важнее "задрачивания" задачек с литкода.
Особенно мне нравятся секция алгоритмов при собесах на позицию фронта.
Да да, мне обязательно на фронте пригодится уменее написать свою сортировку, которая будет работать быстрее всроенного Array.sort(). И разумеется, мне крайне необходимо уметь на лету оценивать сложность каждого написанного метода по Big O.
На фронте вообще не должно быть потребности в больших вычислениях, все расчеты ведуться на бэке и отдаются на фронт порционно. Мы же хотим, что бы наши прилажки работали у всех клиентов, включая бедняг с Intel Atom и 2Gb DDR или смартом с 1Gb памяти на борту.
Какой бы классный я ни написал алгоритм, он всеравно упрется в вычислительные мощности клиента на каком-то объеме данных.
Лучше бы на собесах отдавали больше времени на знание / умение пользоваться определенным набором фрэймворков / библиотек.
Если эти Жигули не ломаются и удовлетворяют всем потребностям пользователя, то почему нет? )
А каскадное удаление то завезли?
А то я решил попробовать призму после TypeORM и слегка прифигел, увидев, что нет каскадного удаления.
Async pipe - отличная вещь, но только в простых компонентах (с простым шаблоном и без бизнес-логики).
Когда появляется много структурных детектив - использовать пайп становится весьма затруднительно. Особенно учитывая то, что забаиндить значение стрима в шаблонную переменную возможно только через использование структурной детективы ngIf или ngFor.
А в статье не рассмотрен гораздо более правильный способ отписки внутри компонента, по сравнению с переменными для подписок.
А именно заведение одной переменной типа Subject и использование возможностей RxJS - takeUntil.
private unsubscrib$e: Subject<void> = new Subject<void>();
ngOnDedtroy() { this.unsubscribe$.next(); this.unsubscribe.complete();}
sub.pipe(takeUntil(this.unsubscribe$)).subscribe()!
Вот, собственно и все. Остаётся только добавить takeUntil на все подписки.
Считаю верными 1, 3 и 4 способ
1 — когда есть единственная подписка
3 — async pipe весьма спецефичен. Довольно редко получается его использовать в проде, так как логика внутри компонента в большинстве случаев завязана на получаемые значения из подписки. Но если в компоненте подписка влияет только на шаблон, то это идеальный вариант
4 — самый универсальный способ, постоянно его тспользую и уже на автомате добавляю в компоненты свойства private unsubscribe$: Subject = new Subject(); и имплементируюсь от OnDestroy
2 способ жизнеспособен, но takeUntil мне как-то ближе
5 и 6 — тянуть дополнительные библиотеки ради отписок? Серьезно?
Да, это не чистая CA, но это один из немногих фрэймворков, который диктует свою архитектуру из коробки, а не порождает зоопарки, извините, говнокода.
Вы написали замечательную статью, но на практике ей вдохновятся единицы, а большая часть сообщество React/Vue так и продолжит порождать в каждом новом проекте новую архитектуру. Раздувать одну бибилиотеку кучей других, потому что из коробки функционала не хватает для большинства real-world проектов.
Как пример — из коробки в React нет TS. Половина будет юзать старый добрый JS, половина перейдет на TS. Дальше хуже — Redux, MobX, просто на хуках. Инструментов великое множество, и каждый такой инструмент зачастую приводит к разнице в архитектуре.
Из-за этого зоопарка, переход между проектами на React/Vue разных команд/компаний очень сложен, так как каждый выстраивает архитектуру как хочет / как умеет. Напротив, при переходе между разными проектами на Angular, вы не ощутите большой разницы и вряд ли встретите какие-либо сюрпризы.
По поводу Angular 1.x (AngularJS) вообще стоит забыть как о страшном сне, это была ошибка, но она привела к созданию Angular 2 =)
То, что в статье названо camelCase, на самом деле является PascalCase
В camelCase первая буква строчная, в PascalCase — заглавная
*Зануда-mode OFF*
Для прореживания данных советую использовать алгоритм Вращающейся двери (SwingingDoor). Он сохраняет общую динамику графика. Но с параметрами тоже придется поиграться, что бы добиться наилучшего результата.
А плодить кучу запросов, мне кажется совсем не верным решением.