Еще пост о FeatureSlices


https://www.instagram.com/p/CBbOfaqKbFJ/?igshid=ds34n0o5agw8

Пользуюсь группами вкладок в Chrome с их появления под флагом и не могу нарадоваться удобству. У меня в каждом пользователе браузера открыто 20+ вкладок и я регулярно их перечитываю. Но без вкладок я постоянно забываю о том, что у меня открыто.

Следующий пост про FeatureSlices

https://www.instagram.com/p/CBqWdzuKHyK/?igshid=1e3z6vpsmxgq9

Отображение процессов браузера от ввода URL до финального рендера в виде MindMap

https://kinopio.club/the-browser-when-you-click-a-link-JFYdfq5YKvM1f9A9K3XcI

Аналогичное отображение, но для CSS

https://kinopio.club/css-in-the-browser-JMEzxdApT8kvcBW3g_b3Z

eSIM в России оказывается уже работает!)

Как я именую функции, классы, компоненты, ивенты, сторы.

Так как большую часть времени мы читаем код, а не пишем его, то хочется легко воспринимать существуюшие части кода. Стоит помнить, что мы далеко не всегда пишем полностью новый код. В существующем проекте мы используем уже созданные ранее переменные, сущности и модули.

Во всех IDE есть функция автоимпорта сущности по имени. Многие ею успешно пользуются, в том числе и я. Да даже без этой функции совет из этого поста актуален. Ведь зачастую импортнув сущность однажды она используется больше одного раза в модуле.

А ещё есть такая штука как автодополнение ввода. Давайте разберемся как оно работает: пишем какие-то буквы, IDE анализирует контекст и ищет сущности по входящим в него символам. Притом, введенные символы должны идти в названии сущности ровно в том же порядке в каком были введены.

Например: введено "rsp", будет найдено "responseType", но не "scopeDescription".

А если сложить всё вместе, можно заметить интересный паттерн. Неважно, в какой парадигме ведется разработка, всегда есть некий объект и методы.
В ФП это будет method(object, arg)
в ООП-like object.iss.onethod(arg)
И мы как разработчики всегда знаем, с каким объектом работаем в данный момент, но не всегда знаем какие методы есть у него. Поэтому для нас важнее объект, ведь можно ввести имя объекта и IDE предложит, что с ним можно сделать. В ФП это может работать через pipe/compose или оператор |>. А может быть через ковенцию objectAction. И тогда всё будет работать ровно как в ООП-like objectAction(object, arg), не нужно бояться дублирования object здесь, ведь переменная почти никогда не называется по имени сущности.

Зачастую большое количество используемых методов удобно импортировать в область имен:
import * as namespace from "...".
Тогда формат вызова превращается в namespaceObjectAction(object, arg).

На самом деле компоненты проектируется ровно также как методы в ООП или ФП — выполняют только одну четко определенную задачу. А значит, вполне могут быть именованы в похожем формате. Только action превратится в variant, ведь компоненты сами по себе не выполняют действий, они могут быть разных вариантов отображения.

Примеры: Button, ButtonPrimary, Input, InputMask, InputPassword. Это всё описано в формате ObjectVariant. Если добавить namespace, то получится такое: Form, FormField, FormFieldPrimary, или же Form.Field тут уж как удобнее.

Ровно та же схема работает и с классами. Достаточно почитать книги с примерами по джаве. То же самое с методами и функциями. Внезапно, это работает с именами переменных и констант. При этом введя namespace в IDE, можно увидеть все входящие объекты, дописав или выбрав нужный объект namespaceObject, можно увидеть всего варианты и/или действия.

Главный принцип — от общего к частному.

Ну что.
Неделя началась — https://twitter.com/jsunderhood/status/1277501157447958534

Накидывайте свои вопросы или ещё что, буду отвечать

Все треды из jsunderhood про архитектуру и FeatureSlices перенес в канал по теме:
https://t.iss.one/feature_slices/50

Тред по ☄️ Effector:
https://twitter.com/jsunderhood/status/1279412432000241664

Там начался опрос State of Frontend. Он не совсем корректно собран. Но крайне рекомендую всем указать Effector в разделе про STM. Чтобы он появился в результатах и люди увидели новинку.

https://tsh.io/state-of-frontend/

Тем временем Hexlet опубликовали статью про React и мнение “экспертов” о нём и его будущем.

Я есть в списке “экспертов”. Надеюсь получилось привлечь внимание к Effector.

https://ru.hexlet.io/blog/posts/biblioteka-react-review-article

НА ПОЛНОМ СЕРЬЕЗЕ?

IP адрес чтобы узнать в какой компании?

https://www.npmjs.com/package/@scarf/scarf

Этот пакет уже используется в redux-form, с 370К загрузок в неделю

