Forwarded from Effector news (Дима Zerꙫbias)
В open source вышло приложение, написанное на эффекторе ✨
Часто возникает вопрос, можно ли где-то посмотреть примеры реальных, продуктовых приложений, написанных на эффекторе? Разумеется, большинство приложений — с закрытым исходным кодом и открытых примеров мало.
В 22 году два из мейнтейнеров проекта, @ZeroBias и @sergeysova работали в компании roke.to и разрабатывали фронтенд часть приложения. Компания не пережила падение FTX, но внезапно на днях решили открыть все наработки в open source, очень похвальное решение 👏
Код в приложении (даже двух, на самом деле) написан на момент 22 года, например там используется useStore вместо useUnit, но в целом это полноценный пример реального кода, которое разрабатывали в прод
Свободно для изучения 🤓
https://github.com/roke-to/roketo-ui
https://github.com/roke-to/roketo-business-ui
Часто возникает вопрос, можно ли где-то посмотреть примеры реальных, продуктовых приложений, написанных на эффекторе? Разумеется, большинство приложений — с закрытым исходным кодом и открытых примеров мало.
В 22 году два из мейнтейнеров проекта, @ZeroBias и @sergeysova работали в компании roke.to и разрабатывали фронтенд часть приложения. Компания не пережила падение FTX, но внезапно на днях решили открыть все наработки в open source, очень похвальное решение 👏
Код в приложении (даже двух, на самом деле) написан на момент 22 года, например там используется useStore вместо useUnit, но в целом это полноценный пример реального кода, которое разрабатывали в прод
Свободно для изучения 🤓
https://github.com/roke-to/roketo-ui
https://github.com/roke-to/roketo-business-ui
👍28🔥12🙈7😐3👎2😁1
Вы можете подписаться на мои списки застаренных репозиториев на гитхабе.
https://github.com/sergeysova
Я регулярно нахожу новые инструменты и добавляю их в списки.
Когда нахожу силы и время, то собираю статьи и репозитории в виде рассылки.
https://news.sova.dev/
Скоро будет новый сезон подборок статей. Обычно я выкладываю их также здесь в Telegram для удобства.
https://github.com/sergeysova
Я регулярно нахожу новые инструменты и добавляю их в списки.
Когда нахожу силы и время, то собираю статьи и репозитории в виде рассылки.
https://news.sova.dev/
Скоро будет новый сезон подборок статей. Обычно я выкладываю их также здесь в Telegram для удобства.
👍18👎10🔥4🤔3😁2❤1
Очень рад, что Андрей написал об этом.
Считаю всем стоит обратить своё внимание, что React уже не торт.
https://t.me/xavescor_code/137
Считаю всем стоит обратить своё внимание, что React уже не торт.
https://t.me/xavescor_code/137
Telegram
Андруша пишет код
Почему реакт идёт куда-то не туда pt1
- React Server Components(RSC) вы тута
- React Compiler
- Hooks
Спасибо подкасту "Веб-Стандарты"(https://www.youtube.com/@webstandards_ru), за напоминание что у меня горит от реакта. Всем рекомендую.
RSC - это возможность…
- React Server Components(RSC) вы тута
- React Compiler
- Hooks
Спасибо подкасту "Веб-Стандарты"(https://www.youtube.com/@webstandards_ru), за напоминание что у меня горит от реакта. Всем рекомендую.
RSC - это возможность…
👍35👎4🤔1
Всем привет!
27 мая буду участвовать в круглом столе на конференции Podlodka React Crew. Вместе с Максимом Вишневским и Сергеем Самоховым обсудим архитектуру React-приложений, организацию компонентов и данных, React Compiler, реактивность в React и многое другое.
Также будут выступления по Feature-Sliced Design, миграции проектов и выбору стейт-менеджера.Для моих подписчиков промокод на билеты:
27 мая буду участвовать в круглом столе на конференции Podlodka React Crew. Вместе с Максимом Вишневским и Сергеем Самоховым обсудим архитектуру React-приложений, организацию компонентов и данных, React Compiler, реактивность в React и многое другое.
Также будут выступления по Feature-Sliced Design, миграции проектов и выбору стейт-менеджера.Для моих подписчиков промокод на билеты:
react_crew_1_PHXAp9.🔥20👍7❤3😁2🤩1🙈1
Я уже не первый раз читаю в группах, что ChatGPT довольно тупой и ничего не умеет, даже 4o модель.
Хочу с этим поспорить, пусть до AGI далеко, и в шахматы даже не умеет играть, совершает супер тупые ошибки в игре и галлюцинирует уже потерянными фигурами.
Но даже такие ограниченные возможности можно весьма неплохо применить при обработке больших объемов текста. Из самых простых кейсов:
1) может извлечь транскрипцию из видео, затем сгенерировать сценарий видео по транскрипции;
2) прочитать документацию open-source проекта и выявить устаревшие неактуальные параграфы и целые статьи;
3) составить расписание на неделю по технике time blocking, через Actions;
4) все что угодно на самом деле, так как можно подключить огромное хранилище данных в виде векторных эмбеддингов, а ChatGPT сам будет искать по нему и извлекать подходящие запросу данные;
5) можно подключить Actions, чтобы ChatGPT мог делать запросы по сети с разрешения пользователя;
6) можно преднастроить ChatGPT и опубликовать в GPTs Store, чтобы каждый раз не копипастить промпты;
Я всё это к чему, ChatGPT конечно ограничен в возможностях, но даже эти возможности довольно легко использовать для упрощения своей жизни, особенно если вы можете писать python/nodejs.
Так как, я использую нейронки в своей жизни для очень разных задач, буду чаще делиться своими юзкейсами.
🤖
Хочу с этим поспорить, пусть до AGI далеко, и в шахматы даже не умеет играть, совершает супер тупые ошибки в игре и галлюцинирует уже потерянными фигурами.
Но даже такие ограниченные возможности можно весьма неплохо применить при обработке больших объемов текста. Из самых простых кейсов:
1) может извлечь транскрипцию из видео, затем сгенерировать сценарий видео по транскрипции;
2) прочитать документацию open-source проекта и выявить устаревшие неактуальные параграфы и целые статьи;
3) составить расписание на неделю по технике time blocking, через Actions;
4) все что угодно на самом деле, так как можно подключить огромное хранилище данных в виде векторных эмбеддингов, а ChatGPT сам будет искать по нему и извлекать подходящие запросу данные;
5) можно подключить Actions, чтобы ChatGPT мог делать запросы по сети с разрешения пользователя;
6) можно преднастроить ChatGPT и опубликовать в GPTs Store, чтобы каждый раз не копипастить промпты;
Я всё это к чему, ChatGPT конечно ограничен в возможностях, но даже эти возможности довольно легко использовать для упрощения своей жизни, особенно если вы можете писать python/nodejs.
Так как, я использую нейронки в своей жизни для очень разных задач, буду чаще делиться своими юзкейсами.
🤖
👍38❤3👎3🔥3
Приятных выходных!
Можно ожидать появления инстанциируемых моделей в effector. Основная цель — добавление API для создания инстансов моделей для динамичских списков. Получится, например, сделать классный менеджер форм с динамическими полями, а также обобщить написание кода.
API может выглядеть вот так:
Я думаю, это API должно решить проблему усложнения проекта, когда существующий код внезапно нужно вызывать для элементов списка. Сейчас нужно переписывать на keyval или ему подобные решения, чтобы избежать создания моделей в рантайме.
API model/spawn будет решать этот кейс через создание шаблона модели, а уже затем при отправке в неё ивентов определять в какой именно инстанс прилетит апдейт. В общем, идея простая, но в частности вылезает очень много нестандартных кейсов.
Я всё еще буду продолжать настаивать на том, что создавать инстансы моделей в компонентах — плохая идея. А пока что динамика может быть таким escape hatch для SPA-only приложений.
Публичное обсуждение можно посмотреть в треде:
https://t.me/effector_ru/337809
А внутренний документ с некоторыми деталями API:
https://effector.notion.site/Effector-models-5cca5c90410c4707ab1cdaea37e0cbae
Можно ожидать появления инстанциируемых моделей в effector. Основная цель — добавление API для создания инстансов моделей для динамичских списков. Получится, например, сделать классный менеджер форм с динамическими полями, а также обобщить написание кода.
API может выглядеть вот так:
const counterModel = model({
props: {},
create() {
const $counter = createStore(0)
const incremented = createEvent()
$counter.on(incremented, (counter) => counter + 1)
return { $counter, incremented }
}
})
const counter = spawn(counterModel)
sample({
clock: incrementClicked,
target: counter.props.incremented,
})
Я думаю, это API должно решить проблему усложнения проекта, когда существующий код внезапно нужно вызывать для элементов списка. Сейчас нужно переписывать на keyval или ему подобные решения, чтобы избежать создания моделей в рантайме.
API model/spawn будет решать этот кейс через создание шаблона модели, а уже затем при отправке в неё ивентов определять в какой именно инстанс прилетит апдейт. В общем, идея простая, но в частности вылезает очень много нестандартных кейсов.
Я всё еще буду продолжать настаивать на том, что создавать инстансы моделей в компонентах — плохая идея. А пока что динамика может быть таким escape hatch для SPA-only приложений.
Публичное обсуждение можно посмотреть в треде:
https://t.me/effector_ru/337809
А внутренний документ с некоторыми деталями API:
https://effector.notion.site/Effector-models-5cca5c90410c4707ab1cdaea37e0cbae
🔥20👍6👎5🤔3😁1😡1
Danila_Anisimov_Resume.pdf
98.7 KB
Начнем неделю с резюме разработчика!
Ищите в свою команду frontend-разработчика с образованием магистра машинного обучения и высоконагруженных систем?
Danila Anisimov – разработчик с опытом в создании веб-приложений и AI-решений на React и Next.js.
Крайне рекомендую почитать резюме, возможно именно этот разработчик отлично подойдет вашей команде.
Контакты: https://linkedin.com/in/danila-anisimov | https://github.com/ExLineP
Ищите в свою команду frontend-разработчика с образованием магистра машинного обучения и высоконагруженных систем?
Danila Anisimov – разработчик с опытом в создании веб-приложений и AI-решений на React и Next.js.
Крайне рекомендую почитать резюме, возможно именно этот разработчик отлично подойдет вашей команде.
Контакты: https://linkedin.com/in/danila-anisimov | https://github.com/ExLineP
Forwarded from © Как его там… (Dmitry Remezov)
🚦Роутинг
Или как мы топчемся на месте.
Современная веб разработка приучила нас к тому, что "роут" - компонент на какому-то пути.
Все популярные решения (react-router, Next.js, Angular, Vue и пр.), каждый со своими фичами сбоку, обыгрывают именно этот концепт.
Если попробовать дать им общее определение, то будет что-то вроде "Роутинг - механизм связи URL, данных и интерфейса".
Достаточно ли этого?
Действительно ли роутинг в вебе это просто
Для начала попробую сформулировать общее определение.
Роутинг в клиентских приложениях - механизм управления переходами между узлами пользовательских сценариев, состоянием этих узлов и их связью с внешним миром.
Покрывают ли это мейнстримные решения?
Безусловно, но настолько изолировано, ограничено и с привязкой к конкретному окружению, что мы не можем связать роутинг с остальной логикой без костылей, а всё, что не заложено в решение (а заложено только `.push("/another/path”)`), будет физически невозможно и придется реализовывать это самим.
Что такое роут?
Роутом, или, как я сформулировал выше, "узлом" может быть любой самодостаточный элемент пользовательского пути, например:
- Любая страница/лейаут
- Виджет выбора эмоджи
- Диалоговое окно
- Полноэкранный поиск (популярный нынче `⌘K`)
- Окно с выбором стикеров в телеграме в виде тултипа, открываемого при наведении
В приложенном коде я наметил возможную реализацию последнего примера, тултипа со стикерами в телеграме, на effector и atomic-router.
В тот момент, когда логика "что-то открылось/закрылось" перестает быть неважной деталью реализации и становится явным звеном пользовательского сценария, это "что-то" становится роутом.
Неважно открыт тултип или нет, это просто подсказка в интерфейсе, но, когда в нём целый виджет, "неважная деталь реализации" становится ключевой, у виджета появляется роут и логика работы с ним.
И не имеет значения что это - тултип, страница или модалка, это просто способ связи роута и внешнего мира.
Внешний мир
То, что мы привыкли считать неотъемлемыми частями роутинга, - лишь частные случаи.
В мобильных приложениях и виджетах нет URL.
В тестах не нужны компоненты.
В коде большинства продуктов нет голых путей, все работают через какую-то абстракцию по типу
Люди делают приложения, роутинг которых почти полностью построен на модалках.
В логике нет путей, в логике нет компонентов, всё это - внешний мир.
Расширяемость
В приложенных схемах я попробовал отразить разницу мейнстримных моделей и общей модели, выведу основные тезисы.
Ограниченная модель:
- Прибита к компонентам и к URL/файлам
- Нет явных сущностей роутов, вся работа через строки
- Любая "фича" - частный случай, а не системное решение (react-router тут явно лидирует)
- Реализует под капотом самопальную реактивную систему
Расширяемая модель:
- Строится поверх общей реактивной системы
- Дает базовые примитивы - явные сущности роутов и основные методы для построения логики
- Все "фичи" и сайд-эффекты (URL / компоненты / ...) реализуются поверх базовых примитивов
- Логика роутинга напрямую связана со всей остальной логикой
Ограниченная модель реализуется поверх расширяемой, но не наоборот.
Мораль
А нет её, в мейнстриме всё плохо, второй десяток лет с завидным упорством запрягаем старую клячу, надеюсь, мы всё же увидим прогресс.
А пока можете попробовать atomic-router.
Или как мы топчемся на месте.
Современная веб разработка приучила нас к тому, что "роут" - компонент на какому-то пути.
Все популярные решения (react-router, Next.js, Angular, Vue и пр.), каждый со своими фичами сбоку, обыгрывают именно этот концепт.
Если попробовать дать им общее определение, то будет что-то вроде "Роутинг - механизм связи URL, данных и интерфейса".
Достаточно ли этого?
Действительно ли роутинг в вебе это просто
{path, element, loader, …}?Для начала попробую сформулировать общее определение.
Роутинг в клиентских приложениях - механизм управления переходами между узлами пользовательских сценариев, состоянием этих узлов и их связью с внешним миром.
Покрывают ли это мейнстримные решения?
Безусловно, но настолько изолировано, ограничено и с привязкой к конкретному окружению, что мы не можем связать роутинг с остальной логикой без костылей, а всё, что не заложено в решение (а заложено только `.push("/another/path”)`), будет физически невозможно и придется реализовывать это самим.
Что такое роут?
Роутом, или, как я сформулировал выше, "узлом" может быть любой самодостаточный элемент пользовательского пути, например:
- Любая страница/лейаут
- Виджет выбора эмоджи
- Диалоговое окно
- Полноэкранный поиск (популярный нынче `⌘K`)
- Окно с выбором стикеров в телеграме в виде тултипа, открываемого при наведении
В приложенном коде я наметил возможную реализацию последнего примера, тултипа со стикерами в телеграме, на effector и atomic-router.
В тот момент, когда логика "что-то открылось/закрылось" перестает быть неважной деталью реализации и становится явным звеном пользовательского сценария, это "что-то" становится роутом.
Неважно открыт тултип или нет, это просто подсказка в интерфейсе, но, когда в нём целый виджет, "неважная деталь реализации" становится ключевой, у виджета появляется роут и логика работы с ним.
И не имеет значения что это - тултип, страница или модалка, это просто способ связи роута и внешнего мира.
Внешний мир
То, что мы привыкли считать неотъемлемыми частями роутинга, - лишь частные случаи.
В мобильных приложениях и виджетах нет URL.
В тестах не нужны компоненты.
В коде большинства продуктов нет голых путей, все работают через какую-то абстракцию по типу
.push(routes.product.edit({ id: ... })), ведь строки - неудобный и откровенно дырявый способ идентификации роутов.Люди делают приложения, роутинг которых почти полностью построен на модалках.
В логике нет путей, в логике нет компонентов, всё это - внешний мир.
Расширяемость
В приложенных схемах я попробовал отразить разницу мейнстримных моделей и общей модели, выведу основные тезисы.
Ограниченная модель:
- Прибита к компонентам и к URL/файлам
- Нет явных сущностей роутов, вся работа через строки
- Любая "фича" - частный случай, а не системное решение (react-router тут явно лидирует)
- Реализует под капотом самопальную реактивную систему
Расширяемая модель:
- Строится поверх общей реактивной системы
- Дает базовые примитивы - явные сущности роутов и основные методы для построения логики
- Все "фичи" и сайд-эффекты (URL / компоненты / ...) реализуются поверх базовых примитивов
- Логика роутинга напрямую связана со всей остальной логикой
Ограниченная модель реализуется поверх расширяемой, но не наоборот.
Мораль
А нет её, в мейнстриме всё плохо, второй десяток лет с завидным упорством запрягаем старую клячу, надеюсь, мы всё же увидим прогресс.
А пока можете попробовать atomic-router.
👍25👎7❤5🔥3
Уже через час будет круглый стол по архитектуре на Podlodka React Crew.
https://t.me/sergeysova/955
Увидимся там!
https://t.me/sergeysova/955
Увидимся там!
Telegram
Сова пишет…
Всем привет!
27 мая буду участвовать в круглом столе на конференции Podlodka React Crew. Вместе с Максимом Вишневским и Сергеем Самоховым обсудим архитектуру React-приложений, организацию компонентов и данных, React Compiler, реактивность в React и многое…
27 мая буду участвовать в круглом столе на конференции Podlodka React Crew. Вместе с Максимом Вишневским и Сергеем Самоховым обсудим архитектуру React-приложений, организацию компонентов и данных, React Compiler, реактивность в React и многое…
👎12 7❤5😁3👍2
Если вы присутствовали на круглом столе, напишите свой отзыв, пожалуйста.
Ну и здесь можно продолжить дискуссию, написать свои вопросы/комментарии/мнение.
А ещё, если есть желание увидеться со спикерами.
Я в ближайшее время в Армении.
Ну и здесь можно продолжить дискуссию, написать свои вопросы/комментарии/мнение.
А ещё, если есть желание увидеться со спикерами.
👎16👍12❤5🤩5🤬3
А вот и запись!
https://youtu.be/7p7dJTyz4i4
P.S.
Если вы хотите, чтобы мне было не пофиг на дизлайки, то пишите в комментах, почему их ставите. Критику готов послушать.
https://youtu.be/7p7dJTyz4i4
P.S.
YouTube
Круглый стол: Архитектурные вопросы в разрезе React. Максим Вишневский, Сергей Самохов, Сергей Сова
Программируешь на React, используешь хуки и популярные инструменты из npm? А что если мы скажем, что ко всему этому можно относиться более ответственно?
Поговорим об архитектуре в целом, о реакте как о рендер-движке, организации компонентов и данных, подумаем…
Поговорим об архитектуре в целом, о реакте как о рендер-движке, организации компонентов и данных, подумаем…
👎23🔥17👍16🤯8😱8🤬6
Вместо Next.js я использую vike.dev для SSR проектов.
Один из громадных плюсов это глубокая кастомизация (при необходимости), а также удобства для разработчика.
Столкнулся с проблемой: при клиентских переходах не запускается логика effector. При перезагрузке страницы, а именно запуске логики на сервере, всё ОК, но на клиенте при
Пошел смотреть в репу:
https://github.com/vikejs/vike/blob/main/vike/client/client-routing-runtime/getPageContextFromHooks.ts
А там куча комментов от разработчиков. В итоге, за пару минут чтения, а потом и исправления всё пофиксил.
Оказалось, что запуск логики нужно размещать в
Документация пока что не покрывает вопросы глубокой интеграции с СТМ. Хотя комментарии во внутреннем коде многое объясняют, за что спасибо разработчикам.
Один из громадных плюсов это глубокая кастомизация (при необходимости), а также удобства для разработчика.
Столкнулся с проблемой: при клиентских переходах не запускается логика effector. При перезагрузке страницы, а именно запуске логики на сервере, всё ОК, но на клиенте при
navigate(), пустота. Лишь в логах видно getPageContextFromHooks.Пошел смотреть в репу:
https://github.com/vikejs/vike/blob/main/vike/client/client-routing-runtime/getPageContextFromHooks.ts
А там куча комментов от разработчиков. В итоге, за пару минут чтения, а потом и исправления всё пофиксил.
Оказалось, что запуск логики нужно размещать в
+onBeforeRender.ts, а не в +onRenderHtml.tsx.Документация пока что не покрывает вопросы глубокой интеграции с СТМ. Хотя комментарии во внутреннем коде многое объясняют, за что спасибо разработчикам.
👎137👍35😁9😱7🤯6😢6
Как еще можно использовать patronum
Продолжаем разбираться зачем использовать patronum, если можно всё описать через
Такие шортхенды как
Для начала разберемся, что за кусочек логики тут описан,
Когда пользователь нажал Продолжить,
Взять email и OTP,
Если email И OTP валидны
И этап логина НЕ initial,
Начать верификацию OTP.
Без шортхендов фильтр выглядел бы так:
Продолжаем разбираться зачем использовать patronum, если можно всё описать через
combine().Такие шортхенды как
and, or, not, и т.д. позволяют сократить количество кода и повысить наглядность.Для начала разберемся, что за кусочек логики тут описан,
sample описывает один шаг в сценарии:clock: когда что-то случилось,source: взять данные отсюда,filter: если выполняется условие,target: передать сюда данные из source.Когда пользователь нажал Продолжить,
Взять email и OTP,
Если email И OTP валидны
И этап логина НЕ initial,
Начать верификацию OTP.
Без шортхендов фильтр выглядел бы так:
combine(
$emailValid,
$otpValid,
$stageInitial,
(email, otp, stageInitial) =>
email && otp && !stageInitial
),
😁194🤬25😱17🤔15👍14🤯13
Год назад я писал о том, что запускаю образовательную программу "Разработка по-взрослому". Ее цель — погрузить участников в разработку фронтенд-приложений, рассказать, зачем таким проектам нужна архитектура, как проще использовать React, в каких случаях полезен Effector и т.д.
Изначально в программе рассказывалось, как разработать приложение, но сами по себе знания в формате видео не дают практических навыков. Хоть рассказываемые практики остаются проверенными и работающими, в ряде случаев оказалось сложно донести их в видеоформате. Поэтому мы меняем формат: участники будут писать свой продукт, а мы выступим в роли менторов.
Помимо этого, мы улучшили формат программы: продолжительность видео уменьшили до 30 минут, переехали из Telegram на веб-платформу для более удобного просмотра материалов, дополнили видео статьями, а также добавили тесты для самопроверки.
Этот пост – начало открытого рассказа о нашем опыте создания образовательной программы на основе готового проекта. Наша задача в этой программе — научить писать и запускать веб-приложения в продакшен, используя лучшие практики, планирования разработки, деплоя в продакшен с резервными копиями и отслеживанием метрик.
#react #typescript #architecture #effector
В комментариях я напишу еще детали…
Изначально в программе рассказывалось, как разработать приложение, но сами по себе знания в формате видео не дают практических навыков. Хоть рассказываемые практики остаются проверенными и работающими, в ряде случаев оказалось сложно донести их в видеоформате. Поэтому мы меняем формат: участники будут писать свой продукт, а мы выступим в роли менторов.
Помимо этого, мы улучшили формат программы: продолжительность видео уменьшили до 30 минут, переехали из Telegram на веб-платформу для более удобного просмотра материалов, дополнили видео статьями, а также добавили тесты для самопроверки.
Этот пост – начало открытого рассказа о нашем опыте создания образовательной программы на основе готового проекта. Наша задача в этой программе — научить писать и запускать веб-приложения в продакшен, используя лучшие практики, планирования разработки, деплоя в продакшен с резервными копиями и отслеживанием метрик.
#react #typescript #architecture #effector
В комментариях я напишу еще детали…
🤬451👍32🔥13 9👎7 6
Мне нравится, что декларативный подход effector не так сильно раздувает API, которое необходимо, чтобы писать приложения практически любой сложности.
P.S.
Справедливости ради, сюда вполне можно докинуть patronum, atomic-router, farfetched, effector-*, и это всё будет раздувать необходимое для работы API.
Насколько мне известно, такая же ситуация обстоит и с другими стейт-менеджерами, поэтому приводить её не стал.
Решить проблему конечно можно, так как образовалась пачка устойчивых регулярных пакетов, можно сделать мета-пакет типа
P.S.
Справедливости ради, сюда вполне можно докинуть patronum, atomic-router, farfetched, effector-*, и это всё будет раздувать необходимое для работы API.
Насколько мне известно, такая же ситуация обстоит и с другими стейт-менеджерами, поэтому приводить её не стал.
Решить проблему конечно можно, так как образовалась пачка устойчивых регулярных пакетов, можно сделать мета-пакет типа
npm install framework-react, внутрь которого засунуть все необходимые обычно пакеты.👎66👍21❤5🤔4🔥3🗿1
SpaceX приводнили свой огромный корабль.
За 4 запуска им удалось достичь настолько амбициозной цели.
Я все это к чему, мы наглядно видим, как огромный проект разрабатывается итеративно.
Обязательно запускайте свои проекты на ранних стадиях, не ждите пока будут готовы все фичи.
Именно такие запуски дают возможность сделать фичи действительно полезными
За 4 запуска им удалось достичь настолько амбициозной цели.
Я все это к чему, мы наглядно видим, как огромный проект разрабатывается итеративно.
Обязательно запускайте свои проекты на ранних стадиях, не ждите пока будут готовы все фичи.
Именно такие запуски дают возможность сделать фичи действительно полезными
😁43👍26🤩4👎2🔥2
Если вам нужны Server Actions в vike.dev или другом серверном фреймворке, то рекомендую обратить внимание на telefunc.com
Конечно, не стоит прям писать запросы к бд в экшенах на SQL.
Есть более очевидный кейс, когда серверные экшены идеально подходят — обращение к внешним сервисам по API.
Если мы не хотим, чтобы в бандл попадал API Key, и чтобы этот ключ отображался во вкладке Network, то есть пользователь его вообще не мог увидеть.
Telefunc позволяет превратить обращение к файлу
При этом, если писать на typescript, типы описывающие функцию будут автоматически превращены в рантайм валидацию, то есть устранена дырища серверных экшенов в next.js
Проект от создателя vike.dev, то есть вы можете рассчитывать на хороший API и расширяемость. Автор при этом довольно активно рассматривает новые варианты использования, просто посмотрите issues (закрытые тоже).
А вот в issue по ссылке ниже, вы можете увидеть как я использую vike с effector (ну немного), а также подписаться на обновления.
https://github.com/brillout/telefunc/issues/109
Конечно, не стоит прям писать запросы к бд в экшенах на SQL.
Есть более очевидный кейс, когда серверные экшены идеально подходят — обращение к внешним сервисам по API.
Если мы не хотим, чтобы в бандл попадал API Key, и чтобы этот ключ отображался во вкладке Network, то есть пользователь его вообще не мог увидеть.
Telefunc позволяет превратить обращение к файлу
.telefunc.ts в fetch() запрос в клиентском бандле.При этом, если писать на typescript, типы описывающие функцию будут автоматически превращены в рантайм валидацию, то есть устранена дырища серверных экшенов в next.js
Проект от создателя vike.dev, то есть вы можете рассчитывать на хороший API и расширяемость. Автор при этом довольно активно рассматривает новые варианты использования, просто посмотрите issues (закрытые тоже).
А вот в issue по ссылке ниже, вы можете увидеть как я использую vike с effector (ну немного), а также подписаться на обновления.
https://github.com/brillout/telefunc/issues/109
👍19🔥2❤1