Что такое кастомизация в программировании

Кастомизация

Кастомизация — это методика адаптации продуктов, предназначенных для массового использования под индивидуальные потребности конкретного покупателя путем изменения товара, например, комплектация дополнительными элементами.

Термин заимствован с английского языка и образован от слов «customise», «customer». Кастомизация означает в буквальном переводе «клиент», «потребитель», «покупатель».

Для чего осуществляется кастомизация?

Свяжите сервисы между собой без программистов за 5 минут!

Подключение ExpertSender

Как настроить выгрузку лидов из Вконтакте в GetCourse?

Результат кастомизации (кастом) представляет собой штучный товар, изготовленный в единственном экземпляре или в небольшом количестве. Кастомизация используется, чтобы дифференцировать предложение, создать уникальные условия для определенной целевой аудитории. Например, привлечь требовательных покупателей, готовых заплатить больше за уникальные характеристики.

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

Настроить интеграцию без программистов ApiX-Drive

Статьи о маркетинге, автоматизации и интеграциях в нашем Блоге

Кастомные свойства

В языках программирования есть переменные: вы что-нибудь один раз объявляете, присваиваете значение, а потом снова и снова используете. Если значение переменной меняется, то оно меняется везде. Похоже на местоимения в языке: из предложения или абзаца всегда понятно, кто «мы» или что за «оно», мы их как будто объявили раньше и наверняка переопределим потом.

Но это языки программирования, а что со стилями? Вообще, декларативная природа CSS не подразумевает никаких переменных и соавтор CSS Берт Бос очень против, почитайте. Но жизнь внесла свои коррективы в изначальную идею, и переменные в стилях появились — слишком уж удобно было. Но сначала в препроцессорах.

Как работают препроцессоры? Вы пишете на каком-то языке, который внешне напоминает CSS, а иногда вообще не напоминает.

@mixin sass @if & &:hover color: tomato @else a color: plum

Потом это компилируется в настоящие стили. Переменные там — это такая сложная автозамена переменных на их значения. Sass, Less, Stylus, PostCSS-плагины — все они работают только так. Эти переменные существуют только в разработке, в браузере их уже нет.

.scss

Если сравнить такое поведение с JavaScript, то становится очень обидно за CSS. В JS переменные живут прямо в браузере, их можно создавать и менять на лету. Тем не менее такие переменные и другие элементы программирования в CSS-препроцессорах получили огромную популярность. Уже почти не бывает больших проектов без препроцессоров.

К счаcтью нашлись люди, недовольные такими куцыми переменными. После ряда черновиков и вариаций синтаксиса, Таб Аткинс написал спецификацию полноценных CSS-переменных, точнее, кастомных свойств. Эти переменные поддерживаются уже в 70% браузеров по миру и сильно меняют принцип написания стилей.

Кастомные кто? Объясняю. Помните, я говорил, что CSS не очень-то готов к переменным? Чтобы сохранить синтаксическую совместимость со старыми браузерами и не противоречить модели языка, было решено сделать не просто переменные с долларом в начале, а механизм создания собственных свойств для нужд разработчика. Ещё их переводят как «пользовательские» свойства, но с этим возникает путаница: кто здесь пользователь, а кто здесь разработчик? Сразу скажу, синтаксис у них немножко странный, но вы поймёте почему.

Например, у нас сейчас есть свойство box-shadow , чтобы отбрасывать тень. А раньше его не было, оно появилось первым в браузере Safari в 2008 году. Но появилось не просто так, а как -webkit-box-shadow , с префиксом, начинающимся с дефиса. То есть разработчики движка WebKit придумали своё свойство. Только потом, когда оно стало частью стандарта и появилось в других браузерах, префикс убрали.

.shady

Теперь вы тоже можете создавать собственные свойства, только не нужно указывать между дефисами название движка: дефис, дефис, название свойства. Давайте создадим свойство —box-shadow-color и зададим ему значение tomato . Чтобы использовать это значение в коде, нужно передать его в функцию var() .

.shady

Мы сейчас объявили новое свойство, которое потом можно повторно использовать снова и снова. А ещё свойства box-shadow-color никогда не было в природе и чтобы менять тени, например, по наведению, приходилось переписывать box-shadow целиком. А теперь по ховеру можно просто поменять значение переменной. Круто?

.shady < --box-shadow-color: tomato; >.shady:hover

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

.shady

Из-за того, что это кастомные свойства, а не просто доллары с автозаменой, они ведут себя как обычные свойства: наследуются вглубь для всех детей элемента и не видны между элементами-соседями. Чтобы переменную точно было видно во всём документе, её нужно задать самому корневому элементу , но лучше даже :root , на случай если это корневой элемент .

:root

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

@media (min-width: 320px) < .shady < --font-size: 48px; >>

Кастомные свойства можно использовать даже внутри функции calc() , которая посчитает результат выражения внутри. Уже не очень похоже на привычный CSS, правда? Стоит ли говорить, что все препроцессоры уже умерли от зависти, глядя на такое.

.shady

Ещё кастомные свойства становятся идеальным транспортом для данных между скриптами и стилями. Например, вы можете динамически считать координаты мыши в JS и пробрасывать их в кастомные свойства через setProperty в нужный элемент.

