Forwarded from 🦉
В вашем проекте есть monorepo? Может быть вы вынуждены разделять свой код на пакеты, потому что поддерживаете сразу несколько платформ?
Anonymous Poll
46%
Да, у меня yarn workspaces или lerna, или другой способ организации
41%
Нет
13%
Не знаю
Сова пишет…
Attribute-Based Access Control А мы тут изобретаем ABAC, для передачи с сервера на клиент и двусторонней валидации данных. Почему не готовое решение? Большинство готовых решений монструозны и реализованы на XML. Нам требуется простая, но в то же время мощная…
Уже несколько недель думаю как назвать библиотеку для проверки прав в стиле ABAC.
Все самые интересные названия заняты, вот какое-то мучение. Сейчас пришла в голову идея: npmjs.com/can-you
Достаточно хорошо описывает цель: проверка прав?
Все самые интересные названия заняты, вот какое-то мучение. Сейчас пришла в голову идея: npmjs.com/can-you
Достаточно хорошо описывает цель: проверка прав?
Как я именую всё в приложении.
Когда читаю код, я хочу понимать намерения автора, что он хотел выразить кодом.
Если я вижу функцию employeeStatusChange, я хочу четко понимать её назначение “сменить статус сотрудника” или же “узнать в каком состоянии находится процесс изменения сотрудника”.
Если коротко, то использую подход:
Namespace + HighContext + LowContext + Action
Примеры выше можно показать так (namespace отсутствует):
employeeStatusChange
employee — high context, в контексте чего выполняется действие
status — low context, нечто принадлежащее родительскому контексту
change — action, что делаем с этим
То есть изменяем статус сотрудника.
А вот пример с выяснением текущего статуса процесса изменения сотрудника, может выглядеть так employeeChangeStatus:
employee — high context, всё так же работаем с сотрудником
change — low context, но здесь уже указываем что работаем с сущностью change принадлежащей сотруднику
status — action, выступает как глагол
Таким образом, можно четко обозначить назначение функции, не добавляя дополнительных слов. Получается коротко и понятно, при условии, что конвенцию понимают все в команде.
А вот как быть БЕЗ конвенции? Как отличить эти функции не превращая имя в месиво вроде readStatusOfEmployeeChanging, которое не отсортировать по имени, потому что тогда сгруппируются все функции начинающиеся с read*, вместо группирования по сущности employee.
P.S.
Если переложить этот подход на точечную нотацию, получится вполне себе вменяемая объектная модель:
employeeChangeStatus -> employee.change.status()
А вот readStatusOfEmployeeChanging уже не перекладывается без полной смены порядка слов, что не очень приятно. Ну и важные слова employee и change теряются в середине и конце названия.
Когда читаю код, я хочу понимать намерения автора, что он хотел выразить кодом.
Если я вижу функцию employeeStatusChange, я хочу четко понимать её назначение “сменить статус сотрудника” или же “узнать в каком состоянии находится процесс изменения сотрудника”.
Если коротко, то использую подход:
Namespace + HighContext + LowContext + Action
Примеры выше можно показать так (namespace отсутствует):
employeeStatusChange
employee — high context, в контексте чего выполняется действие
status — low context, нечто принадлежащее родительскому контексту
change — action, что делаем с этим
То есть изменяем статус сотрудника.
А вот пример с выяснением текущего статуса процесса изменения сотрудника, может выглядеть так employeeChangeStatus:
employee — high context, всё так же работаем с сотрудником
change — low context, но здесь уже указываем что работаем с сущностью change принадлежащей сотруднику
status — action, выступает как глагол
Таким образом, можно четко обозначить назначение функции, не добавляя дополнительных слов. Получается коротко и понятно, при условии, что конвенцию понимают все в команде.
А вот как быть БЕЗ конвенции? Как отличить эти функции не превращая имя в месиво вроде readStatusOfEmployeeChanging, которое не отсортировать по имени, потому что тогда сгруппируются все функции начинающиеся с read*, вместо группирования по сущности employee.
P.S.
Если переложить этот подход на точечную нотацию, получится вполне себе вменяемая объектная модель:
employeeChangeStatus -> employee.change.status()
А вот readStatusOfEmployeeChanging уже не перекладывается без полной смены порядка слов, что не очень приятно. Ну и важные слова employee и change теряются в середине и конце названия.
Буквально на днях записал коротенький выпуск «Под куполом» про компоненты-монстры во время проектирования ui-lib.
https://anchor.fm/under-a-dome/episodes/--er9ulu
https://podcasts.apple.com/ru/podcast/%D0%BF%D0%BE%D0%B4-%D0%BA%D1%83%D0%BF%D0%BE%D0%BB%D0%BE%D0%BC/id1553479345?l=en&i=1000514308069
https://music.yandex.com/album/13932760/track/79817578
https://anchor.fm/under-a-dome/episodes/--er9ulu
https://podcasts.apple.com/ru/podcast/%D0%BF%D0%BE%D0%B4-%D0%BA%D1%83%D0%BF%D0%BE%D0%BB%D0%BE%D0%BC/id1553479345?l=en&i=1000514308069
https://music.yandex.com/album/13932760/track/79817578
Spotify for Podcasters
Компоненты-монстры by Под куполом
Как перестать создавать огромные компоненты и не пытаться дробить их на слишком маленькие части.
Комментарии
Комментарии
У нас тут спор!
Что значит слово tier по вашему мнению? Не гуглить, чисто отсебятину накидайте.
Что значит слово tier по вашему мнению? Не гуглить, чисто отсебятину накидайте.
Forwarded from Effector news (Сергей Сова)
YouTube
effector meetup 2
Ссылка на чат в Телеграм:
https://t.me/joinchat/NM5fCJRw5Cw0YjYy
В современной frontend-разработке мы сталкиваемся с задачами уменьшения зависимостей между модулями и наглядного описания их внутренних и внешних связей, желая снизить количество ошибок и упростить…
https://t.me/joinchat/NM5fCJRw5Cw0YjYy
В современной frontend-разработке мы сталкиваемся с задачами уменьшения зависимостей между модулями и наглядного описания их внутренних и внешних связей, желая снизить количество ошибок и упростить…
Давненько не проводили TalkStream.
Вот всё, что было https://www.youtube.com/playlist?list=PLRXfqpDVC48YBxB71dx1YRKixd1_6AjmV
Интересен такой формат, стоит продолжать?
Вот всё, что было https://www.youtube.com/playlist?list=PLRXfqpDVC48YBxB71dx1YRKixd1_6AjmV
Интересен такой формат, стоит продолжать?
YouTube
TalkStream - YouTube
Forwarded from Kitekat
Сова пишет…
Сейчас реализовал наивную версию match для effector/reflect. Метод выбирает компонент из cases соответствующий значению в сторе source, во время рендера привязывает сторы и ивенты к нему. Оказалось, что похожим образом можно реализовать декларативную замену…
О! JWT should not be your default for sessions
Отправьте в реакт чат, может перестанут новичкам советовать
https://evertpot.com/jwt-is-a-bad-default/
Отправьте в реакт чат, может перестанут новичкам советовать
https://evertpot.com/jwt-is-a-bad-default/
Evertpot
JWT should not be your default for sessions
Forwarded from 🍰 Feature-Sliced Design (core-team)
Всем привет!
Прошло достаточно много времени, но теперь мы готовы представить вам v2.0-beta версию методологии!
Мы постарались изложить здесь:
- Get-started материалы
- Фундаментальные концепции
- Гайды и примеры по применению (включая миграцию с v1)
- Справочный материал по абстракциям
- Общее видение дальнейшего развития методологии
Материал копился и обсуждался достаточно долго, поэтому нам очень важно получить от вас фидбек по текущей версии!
- Можете делиться впечатлениями и замечаниями здесь в чате, в ишьюсах или в дискуссиях (или даже в пулл-реквестах)
- Сейчас для нас крайне важно собрать максимум ваших пожеланий, кейсов, реальных проблем с практики - чтобы обработать их со стороны методологии
- Работа над методологией еще в процессе, многое может поменяться, но фундамент под полноценный релиз v2 - кладется именно сейчас (потому нам так важен объемный и содержательный фидбек)
https://feature-sliced.design/
🍰 Release Notes
Прошло достаточно много времени, но теперь мы готовы представить вам v2.0-beta версию методологии!
Мы постарались изложить здесь:
- Get-started материалы
- Фундаментальные концепции
- Гайды и примеры по применению (включая миграцию с v1)
- Справочный материал по абстракциям
- Общее видение дальнейшего развития методологии
Материал копился и обсуждался достаточно долго, поэтому нам очень важно получить от вас фидбек по текущей версии!
- Можете делиться впечатлениями и замечаниями здесь в чате, в ишьюсах или в дискуссиях (или даже в пулл-реквестах)
- Сейчас для нас крайне важно собрать максимум ваших пожеланий, кейсов, реальных проблем с практики - чтобы обработать их со стороны методологии
- Работа над методологией еще в процессе, многое может поменяться, но фундамент под полноценный релиз v2 - кладется именно сейчас (потому нам так важен объемный и содержательный фидбек)
https://feature-sliced.design/
🍰 Release Notes
Мы делаем очень сложные системы, но далеко не всегда можем даже представить насколько сложными они являются на самом деле, из-за этого не прорабатываем свои интерфейсы достаточно хорошо.
Есть разные экраны: мобильные, планшеты, ноутбуки, десктопы
Разные приложения требуют разной плотности информации и интерфейсов
Плюс есть люди с нарушениями зрения, им требуется более крупный интерфейс.
А значит нам нужна регулировка размерности компонентов, изменение размеров шрифтов и отступов, чтобы настроить как размер шрифта для более крупного текста, так и увеличить плотность интерфейса, чтобы уместить больше элементов на экране.
Есть разные цвета: есть просто компоненты и группы, они могут быть разных вариантов, primary, secondary, tertiary. Эти компоненты могут располагаться на разных поверхностях: default, primary, secondary, а значит нельзя оставлять цвета компонентов как есть, в нужно красить специально под цвет фона. Помимо этого есть дневная и ночная тема, компоненты тоже должны быть перекрашены, а если есть изменённый фон и компоненты на нем, то их также нужно перекрасить в ночной теме, чтобы яркий белый цвет не бил по глазам.
Каждый вариант содержит 16 цветов, у нас есть 3 варианта компонентов, три цвета фонов и два оформления, ночное и дневное, получается 18 разных вариантов и 288 цветов всего. А люди с нарушениям зрения будут лучше себя чувствовать если создать для них отдельное оформление, а ещё лучше по одному на каждый тип нарушения цветового зрения.
Нам нужно создать систему компонентов, где каждый компонент может быть отрисован в разных размерах отступов и шрифтов, а также в разных цветах, чтобы увеличить визуальный вес, его можно расположить на поверхностях разных цветов, чтобы создать акцент на группе компонентов сразу, а также переключить в темную или светлую тему… ах, да цвета всех компонентов в системе не предустановленны заранее и могут быть изменены, хоть по желанию пользователя.
Если коротко о том, как будет работать Woly UI.
Есть идеи как реализовать такую систему?
Есть разные экраны: мобильные, планшеты, ноутбуки, десктопы
Разные приложения требуют разной плотности информации и интерфейсов
Плюс есть люди с нарушениями зрения, им требуется более крупный интерфейс.
А значит нам нужна регулировка размерности компонентов, изменение размеров шрифтов и отступов, чтобы настроить как размер шрифта для более крупного текста, так и увеличить плотность интерфейса, чтобы уместить больше элементов на экране.
Есть разные цвета: есть просто компоненты и группы, они могут быть разных вариантов, primary, secondary, tertiary. Эти компоненты могут располагаться на разных поверхностях: default, primary, secondary, а значит нельзя оставлять цвета компонентов как есть, в нужно красить специально под цвет фона. Помимо этого есть дневная и ночная тема, компоненты тоже должны быть перекрашены, а если есть изменённый фон и компоненты на нем, то их также нужно перекрасить в ночной теме, чтобы яркий белый цвет не бил по глазам.
Каждый вариант содержит 16 цветов, у нас есть 3 варианта компонентов, три цвета фонов и два оформления, ночное и дневное, получается 18 разных вариантов и 288 цветов всего. А люди с нарушениям зрения будут лучше себя чувствовать если создать для них отдельное оформление, а ещё лучше по одному на каждый тип нарушения цветового зрения.
Нам нужно создать систему компонентов, где каждый компонент может быть отрисован в разных размерах отступов и шрифтов, а также в разных цветах, чтобы увеличить визуальный вес, его можно расположить на поверхностях разных цветов, чтобы создать акцент на группе компонентов сразу, а также переключить в темную или светлую тему… ах, да цвета всех компонентов в системе не предустановленны заранее и могут быть изменены, хоть по желанию пользователя.
Если коротко о том, как будет работать Woly UI.
Есть идеи как реализовать такую систему?
Хочу возобновить Howtocards/Cardbox в виде стартапа со всеми вытекающими.
Кто хочет присоединиться? Ищу участников, разработчиков rust/ts, девопса в команду в парт-тайм
Кто хочет присоединиться? Ищу участников, разработчиков rust/ts, девопса в команду в парт-тайм
Сова пишет…
Хочу возобновить Howtocards/Cardbox в виде стартапа со всеми вытекающими. Кто хочет присоединиться? Ищу участников, разработчиков rust/ts, девопса в команду в парт-тайм
Почему не Notion:
1. Он платный, в бесплатном ограничение в 1000 блоков.
2. Он персональный. В мою страницу не может отправить комментарий другой человек
3. Нет структурной системы комментариев. Хорошую структуру предложил гитхаб в своих Discussions.
4. Нет поиска по всем страницам всех пользователей в сервисе.
5. Нет четких рекомендаций как писать страницы так, чтобы они были полезны для других пользователей.
6. Нет персональной личной коллекции сохранённых страниц с гарантиями не удаления данных.
7. Нет системы рейтинга страниц.
8. Нет системы рекомендации полезных или подходящих страниц.
9. Я не могу отправить другому пользователю предложения по изменению его страницы.
10. В редакторе страниц нет вставки playground/repl разных языков программирования. Нельзя в страницу вставить другую страницу инлайн.
1. Он платный, в бесплатном ограничение в 1000 блоков.
2. Он персональный. В мою страницу не может отправить комментарий другой человек
3. Нет структурной системы комментариев. Хорошую структуру предложил гитхаб в своих Discussions.
4. Нет поиска по всем страницам всех пользователей в сервисе.
5. Нет четких рекомендаций как писать страницы так, чтобы они были полезны для других пользователей.
6. Нет персональной личной коллекции сохранённых страниц с гарантиями не удаления данных.
7. Нет системы рейтинга страниц.
8. Нет системы рекомендации полезных или подходящих страниц.
9. Я не могу отправить другому пользователю предложения по изменению его страницы.
10. В редакторе страниц нет вставки playground/repl разных языков программирования. Нельзя в страницу вставить другую страницу инлайн.