Вы описали проект по типо сайта визитки, где просто в тупую именно из реактовских компонентов достаточно дергать запросы без какой либо логики.
Да и вообще всё остальное управление состоянием проекта вы как себе представляете?
Этого более чем достаточно для написания всевозможных лендингов и админок, которые составляют немаленький процент от общего числа сайтов. Для всяких корпоративных порталов с формами и списками, где все остальное управление состоянием состоит из работы с данными форм.
в розовых проектах без валидацией, без всевозможных условий формирования запросов, без цепочек запросов
Для хранения данных форм и валидаций мы используем Formik, вполне устраивает, а условия формирования запросов и завязывать один запрос на другой RTK Query умеет.
Для вас MobX - золотой молоток, но тем не менее он нужен далеко не всегда
Ну почему же. В большинстве случаев менеджер состояний используется для хранения данных с бэкенда. Если использовать RTK Query, то просто в коде пишешь что-то типа:
И всё, одна строчка кода и ты получаешь список городов, состояние запроса, кэширование по типу Apollo GraphQL, где не нужно задумываться о том, пришли у тебя данные с бэкенда или из стора.
Реально, одна строчка кода, никого бойлерплейта, а вся редаксовская дичь происходит где-то под капотом. При этом сама API генерируется автоматически из swagger схемы, то есть ничего не надо делать руками, всегда актуальные типы и нет несогласованности бэка с фронтом. Так что для общения с бэком очень удобно.
Да, если писать классические модели данных, записывать туда бизнес логику, то естественно MobX. Но это разные цели. И для большинства проектов за глаза хватит того общения с бэкендом, которое я описал выше
На самом деле многое зависит от продвижения и рекламы. Поскольку даже крутые проекты могут не сыскать известности, а менее качественными продолжают пользоваться только потому, что они на слуху.
Мне кажется, что шансы на большое будущее есть, поскольку фреймворк уже в текущем состоянии весьма удобен, и что самое главное - он первый в своём роде.
Но его создателям я бы рекомендовал писать статьи на профильных ресурсах и выступать на митапах. Собственно этой своей статьей вношу посильную лепту)
Не совсем. Это предложение по улучшению, чтобы можно было инициализировать проект на основе уже существующего манифеста, то есть для миграции уже существующего расширения в инфраструктуру Plasmo.
How do you envision this feature/change to look/work like? - pnpm create plasmo OR pnpm dlx plasmo init OR plasmo init inside a directory with a manifest.json
Если посмотреть на скрин со структурой папок, то там видно, что файла manifest.json в проекте нет. Все вещи описываются в package.json, а потом по команде plasmo build проходит сборка и генерируется манифест с ссылками на все используемые скрипты и ресурсы.
Два месяца назад было ишью, о котором я упоминал в статье с просьбой добавить возможность генерации второй версии манифеста. В результате добавили флаг target. И теперь появилась возможность выполнить следующую команду: plasmo build --target=firefox-mv2
Ну и к тому же проект развивается и, если сейчас какая-то функциональность не поддерживается, то думаю это доработают
Этого более чем достаточно для написания всевозможных лендингов и админок, которые составляют немаленький процент от общего числа сайтов. Для всяких корпоративных порталов с формами и списками, где все остальное управление состоянием состоит из работы с данными форм.
Для хранения данных форм и валидаций мы используем Formik, вполне устраивает, а условия формирования запросов и завязывать один запрос на другой RTK Query умеет.
Для вас MobX - золотой молоток, но тем не менее он нужен далеко не всегда
Ну почему же. В большинстве случаев менеджер состояний используется для хранения данных с бэкенда. Если использовать RTK Query, то просто в коде пишешь что-то типа:
И всё, одна строчка кода и ты получаешь список городов, состояние запроса, кэширование по типу Apollo GraphQL, где не нужно задумываться о том, пришли у тебя данные с бэкенда или из стора.
Реально, одна строчка кода, никого бойлерплейта, а вся редаксовская дичь происходит где-то под капотом. При этом сама API генерируется автоматически из swagger схемы, то есть ничего не надо делать руками, всегда актуальные типы и нет несогласованности бэка с фронтом. Так что для общения с бэком очень удобно.
Да, если писать классические модели данных, записывать туда бизнес логику, то естественно MobX. Но это разные цели. И для большинства проектов за глаза хватит того общения с бэкендом, которое я описал выше
Да, конечно
Вот запись трансляции: https://youtu.be/-glbRXbIAGM?t=4648
И вот ссылка на репозиторий с итоговым результатом: https://github.com/geosins/text-decorator-browser-extension
На самом деле многое зависит от продвижения и рекламы. Поскольку даже крутые проекты могут не сыскать известности, а менее качественными продолжают пользоваться только потому, что они на слуху.
Мне кажется, что шансы на большое будущее есть, поскольку фреймворк уже в текущем состоянии весьма удобен, и что самое главное - он первый в своём роде.
Но его создателям я бы рекомендовал писать статьи на профильных ресурсах и выступать на митапах. Собственно этой своей статьей вношу посильную лепту)
Не совсем. Это предложение по улучшению, чтобы можно было инициализировать проект на основе уже существующего манифеста, то есть для миграции уже существующего расширения в инфраструктуру Plasmo.
How do you envision this feature/change to look/work like?
- pnpm create plasmo
pnpm dlx plasmo initORplasmo initinside a directory with amanifest.jsonЕсли посмотреть на скрин со структурой папок, то там видно, что файла
manifest.jsonв проекте нет. Все вещи описываются в package.json, а потом по командеplasmo buildпроходит сборка и генерируется манифест с ссылками на все используемые скрипты и ресурсы.Два месяца назад было ишью, о котором я упоминал в статье с просьбой добавить возможность генерации второй версии манифеста. В результате добавили флаг
target. И теперь появилась возможность выполнить следующую команду:plasmo build --target=firefox-mv2Ну и к тому же проект развивается и, если сейчас какая-то функциональность не поддерживается, то думаю это доработают
На самом деле декораторы ещё старше. Раньше они находились в другом репозитории: https://github.com/wycats/javascript-decorators/tree/master. И здесь первый коммит датирован 7 мартом 2015.
В тот же день было подано предложение о добавлении декораторов в TypeScript (где они появились в версии 1.5 от 20 июля 2015) https://github.com/Microsoft/TypeScript/issues/2249
А в stage 2 декораторы перешли в июле 2016 https://github.com/tc39/proposals/commit/97eb62f75be13e64341c6242f7291104c28a96f3
Итого для достижения stage 3 потребовалось более семи лет, из которых шесть пришлись на stage 2.