Все чаще замечаю, что мне нехватает времени, поскольку в роботах много работы с командой и новыми проектами, а по утрам занимаюсь cardbox и допиливаю accesso. На конец августа я запланировал релиз patronum, осталось покрыть все методы тестами и документацией. Очень много времени трачу в чатах, отвечая на вопросы по методологии FeatureSlices и AtomicDesign, которые необходимо превратить в статьи и инструменты.

Инструмент отладки effector-logger требует обновления на новую версию, пользователи занесли крутые предложения в issues, а ещё я задумал в inspector добавить крутую отладку состояния сторов в realtime. В закромах лежит интересный прототип DI для Effector, который я периодически мучаю, чтобы получить удобный DX. Для меня это крайне важный поинт, мало какие инструменты пытаются быть действительно удобными для разработчиков.

Я написал продолжение подкаста, но пока только текст, мне осталось его записать и смонтировать. Я видел, что есть люди, которым было бы интересно не только продолжение темы про продуктовую разработку, но и тема про хуки и классы реакта. Помимо этого, я работаю над actix-swagger, генератором rust-кода из openapi3. Я хочу генерировать код, а не схему из кода, с одной стороны это проще в техническом плане, но возникает сложность интеграции сгенерированного кода и бизнес-логики, даже решив эту проблему, я должен озаботиться DX получившегося решения.

Я думаю ни для кого не секрет, что количество доступных знаний и правильных подходов разработки фронтенда на подозрительно низком уровне, поэтому я пишу план нескольких курсов по разработке, куда войдет курс по базовым и advanced навыкам git, командной работе над React-приложениям, FeatureSlices на практике и проектированием приложений с Effector.

Я хочу выпустить всё это, но вообще не понимаю, что выпускать первым и что нужно людям, а ещё не хватает мотивации. Мне нужна помощь с определением приоритетов, но очевидно, что голосование в опросе нерепрезентативно. Любой из подписчиков может выбрать что угодно, не задумываясь о полезности. Я хочу сделать для вас то, что действительно нужно, притом, в первую очередь самое необходимое.

Мы, разработчики или айтишники, зарабатываем деньги в первую очередь своими знаниями и техническими навыками, инструментарий помогает нам снять головную боль и рутину, оставив время заниматься действительно интересными и важными вещами. Статьи и гайды помогают взглянуть на привычные вещи глубже, посмотреть на них с новой стороны, а также передать знания младшим коллегам быстрее и проще, а кому-то статьи просто помогают держаться выбранного курса, достаточно регулярно сверяться с текстом.

В любом случае, наши знания и вложенное в них время, приносит нам деньги, кто-то готов покупать курсы, кто-то оплачивает подписки, некоторые вкладывают свое время и деньги в инструментарий, полезный команде, тем самым помогая и многим другим, у которых пока нет средств на такие вложения. Почти всегда эти вложения оправдываются, даже если не сразу очевидно, в какой сфере навык стрельнет.

Поэтому я хочу дать выбор тем, кто понимает, что вложенные средства возвращаются в виде знаний или инструментов, ведь $4 доллара(300₽) это крайне небольшое вложение, кофе в старбаксе, но для меня это сигнал о том, что человек действительно хочет получить статью или инструмент. В первую очередь, это мотивация заниматься определенными инструментами, а некоторые отложить, ведь время не бесконечно. Мне нужна помощь в этом, я не могу выбрать сам — patreon.com/sergeysova

В сообщении напишите то, что нужно вам в первую очередь, количество и размер донатов позволит мне легко приоритизировать задачи и выпустить необходимые статьи и инструменты с лучшим качеством. Спасибо!

Благодаря вашей поддержке, запилил отображение вложенных объектов в effector-inspector. Спасибо!

Помимо обычных объектов, поддерживается Set/Map/Symbol и все стандартные типы. Накидайте, какие объекты в жс хранят не самые обычные данные/структуры данных. И вообще, как отображать WeakMap?

Новые идеи и предложения можно закидывать напрямую в issues — https://github.com/sergeysova/effector-inspector.

Есть идеи как отображать файловую структуру? Эта информация есть в самих сторах, но нужно как-то организовать её, чтобы понятно было. Я думал добавить чекбокс переключающий отображение со списка сторов на дерево файлов со сторами

Продолжаю добавлять поддержку стандартных объектов и типов в effector-logger.

Сейчас добавил BigInt, Function, Array(каким-то образом забыл, что он существует) и ошибок.

Добавил простейшие логи с фильтрацией

И эффекты. Закину релиз с такими возможностями. А всякие дополнительные фичи, буду добавлять уже по необходимости

TverIO продолжает череду онлайн мероприятий. В этот четверг в 19:00 будем говорить о State Management на фронте. Участвуют крутые эксперты, которые помогут раскрыть тему с разных сторон и я).

Присоединяйтесь. https://www.meetup.com/ru-RU/tverio/events/271917823/