Сова пишет…
2.99K subscribers
375 photos
38 videos
5 files
444 links
Download Telegram
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
👍28🔥12🙈7😐3👎2😁1
Вы можете подписаться на мои списки застаренных репозиториев на гитхабе.
https://github.com/sergeysova

Я регулярно нахожу новые инструменты и добавляю их в списки.

Когда нахожу силы и время, то собираю статьи и репозитории в виде рассылки.
https://news.sova.dev/

Скоро будет новый сезон подборок статей. Обычно я выкладываю их также здесь в Telegram для удобства.
👍18👎10🔥4🤔3😁2❤1
Я уже очень давно не видел, чтобы кто-то верстал интерфейсы на таблицах…
🗿17👍9🤯6🤔2❤1
Ещё один проект в Google Graveyard.

Когда они уже gmail убьют, чтобы Гуглом никто не пользовался?
😢12
Всем привет!
27 мая буду участвовать в круглом столе на конференции Podlodka React Crew. Вместе с Максимом Вишневским и Сергеем Самоховым обсудим архитектуру React-приложений, организацию компонентов и данных, React Compiler, реактивность в React и многое другое.

Также будут выступления по Feature-Sliced Design, миграции проектов и выбору стейт-менеджера.Для моих подписчиков промокод на билеты: react_crew_1_PHXAp9.
🔥20👍7❤3😁2🤩1🙈1
Мне позвонил браузер! В каком мире мы вообще живем
😁31👍3😱3
Я уже не первый раз читаю в группах, что ChatGPT довольно тупой и ничего не умеет, даже 4o модель.

Хочу с этим поспорить, пусть до 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 может выглядеть вот так:

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
21👎8🙈1
Forwarded from © Как его там… (Dmitry Remezov)
🚦Роутинг

Или как мы топчемся на месте.

Современная веб разработка приучила нас к тому, что "роут" - компонент на какому-то пути.
Все популярные решения (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
Если вы присутствовали на круглом столе, напишите свой отзыв, пожалуйста.

Ну и здесь можно продолжить дискуссию, написать свои вопросы/комментарии/мнение.

А ещё, если есть желание увидеться со спикерами.
Я в ближайшее время в Армении.
👎16👍12❤5🤩5🤬3
Вместо Next.js я использую vike.dev для SSR проектов.

Один из громадных плюсов это глубокая кастомизация (при необходимости), а также удобства для разработчика.

Столкнулся с проблемой: при клиентских переходах не запускается логика 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, если можно всё описать через 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

В комментариях я напишу еще детали…
🤬451👍32🔥139👎76
Мне нравится, что декларативный подход effector не так сильно раздувает API, которое необходимо, чтобы писать приложения практически любой сложности.

P.S.
Справедливости ради, сюда вполне можно докинуть patronum, atomic-router, farfetched, effector-*, и это всё будет раздувать необходимое для работы API.

Насколько мне известно, такая же ситуация обстоит и с другими стейт-менеджерами, поэтому приводить её не стал.
Решить проблему конечно можно, так как образовалась пачка устойчивых регулярных пакетов, можно сделать мета-пакет типа npm install framework-react, внутрь которого засунуть все необходимые обычно пакеты.
👎66👍21❤5🤔4🔥3🗿1
SpaceX приводнили свой огромный корабль.

За 4 запуска им удалось достичь настолько амбициозной цели.
Я все это к чему, мы наглядно видим, как огромный проект разрабатывается итеративно.

Обязательно запускайте свои проекты на ранних стадиях, не ждите пока будут готовы все фичи.
Именно такие запуски дают возможность сделать фичи действительно полезными
😁43👍26🤩4👎2🔥2
Если вам нужны Server Actions в vike.dev или другом серверном фреймворке, то рекомендую обратить внимание на telefunc.com

Конечно, не стоит прям писать запросы к бд в экшенах на 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