Цель статьи — показать как упростить работу с Redux, без привязки к фичам React. Кроме того, по ощущениям, больше людей знакомы с работой через классы. Крупные проекты, например, зачастую не спешат внедрять моментально все нововведения. Это сложно, долго, дорого и тд.
Поэтому, для целей статьи, не важно хуки это будут или нет. В конце статьи приводятся ссылки
Полный код переписанного на коммуникации примера из доки ReduxToolkit тут, а потыкать можно тут.
Перейдя по ним можно посмотреть как это выглядит с хуками.
Rematch надо попробовать. Выглядит довольно внушительно.
Можно ли это это было сделать без зависимостей — наверно да. Было ли это сделать проще — однозначно нет. Библиотека полностью построена поверх Redux и всего лишь автоматизирует рутинные операции.
Имея под капотом Redux мы можем пользоваться всеми инструментами, которые созданы для работы с ним, например Redux DevTools и это очень удобно.
Какие профиты может дать отделение ее от Redux?
Слегка бомбануло после прочтения первой строки 2-го абзаца. ES7 уже вышел и в нем ничего нового уже не появится. Поэтому я просто оставлю это здесь.
Все описание по тексту и выводы — TypeScript. Зачем вообще было упоминать про ES7?
Так же слегка напрягает описание костылей, которые заставляют декораторы работать, в середине статьи. Лично мне было бы приятнее видеть это в конце статьи.
Статья проработана, содержит примеры и тд. После прочтения я реально проникся идеей декораторов, но описанные мелочи слегка подпортили общее впечатление. Было бы приятно, если бы автор прислушался к моему скромному мнению.
А если вычисления есть? Вытаскивать их из ноды и рулить внешним процессом?
JS не такой медленный, как принято считать. Кроме того, большую часть задач можно разбить на более мелкие. Ну а если и это не сделать, у нас есть сервер на JAVA, который может взять на себя эту тяжеловесную задачу.
Насколько я понимаю под «акторами» на node.js в итоге подразумевалась пачка нодовых процессов, запущенных через cluster, и общающихся через некий внешний event-bus?
Нет. Под актором в данном случае подразумевается нодовский модуль(или группа модулей), общающихся через внешний event-bus. В рамках каждого процесса запущенного через cluster живет куча акторов. Вообще запуск через cluster не является обязательным, он нужен лишь для того, чтобы обеспечить большую производительность.
Cluster тоже не решение, потому что точно также блокирует интерпретатор
А зачем писать на Node что-то блокирующее? JS под это в принципе не заточен. Любую действие надо выполнять максимально быстро, все операции должны быть асинхронными — это основа программирования на JS, будь то браузерное приложение или сервер.
Достоинством акторов в данном случае является то, что мы можем запустить любое число инстанций сервера (используя например cluster) или разнести сервер на разные машины, которые абсолютно равны между собой (не считая мастера, который немного ровнее остальных).
При этом код остается неизменным, нагрузка размазывается по всем инстансам, повышается надежность (умер процесс либо забили либо перезапустили, если возможно) и т.д.
Надеюсь я ответил на вопрос.
что имеется ввиду, когда говорится о глобальной шине?
Vertx-eventbus
Модули NodeJS оформляются таким образом, чтобы не иметь зависимостей (в идеале вообще ни от кого). Обмениваются данными они не напрямую, а путем отправки сообщений через общую шину. Такие модули и называются акторами. При запуске инстанции конфигом определяется какие именно модули надо грузить.
Затем заворачиваем это все в кластер или запускаем на разных машинах и живем долго и счастливо.
Поэтому, для целей статьи, не важно хуки это будут или нет. В конце статьи приводятся ссылки
Перейдя по ним можно посмотреть как это выглядит с хуками.
Rematch надо попробовать. Выглядит довольно внушительно.
Имея под капотом Redux мы можем пользоваться всеми инструментами, которые созданы для работы с ним, например Redux DevTools и это очень удобно.
Какие профиты может дать отделение ее от Redux?
Все описание по тексту и выводы — TypeScript. Зачем вообще было упоминать про ES7?
Так же слегка напрягает описание костылей, которые заставляют декораторы работать, в середине статьи. Лично мне было бы приятнее видеть это в конце статьи.
Статья проработана, содержит примеры и тд. После прочтения я реально проникся идеей декораторов, но описанные мелочи слегка подпортили общее впечатление. Было бы приятно, если бы автор прислушался к моему скромному мнению.
JS не такой медленный, как принято считать. Кроме того, большую часть задач можно разбить на более мелкие. Ну а если и это не сделать, у нас есть сервер на JAVA, который может взять на себя эту тяжеловесную задачу.
Нет. Под актором в данном случае подразумевается нодовский модуль(или группа модулей), общающихся через внешний event-bus. В рамках каждого процесса запущенного через cluster живет куча акторов. Вообще запуск через cluster не является обязательным, он нужен лишь для того, чтобы обеспечить большую производительность.
А зачем писать на Node что-то блокирующее? JS под это в принципе не заточен. Любую действие надо выполнять максимально быстро, все операции должны быть асинхронными — это основа программирования на JS, будь то браузерное приложение или сервер.
Достоинством акторов в данном случае является то, что мы можем запустить любое число инстанций сервера (используя например cluster) или разнести сервер на разные машины, которые абсолютно равны между собой (не считая мастера, который немного ровнее остальных).
При этом код остается неизменным, нагрузка размазывается по всем инстансам, повышается надежность (умер процесс либо забили либо перезапустили, если возможно) и т.д.
Надеюсь я ответил на вопрос.
Vertx-eventbus
Модули NodeJS оформляются таким образом, чтобы не иметь зависимостей (в идеале вообще ни от кого). Обмениваются данными они не напрямую, а путем отправки сообщений через общую шину. Такие модули и называются акторами. При запуске инстанции конфигом определяется какие именно модули надо грузить.
Затем заворачиваем это все в кластер или запускаем на разных машинах и живем долго и счастливо.