Я давно сюда не писал, и если вы всё это время оставались — спасибо вам огромное. Я правда очень это ценю 🫶

В последнее время я старался делиться здесь open-source решениями — тем, что делает жизнь разработчиков чуть проще. Как правило, это были решения реальных проблем, с которыми я сталкивался в работе, чтобы другим не приходилось тратить на них своё время. Иногда — просто небольшие челленджи для себя 🙂

Но регулярно писать только про такие вещи непросто, а делиться хочется чаще.

Поэтому дальше здесь будет немного больше и других постов, связанных с разработкой 👨‍💻

Спасибо, что вы здесь ❤️

I haven’t posted here for a while, and if you’ve stayed all this time — thank you so much. I really appreciate it 🫶

Lately, I’ve been sharing open-source solutions here — things that make developers’ lives a bit easier. Most of them came from real problems I ran into at work, so others wouldn’t have to spend time solving the same things. Sometimes it was just small personal challenges 🙂

But writing only about things like that on a regular basis isn’t easy, and I want to share more often.

So there will be a bit more posts here related to development as well 👨‍💻

Thanks for being here ❤️

Важность дизайн-системы для фронтенда (как для web, так и для мобаила) сложно переоценить.

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

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

Первая — у дизайн-системы часто нет конкретного владельца. Нет человека, который за неё отвечает целиком: принимает решения, держит целостность и понимает, куда она должна развиваться.

Вторая — нет единственного code owner’а. Когда компоненты пишут все понемногу, система быстро превращается в набор разрозненных решений с разной логикой и качеством. Имо дизайн-систему вообще не стоит делать коллективно. По опыту, гораздо лучше, когда её ведут несколько разработчиков (а то и вовсе один, но опытный), которые последовательно и осознанно выстраивают систему, а команда уже использует её и даёт обратную связь.

С точки зрения техники, самая большая проблема — компоненты часто не написаны в нативном стиле.

Приведу пример последнего на SwiftUI:

Вот нативный Toggle:

Toggle(isOn: $isEnabled) {
    Text("Notifications")
}

а вот toggle из одного реального проекта:

DSToggle(
    title: "Notifications",
    value: isEnabled,
    style: .switch,
    enabled: true,
    onValueChanged: { newValue in
        isEnabled = newValue
    }
)

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

Пример действительно классной дизайн-системы (поверьте, я их видел крайне много):

https://orbit.kiwi/components

Реализация на SwiftUI, Compose, React.

The importance of a design system for frontend development — both web and mobile — is hard to overestimate.
There are tons of articles about this 🙂 Everyone talks about its benefits: brand recognition, visual consistency, and development speed.

But in practice, truly well-designed design systems are very rare. And the problems are usually the same.

First, a design system often has no clear owner.
There’s no single person responsible for it end-to-end: making decisions, maintaining consistency, and understanding where the system should evolve.

Second, there is no single code owner.
When everyone contributes a little, the system quickly turns into a collection of fragmented solutions with different logic and quality levels. IMO, a design system shouldn’t really be built collectively. From my experience, it works much better when it’s driven by one or two experienced developers (or even just one), who build it thoughtfully and consistently, while the rest of the team uses it and provides feedback.

From a technical perspective, the biggest issue is that components are often not implemented in a native way.

A simple example in SwiftUI.

A native Toggle:

Toggle(isOn: $isEnabled) {
    Text("Notifications")
}

And here’s a Toggle from a real project:

swift 

DSToggle(
    title: "Notifications",
    value: isEnabled,
    style: .switch,
    enabled: true,
    onValueChanged: { newValue in
        isEnabled = newValue
    }
)

Any design system should strive to preserve native naming, the number and order of parameters, and feel like a natural extension of the framework rather than a separate DSL.

As an example of a truly great design system (trust me, I’ve seen a lot of them):
https://orbit.kiwi/components

Implemented in SwiftUI, Compose, React.

#readthis@swiftui_dev #getsources@swiftui_dev