Поднимая атом, подход 2.0.1
- суббота, 16 мая 2020 г. в 00:27:15
https://habr.com/ru/post/502038/
Не прошло и года, вторая статья около тем реактивности данных. Цель текущего цикла разработки, разобраться в понятиях и зафиксировать API библиотеки. Мне, как автору стремящемуся к полиглотизму, стало фиолетово на способы описания ручек.
Согласно моей карте знания области функционального программирования, базовая частица библиотеки по прежнему остаётся функтором раскаченной до монады (и наоборот если взглядом древнегреческих философов). Карта никогда не станет территорией, и в текущей реинкарнации решено выйти из этого дремучего-леса/диких-джунглей функциональной терминологии и подготовить документацию на родном, человеческом языке.
Для генерации документации попробовал documenter пакета api-extractor от microsoft, упаковав полученный маркдаун в docusaurus от facebook.
Вот что получилось: alak.now.sh
Оптимальным кажется генерировать статику для сайта документации на свой вкус из json полученным от api-extractor. Docusaurus и documenter несут с собой некие клеше и монструозность корпоративного подхода к разработке. Всё можно сильно легче и краше, прошлось добавить несколько промежуточных трансформаций для компактности сайта.
Работу ядра прошлых версии библиотеки обеспечивал
Обычно подобное приходится класть в конфиг из за необходимости отучать TS быть похожим на C#. Типы и дженерики для JS, имхо, не должны подтягивать новую философию. Тем не менее библиотека стремится на 100% соответствовать стандартом TS. Обещаю добавить тестирование типов по всей строгости. Сейчас тестируются скомпилированные js-бандлы, так показалось лучше.
Может кто помнит пост от 1 сентября 2014 года Атом — минимальный кирпичик реактивного приложения. Алак это атом версии 2020 года, применяемый на боевых JS проектах для создания различных MV* (в основном MVVM) паттернов проектирования. Поскольку это достаточно легковесное и быстрое решение, нашлось применение и на сервере для управления сокетами, сессиями и пользователями. Уже года 4 вынашиваю что-то вроде спринга для простой и сложной логики на основе атома, об этом возможно в другой раз. А сейчас, предлагаю познакомится с управлением состоянием копонента за его пределами из любой точкивселенной вашего кода.
Пример на codesandbox
Очень часто не нужно подтягивать какой-либо крутой стор.
Берём атом, хук, логику и готово.
Однажды делал большой проект на vue2, и пробовал поделится кодом своего большого и крутого стора для vue, даже получил 15 звёздочек от китайцев. Но на следующем большом vue проекте, стор изменился концептуально, а сейчас пошли проекты на jsx с хуками. В основе всегда использовал эту реактивную частицу. Такая альтернатива на поколение опережает шину событий, паттерн наблюдатель, и другие библиотеки связи модуля А с модулем/компоненом B.
С прошлой статьи вроде учтены всё возникшие конфузы читателей. Сейчас не должно возникать вопросов о ручках API, что такое up и down. Названия постарался сделать максимально отражающими суть действия, документация на русском доступна во всех IDE и codesandbox из авто-подсказок.
Первая версия не задалось, второй ещё нет.
Как проверить готовность версии?
Чего не хватает?
- JavaScript
- Функциональное программирование
- TypeScript
Не прошло и года, вторая статья около тем реактивности данных. Цель текущего цикла разработки, разобраться в понятиях и зафиксировать API библиотеки. Мне, как автору стремящемуся к полиглотизму, стало фиолетово на способы описания ручек.
— Да и вообще, в Матрице слишком много информации, чтобы ее декодировать.
Надо просто привыкнуть.
Я вообще не вижу кода.
Вижу блондинку, брюнетку, рыжую.
Итак, представляю alak 2.0.1-RC
Согласно моей карте знания области функционального программирования, базовая частица библиотеки по прежнему остаётся функтором раскаченной до монады (и наоборот если взглядом древнегреческих философов). Карта никогда не станет территорией, и в текущей реинкарнации решено выйти из этого дремучего-леса/диких-джунглей функциональной терминологии и подготовить документацию на родном, человеческом языке.
Для генерации документации попробовал documenter пакета api-extractor от microsoft, упаковав полученный маркдаун в docusaurus от facebook.
Вот что получилось: alak.now.sh
Оптимальным кажется генерировать статику для сайта документации на свой вкус из json полученным от api-extractor. Docusaurus и documenter несут с собой некие клеше и монструозность корпоративного подхода к разработке. Всё можно сильно легче и краше, прошлось добавить несколько промежуточных трансформаций для компактности сайта.
Кирпич для TypeScript
Работу ядра прошлых версии библиотеки обеспечивал
Proxy. После замеров производительности в сравнении с __proto__ разница оказалась небольшой. Оба решения достаточны быстрые и экономные по памяти. Решение текущей версии по умолчанию стартует на __proto__. Использование прототипов в тайпскрипте безжалостно кидает в сторону создания классов, чья производительность ощутимо ниже. Как и enum сперва казалось классным решением, а ныне использую просто константу или типизированные строки из-за неочевидности поведения enum при сериализации. Люблю дженерики и отношусь к авторам считающим правила C# (под что косят официальные документации TS) излишними в JS мире. Видел много ругани в сторону typescript за тип any, считаю именно существование этого типа делает js-код на typescript великим. (снова)) noImplicitAny:falseОбычно подобное приходится класть в конфиг из за необходимости отучать TS быть похожим на C#. Типы и дженерики для JS, имхо, не должны подтягивать новую философию. Тем не менее библиотека стремится на 100% соответствовать стандартом TS. Обещаю добавить тестирование типов по всей строгости. Сейчас тестируются скомпилированные js-бандлы, так показалось лучше.
Так что за… Алак?
Может кто помнит пост от 1 сентября 2014 года Атом — минимальный кирпичик реактивного приложения. Алак это атом версии 2020 года, применяемый на боевых JS проектах для создания различных MV* (в основном MVVM) паттернов проектирования. Поскольку это достаточно легковесное и быстрое решение, нашлось применение и на сервере для управления сокетами, сессиями и пользователями. Уже года 4 вынашиваю что-то вроде спринга для простой и сложной логики на основе атома, об этом возможно в другой раз. А сейчас, предлагаю познакомится с управлением состоянием копонента за его пределами из любой точки
Пример на codesandbox
Очень часто не нужно подтягивать какой-либо крутой стор.
Берём атом, хук, логику и готово.
Однажды делал большой проект на vue2, и пробовал поделится кодом своего большого и крутого стора для vue, даже получил 15 звёздочек от китайцев. Но на следующем большом vue проекте, стор изменился концептуально, а сейчас пошли проекты на jsx с хуками. В основе всегда использовал эту реактивную частицу. Такая альтернатива на поколение опережает шину событий, паттерн наблюдатель, и другие библиотеки связи модуля А с модулем/компоненом B.
Бла-бла спагетти
Лет так 12 назад во времена расцвета ActionScript, MVC и инверсии зависимостей. Гуру-флэшеры с негодованием смотрели на MVC-библиотеки, утверждая какое-либо отсутствие всякой необходимости в них. Вопреки советам старших, получив очередной новый большой проект в качестве лида, стал делать его на крутой либе — mvcExpress. Начало было классным, а спустя год, следуя всем канонам, код всё равно превратился в подобие спагетти.
Такова бизнес-логика, её важно уметь готовить. Иной раз действительно лучше всего может подойти mobx или effector. Воще это дело вкуса. Но повторюсь, важно уметь готовить бизнес-логику а не канонический redux. Всё же мы пишем софт для заказчика/пользователей, и бывает нужно именно логическое спагетти несовместимое с существующими решениями.
Возможно опыт использования готовых сторов необходим для понимания принципа необходимости отделения отображения от данных. Это как шутили раньше что каждый флешер должен сделать свой видео-проигрыватель, (а ещё раньше каждый программист должен написать свой язык с компилятором). Сейчас видимо каждый фронтовик должен сделать свой стор. Вероятно по этому я не спешу делится своим стором, он меняется от проекта к проекту. Свой вклад в сообщество продолжаю вносить в таком формате. Делюсь лучим что есть в моём js-коде.
Такова бизнес-логика, её важно уметь готовить. Иной раз действительно лучше всего может подойти mobx или effector. Воще это дело вкуса. Но повторюсь, важно уметь готовить бизнес-логику а не канонический redux. Всё же мы пишем софт для заказчика/пользователей, и бывает нужно именно логическое спагетти несовместимое с существующими решениями.
Возможно опыт использования готовых сторов необходим для понимания принципа необходимости отделения отображения от данных. Это как шутили раньше что каждый флешер должен сделать свой видео-проигрыватель, (а ещё раньше каждый программист должен написать свой язык с компилятором). Сейчас видимо каждый фронтовик должен сделать свой стор. Вероятно по этому я не спешу делится своим стором, он меняется от проекта к проекту. Свой вклад в сообщество продолжаю вносить в таком формате. Делюсь лучим что есть в моём js-коде.
Быть или не быть?
С прошлой статьи вроде учтены всё возникшие конфузы читателей. Сейчас не должно возникать вопросов о ручках API, что такое up и down. Названия постарался сделать максимально отражающими суть действия, документация на русском доступна во всех IDE и codesandbox из авто-подсказок.
Первая версия не задалось, второй ещё нет.
Как проверить готовность версии?
Чего не хватает?