Forwarded from Steam Community
💢 Фанатский ремастер S.T.A.L.K.E.R.: Shadow of Chernobyl, который делают с 2010 года, почти готов — выпустят 25 декабря
💩17🔥5😁3👍2
Разработка библиотеки компонентов
Чем больше я смотрю на возможные паттерны при разработке библиотек компонентов, тем больше мне нравится styled/emotion/stitches.
Если брать чистый css, то при большом размере библиотеки компонентов, придется импортировать весь css или специальным образом настраивать сборщик, чтобы импорты css работали внутри node_modules.
Примерно так же выглядят проблемы с tailwindcss/windicss, либо бандлить все стили в библиотеку, либо натравливать конфиг тайлвинда на node_modules, чтобы тот смог извлекать классы из className в компонентах.
С CSS-in-JS все выглядит ГОРАЗДО проще и как-то более предсказуемо. Да, есть просадка в производительности и кешировании, но даже для SSR есть крайне простой в использовании Critical CSS и куча других ухищрений. Разработка библиотеки компонентов становится довольно простым и приятным занятием. Посмотреть на тот же mantine.dev, который построен поверх emotion.
У меня в бэклоге лежит проект CSS-in-JS с компиляцией и префиксированием CSS во время сборки, чтобы не тащить в рантайм парсер и компилятор CSS. Остается только инжектор уже скомпилированных стилей в <head> и удобный интерфейс для компонентов.
Когда бы это сделать… особенно если библиотека компонентов нужна вчера.
Чем больше я смотрю на возможные паттерны при разработке библиотек компонентов, тем больше мне нравится styled/emotion/stitches.
Если брать чистый css, то при большом размере библиотеки компонентов, придется импортировать весь css или специальным образом настраивать сборщик, чтобы импорты css работали внутри node_modules.
Примерно так же выглядят проблемы с tailwindcss/windicss, либо бандлить все стили в библиотеку, либо натравливать конфиг тайлвинда на node_modules, чтобы тот смог извлекать классы из className в компонентах.
С CSS-in-JS все выглядит ГОРАЗДО проще и как-то более предсказуемо. Да, есть просадка в производительности и кешировании, но даже для SSR есть крайне простой в использовании Critical CSS и куча других ухищрений. Разработка библиотеки компонентов становится довольно простым и приятным занятием. Посмотреть на тот же mantine.dev, который построен поверх emotion.
У меня в бэклоге лежит проект CSS-in-JS с компиляцией и префиксированием CSS во время сборки, чтобы не тащить в рантайм парсер и компилятор CSS. Остается только инжектор уже скомпилированных стилей в <head> и удобный интерфейс для компонентов.
Когда бы это сделать… особенно если библиотека компонентов нужна вчера.
🔥10💩8👍2
На бывшей главной странице yandex.ru одна из главных новостей:
дизайнер представил две версии интерьера новой "Буханки"
Во первых, работа дизайнера никак не связан с производителем УАЗ.
Во вторых, он выполняет её "по фану", но новость каким-то образом попала на главную этого "новостного ресурса"
У парня 286 подписчиков в телеграме. Как они вообще нашли его??
Я знаю, что это немного не в тему канала (а какая у него вообще тема?), но это ж просто жесть, адекватных новостных сервисов просто не осталось в РФ.
дизайнер представил две версии интерьера новой "Буханки"
Во первых, работа дизайнера никак не связан с производителем УАЗ.
Во вторых, он выполняет её "по фану", но новость каким-то образом попала на главную этого "новостного ресурса"
У парня 286 подписчиков в телеграме. Как они вообще нашли его??
Я знаю, что это немного не в тему канала (а какая у него вообще тема?), но это ж просто жесть, адекватных новостных сервисов просто не осталось в РФ.
😁6❤3👍2👎2💩1
Я уже не первый раз слышу, что подписчики жалуются, что подкаст "Под куполом" не доступен в РФ.
Я сейчас перенес подкаст на другую платформу.
Попробуйте воспроизвести без VPN!
https://podcast.sova.dev/
Я сейчас перенес подкаст на другую платформу.
Попробуйте воспроизвести без VPN!
https://podcast.sova.dev/
Под куполом
Сугубо субъективный взгляд на вещи в формате ночных посиделок
👍5🥱3❤1
К сожалению, подкаст "Сова говорит…" не выпускался уже несколько лет и вряд ли будет продолжаться
Но все выпуски можно послушать на soundcloud
https://soundcloud.com/sergeysova
Но все выпуски можно послушать на soundcloud
https://soundcloud.com/sergeysova
💔8🤔2❤1🤡1
Нашел весьма полезные правила для онлайн общения в социуме.
Далеко не со всеми людьми хочется вести хоть какое-то общение, тупо из-за того, что им просто плевать на тебя.
https://www.recurse.com/social-rules
Далеко не со всеми людьми хочется вести хоть какое-то общение, тупо из-за того, что им просто плевать на тебя.
https://www.recurse.com/social-rules
Recurse Center
Social rules - Recurse Center
The RC social rules help create a friendly, intellectual environment where you can spend your energy on programming.
👍4💩3🔥2
Зачем нужны паттерны проектирования
На собеседованиях их довольно часто спрашивают, очень часто применяют в ООП-like Java/C#/C++, конечно же функциональные паттерны, но действительно ли от них много толка в реальной имплементации задач бизнеса?
Когда читаю о паттернах вижу в основном две цели: готовое решение задачи и общий язык для коммуникации с коллегами. Это, конечно же, крайне важные причины выбирать готовые паттерны, а не городить новые.
Я хочу описать еще одну крайне важную причину. Возможно, эта причина важнее всех остальных, хотя знатоки в подписчиках придут и поправят меня в комментариях, если я не прав.
Основная причина использования паттернов, да и создания их — отсутствие необходимости менять существующий код. На первый взгляд кажется, что это фигня: ну что такого, ну поменяю я этот метод или функцию, все же так делают.
Но ведь в надежных системах, люди пишут юнит-тесты и полагаются на то, как работает функциональность. Изменяя существующий код, мы скорее всего хотим поменять его поведение, а значит хотим сломать ожидания коллег от работы этого кода.
Все паттерны проектирования, на мой взгляд, пытаются решить эту задачу — как добавить новую функциональность в приложение, не меняя уже написанный код. Зачем менять существующий код, если мы хотим добавить новый код?
Звучит конечно логично, но на практике достичь этого идеала не получается. Java превратила эту идею в догму, поэтому мы зачастую видим
Если говорить про языки, которые мне гораздо ближе — TypeScript и Rust, то это мультипарадигменные языки во всей своей красе, а значит, можно смешивать кучу различных паттернов для достижения той же самой цели — как добавить новый код не изменяя существующий.
Когда получается удачно задизайнить архитектуру системы, при которой добавление новой функциональности не требует модификации существующего кода, не падают тесты, не нужно перепроверять вручную всю систему целиком, просто убеждаемся, что интеграция нового кода прошла удачно.
Любые правила вводимые в проекте, в том числе с effector, нужны как раз для того, чтобы добавление нового кода снизило количество модификаций существующего. Если вы хотите добавить в команду новое правило и оно кажется важным, попробуйте убедиться, что это правило действительно помогает уменьшить количество изменений в коде. Если нет, возможно, оно и не такое уж важное.
На собеседованиях их довольно часто спрашивают, очень часто применяют в ООП-like Java/C#/C++, конечно же функциональные паттерны, но действительно ли от них много толка в реальной имплементации задач бизнеса?
Когда читаю о паттернах вижу в основном две цели: готовое решение задачи и общий язык для коммуникации с коллегами. Это, конечно же, крайне важные причины выбирать готовые паттерны, а не городить новые.
Я хочу описать еще одну крайне важную причину. Возможно, эта причина важнее всех остальных, хотя знатоки в подписчиках придут и поправят меня в комментариях, если я не прав.
Основная причина использования паттернов, да и создания их — отсутствие необходимости менять существующий код. На первый взгляд кажется, что это фигня: ну что такого, ну поменяю я этот метод или функцию, все же так делают.
Но ведь в надежных системах, люди пишут юнит-тесты и полагаются на то, как работает функциональность. Изменяя существующий код, мы скорее всего хотим поменять его поведение, а значит хотим сломать ожидания коллег от работы этого кода.
Все паттерны проектирования, на мой взгляд, пытаются решить эту задачу — как добавить новую функциональность в приложение, не меняя уже написанный код. Зачем менять существующий код, если мы хотим добавить новый код?
Звучит конечно логично, но на практике достичь этого идеала не получается. Java превратила эту идею в догму, поэтому мы зачастую видим
AbstractFactoryBuilderAdapter. Разумеется, он решает свою задачу, но теперь он крайне далеко от предметной области, которую мы собственно пытаемся моделировать.Если говорить про языки, которые мне гораздо ближе — TypeScript и Rust, то это мультипарадигменные языки во всей своей красе, а значит, можно смешивать кучу различных паттернов для достижения той же самой цели — как добавить новый код не изменяя существующий.
Когда получается удачно задизайнить архитектуру системы, при которой добавление новой функциональности не требует модификации существующего кода, не падают тесты, не нужно перепроверять вручную всю систему целиком, просто убеждаемся, что интеграция нового кода прошла удачно.
Любые правила вводимые в проекте, в том числе с effector, нужны как раз для того, чтобы добавление нового кода снизило количество модификаций существующего. Если вы хотите добавить в команду новое правило и оно кажется важным, попробуйте убедиться, что это правило действительно помогает уменьшить количество изменений в коде. Если нет, возможно, оно и не такое уж важное.
👍25❤5
Новый эпизод подкаста "Под куполом"
Архитектура и Feature Sliced
Зачем вообще использовать паттерны проектирования? Почему FSD не является архитектурой сама по себе? Почему я консультирую именно в экосистеме effector? Как научиться писать код?
Подписывайтесь на Youtube:
youtube.com/@sova
Выпуск можно послушать: Google, Yandex, Spotify, Apple.
https://podcast.sova.dev/episodes/feature-sliced-and-architecture-patterns
Архитектура и Feature Sliced
Зачем вообще использовать паттерны проектирования? Почему FSD не является архитектурой сама по себе? Почему я консультирую именно в экосистеме effector? Как научиться писать код?
Подписывайтесь на Youtube:
youtube.com/@sova
Выпуск можно послушать: Google, Yandex, Spotify, Apple.
https://podcast.sova.dev/episodes/feature-sliced-and-architecture-patterns
❤19⚡1
Причина по которой effector плавно переходит к sample для любых задач.
Даже
Если бы я описал код выше через
А так, в diff увижу изменения только одной строки.
Приятного вечера 🧡
Даже
$store.on() это далеко не самый удобный способ описывать бизнес-логику в коде.Если бы я описал код выше через
$store.on(), то в момент, когда мне понадобилось бы добавить условие, пришлось бы полностью заменить блок .on() на sample.А так, в diff увижу изменения только одной строки.
Приятного вечера 🧡
👍24🤔2😭2