Оператор ngx-take-until-destroy скрывает проблему, а не решает её. Большое количество ручных подписок — это императивное управление подписками, в противовес декларативному. Вот хорошая статья на тему: medium.com/@benlesh/rxjs-dont-unsubscribe-6753ed4fda87
Автоматизировать генерацию компонентов — хорошая идея. Уверен, что если вы доработаете библиотеку и опубликуете в NPM, то она будет пользоваться популярностью. Пока вижу такие недостатки:
— Автокомплит путей не будет работать в терминале, так как скрипт запускается не из папки src. В angular-cli тоже есть такая проблема — на проектах с большим количеством папок и компонентов легко промахнуться, создав компонент не там где нужно из-за опечатки.
— Неплохо бы добавить поддержку TypeScript, CSS модулей или вообще дать возможность использовать собственные файлы-шаблоны. Например, я не использую дефолтные экспорты (причины) и не вижу смысла в создании индексных файлов для каждого компонента. Один из способов решения — дать пользователю возможность создавать свои функции для генерации компонентов:
Эту функцию уже может вызывать ваша библиотека, выполняя оставшуюся часть работы. С таким подходом пользователь библиотеки сможет добавить поддержку Less, Styled Components, Flow и любого другого инструмента, не дожидаясь пока библиотека это реализует.
Полностью согласен. Такой подход обладает следующими преимуществами:
— Нет нужды в ручной отписке, AsyncPipe сам отпишется при уничтожении компонента.
— Можем использовать OnPush стратегию обнаружения изменений для улучшения производительности.
— Нет внешнего состояния в this, код компактный и проще воспринимается.
В оригинале есть пример как подписываться на inventoryChanged$:
«Now, in the detail component, we will subscribe to the inventory to get new value.». Там используется ручная подписка вместо async pipe, а отписки вообще нет. По поводу Транспорта событий хотел бы предостеречь — в примере из статьи нет типизации, при опечатке в названии события у вас просто ничего не произойдёт, так как оператор filter будет отсекать все события из-за несовпадения по свойству name. Пример типизации похожего кода: github.com/andywer/typed-emitter/blob/master/index.d.ts
Просто и без последствий провести конференцию не получится. После проведения вас будут обвинять в поддержке расизма, а twitter будет заполнен призывами бойкотировать вашу конференцию. Кто не с нами — тот против нас. В долгосрочной перспективе организаторам выгоднее отменить конференцию, чтобы исправиться в следующем году и избавиться от претензий.
Не понял, зачем тут использовать Svelte, это же просто работа с Canvas. Тоже самое получится на Angular / React / Vue, так как эти фреймворки про упрощение работы с DOM, а не c Canvas.
Отлично, что популяризируете связку React + Mobx, сам тоже на ней остановился — удобно тестируется, превосходно типизируется. Жаль, что в статье больше внимания уделено тулингу, чем архитектуре приложения. Например, не объяснено зачем во все сторы передавать корневой стор, это ведь типичный Service Locator, скрывающий реальные зависимости и усложняющий написание юнит тестов. Например, у меня RootStore выглядит так:
class RootStore {
testEditorStore = new TestEditorStore(testApi);
testListStore = new TestListStore(testApi);
attemptStore = new AttemptStore(attemptApi, testApi);
routerStore = new RouterStore(this, routes);
}
Такие сторы легко юнит-тестируются, по конструктору видно, что достаточно лишь замокать вызовы к API. По поводу роутера — если предлагаете писать вручную, то неплохо бы объяснить чего не хватает в существующих решениях, так как ваш роутер в использовании имеет много общего с mobx-state-router
Быть может есть смысл рассмотреть другие библиотеки для управления состоянием, например MobX, где тоже есть логгирование, девтулзы, но не нужно городить над библиотекой свои обёртки, меняя привычные подходы до неузнаваемости, как это сделано в статьях выше.
Не понятно зачем на бекенде использовать минифицированную версию библиотеки? Это ведь не фронтенд, где стоит стремиться к уменьшению размера итогового бандла.
— Автокомплит путей не будет работать в терминале, так как скрипт запускается не из папки src. В angular-cli тоже есть такая проблема — на проектах с большим количеством папок и компонентов легко промахнуться, создав компонент не там где нужно из-за опечатки.
— Неплохо бы добавить поддержку TypeScript, CSS модулей или вообще дать возможность использовать собственные файлы-шаблоны. Например, я не использую дефолтные экспорты (причины) и не вижу смысла в создании индексных файлов для каждого компонента. Один из способов решения — дать пользователю возможность создавать свои функции для генерации компонентов:
Эту функцию уже может вызывать ваша библиотека, выполняя оставшуюся часть работы. С таким подходом пользователь библиотеки сможет добавить поддержку Less, Styled Components, Flow и любого другого инструмента, не дожидаясь пока библиотека это реализует.
— Нет нужды в ручной отписке, AsyncPipe сам отпишется при уничтожении компонента.
— Можем использовать OnPush стратегию обнаружения изменений для улучшения производительности.
— Нет внешнего состояния в this, код компактный и проще воспринимается.
Если почитать ещё оригинальные статьи автора, то обнаружится, что учить ему ещё очень рано: в примерах ручные подписки, нет отписок, код слаботипизированный: levelup.gitconnected.com/communicate-between-angular-components-using-rxjs-7221e0468b2
Надеюсь, что новички будут читать не только статьи, но и комментарии к ним, иначе научатся вредным подходам.
«Now, in the detail component, we will subscribe to the inventory to get new value.». Там используется ручная подписка вместо async pipe, а отписки вообще нет. По поводу Транспорта событий хотел бы предостеречь — в примере из статьи нет типизации, при опечатке в названии события у вас просто ничего не произойдёт, так как оператор filter будет отсекать все события из-за несовпадения по свойству name. Пример типизации похожего кода: github.com/andywer/typed-emitter/blob/master/index.d.ts
2 элемента нужно чтобы работал обход в обратную сторону по Tab+Shift. Как видите, JS-кода тут совсем мало.
Лермонтов использовал это слово в своих стихотворениях, а теперь вдруг решили, что слово не существует? Слово зафиксировано в различных словарях: gramota.ru/slovari/dic/?word=%D0%BD%D0%B5%D1%82%D1%83&all=x
Такие сторы легко юнит-тестируются, по конструктору видно, что достаточно лишь замокать вызовы к API. По поводу роутера — если предлагаете писать вручную, то неплохо бы объяснить чего не хватает в существующих решениях, так как ваш роутер в использовании имеет много общего с mobx-state-router
— Организация reducer'а через стандартный класс
— Redux-symbiote — пишем действия и редьюсеры почти без боли
— Redux — пересмотр логики reducer'a и actions
— Оверинжинирг 80 уровня или редьсюеры: путь от switch-case до классов
Быть может есть смысл рассмотреть другие библиотеки для управления состоянием, например MobX, где тоже есть логгирование, девтулзы, но не нужно городить над библиотекой свои обёртки, меняя привычные подходы до неузнаваемости, как это сделано в статьях выше.