element.style.setProperty('--pointer-left', event.clientX);

Дальше в стилях уже можно решить: использовать их в top и left или transform: translate() . И наоборот: значение свойства можно получить в JS с помощью getPropertyValue .

И это я только кастомные свойства лапкой потрогал, дальше ещё куча интересного, что кардинально меняет работу со стилями. Читайте и смотрите дальше сами: статьи, видео и слайды.

Кастомные свойства — это не border-radius , который либо делает красиво, либо нет. Бросаться всё переделывать на них пока рано, вёрстка может сильно поломаться в браузерах, которые их не поддерживают. Но уже пришло время пробовать и уметь.

Разработка приложений со 100%-й кастомизацией. Customization Driven Development (CDD)

В данной статье я хочу поделиться своим опытом разработки интерфейсов с уровнем кастомизации вплоть до 100% (реальные 100%). При этом сохраняется обратная совместимость и возможность апдейтов. Магия? — Нет, это CDD!

Все началось еще в 2018 году в одной крупной международной компании. Меня пригласили в главный офис для объяснения топ руководству как мы будем решать проблему кастомизации нашего продукта, а конкретно UI части. Клиентам необходимо было немного изменить его под себя и кое-что добавить. Нужно было сохранить обратную совместимость, чтобы клиенты могли получать обновления продукта. Тогда я знал только про возможности добавления “дыр” в коде (slots), в которые можно добавить любой функционал. Ну еще и про API, уже для изменения функциональности. Понятно что ни о какой возможности кастомизации на все 100% речи не шло, ведь тогда нужно изменять исходный код, а это само собой потеря обратной совместимости.

Конечно CDD нужен далеко не всем. Эта техника будет крайне полезна при разработке продукта, клиентам которого необходима глубокая кастомизация. Я имею ввиду, не просто поменять логотип и название, а поменять абсолютно все что душе угодно. И при этом не потерять возможность будущих апдейтов продукта.

Как же добиться практически 100%-й кастомизации и без единого разрыва без потери обратной совместимости?

В CDD используется «декларативная кастомизация», т.е. все представление с логикой должны быть вывернуты наружу для возможности полной кастомизации. Если необходимо кастомизировать определенные части довольно сложной компоненты, тогда мы просто отображаем ее более простые внутренние компоненты. Эти компоненты могут быть упакованы в так называемый “черный ящик” с богатым API и “дырами” (slots), либо также отображены еще более простыми компонентами. Представление с логикой любых компонент (кроме примитивных) всегда можно вывернуть наружу, для получения 100% доступа.

И здесь вы можете возразить: “Но как же, ведь когда мы используем внутреннее содержимое, тогда мы теряем возможность апдейтов!”. Нет, это не совсем так, и вот почему:

1. Компонента любой сложности (кроме примитивной) — это всего лишь набор более простых компонент, который всегда есть в свободном доступе и при ее апдейте, мы наглядно видим что и где в этом наборе изменилось и можем очень просто и быстро проапдейтить ее вручную (если это нужно);
2. Сложная компонента состоит из менее сложных компонент, которые мы можем оставить в их стандартном, упакованном виде, если нам не нужна их глубокая кастомизация и естественно будем получать их апдейты автоматически;

Хорошо. А как же этого добиться? Какие шаги?

Сначала нужно разработать самые примитивные компоненты. Они могут, а некоторые из них даже должны иметь по 2 варианта:

1. Стандартный компонент, “черный ящик” с богатым API и “дырами” (slots), удобен в использовании, но имеет ограниченные возможности кастомизации ;
2. Компонент-обертка, расширяет возможности контента, который вы сами помещаете внутрь. Менее удобен в использовании, но имеет гораздо большие возможности кастомизации, вплоть до 100%. Обязательно для стандартных HTML элементов: , , , , , , …

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

В теории все хорошо. А как дела обстоят на практике?

Я создал технологию https://uiwebkit.com, которая уже делает это на практике. Еще, я сейчас готовлю к публикации проект поменьше и он уже полностью Open Source. Вот там уже наглядно видны все плюсы CDD. Проект будет крайне полезен тем, кто часто работает со сложными, кастомными HTML формами с динамическими полями и валидациями. Хотелось бы рассказать о нем подробнее, но это тема уже другой статьи.

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

Буду рад вашим комментариям и мнению на этот счет, либо можете смело писать в личку. Спасибо!

• кастомизация
• веб-сайт
• интерфейсы
• интерфейс
• программирование
• технологические процессы

Что такое кастомизация в программировании

В прошлом уроке мы рассмотрели проверку вводимых данных через скрипт пользовательского редактора.
Но этот скрипт для одного конкретного компонента.
А если у нас много компонентов, для которых нужны однотипные проверки?
Для этого создаются атрибуты.

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

Все вводимые в инспекторе данные надо проверять на корректность.
И Unity это делает. В частности проверяет тип вводимых данных с типом переменной, которой они будут присвоены.
Например в поле типа int нельзя ввести текст или десятичное число.
А если нам нужны дополнительные проверки?

Кастомизация испектора в Unity.
В этой статье мы рассмотрим самый простой способ кастомизации инспектора — атрибуты.