--- title: "Конвертер единиц измерения: температура" slug: "unit-converter-temperature" status: "new" updated: 2026-10-22T16:41:51Z published: 2026-10-22T16:41:51Z canonical: "support.tulip.co/unit-converter-temperature" --- > ## Documentation Index > Fetch the complete documentation index at: https://support.tulip.co/llms.txt > Use this file to discover all available pages before exploring further. # Конвертер единиц измерения: температура To download the app, visit: [tulip](https://Library В этой статье один из наших разработчиков библиотеки, Тамаш, подробно рассказывает о решениях, лежащих в основе приложения-строительного блока «Конвертер единиц измерения: температура», доступного в библиотеке. ## Почему я использовал список объектов вместо таблицы Привет, я Тамаш из Tulip. Для этого компонента я решил использовать список объектов, хранящийся в качестве значений переменных по умолчанию, поскольку набор данных редко меняется и не требует управления с помощью таблиц. В данном случае коэффициенты и смещения при преобразовании температур представляют собой статические математические соотношения. Они не требуют редактирования во время выполнения, агрегирования или реляционных запросов. Именно поэтому я сознательно отказался от использования таблицы. Вместо этого:* я храню определения коэффициентов преобразования внутри переменной* переменная инициализируется значениями по умолчанию* список объектов обеспечивает структурированное и удобное для чтения представление данных* не требуется логика агрегирования таблиц Такой подход позволяет сохранить легкость и автономность компонента. ## Почему не таблица? Использование таблицы повлекло бы за собой:* Необходимость добавить в приложение дополнительную таблицу* Необходимость создать запрос к этой таблице* Необходимость настроить логику агрегации для этого запроса* Необходимость добавить и поддерживать этот запрос и агрегацию внутри приложения Для набора данных, который редко меняется, такие накладные расходы являются ненужными. Благодаря хранению определений преобразований в качестве значений по умолчанию внутри переменной:* Компонент становится полностью переносимым* При копировании приложения копируется и структура данных* Не требуется никаких внешних зависимостей Список объектов обеспечивает чёткое структурированное представление связанных атрибутов (inputUnit-targetUnit, factor, offset) без необходимости использования реляционной логики. ## Принцип проектирования: защищённая логика, гибкая настройка Компонент был разработан с учетом одного ключевого принципа: > Основная логика никогда не должна требовать модификации. Для обеспечения этого я ввёл внутренние переменные компонента и обозначил их с начальным подчеркиванием (например, **_temperatureInputUnit**). Эти переменные с подчеркиванием выступают в роли стабильных внутренних интерфейсов, на которые может полагаться защищённая основная логика. **Компромисс:** использование внутренних переменных требует двух небольших триггеров настройки:* 01 – USER CONFIG: INPUT STAGE сопоставляет внешние источники внутренним переменным* 03 – USER CONFIG: OUTPUT STAGE сопоставляет внутренний результат с желаемым местом назначения Это добавляет тонкий конфигурационный слой вокруг защищённого движка, но при этом оставляет триггер MAGIC неизменным и удобным для копирования и вставки. ### Альтернативный вариант Более простой — но менее удобный для обслуживания — подход заключался бы в том, чтобы вставлять внешние ссылки непосредственно в выражение ядра (например, используя переменную приложения или заполнитель « table record field » прямо в коде). Это позволяет избежать дополнительных триггеров конфигурации, но снижает переносимость и затрудняет повторное использование, поскольку каждая копия требует редактирования основной логики. Для распределения компонентов шаблон интерфейса с использованием внутренних переменных проще в управлении: входы и выходы настраиваются на границах, в то время как вычислительный движок остаётся стабильным и защищённым. Триггер MAGIC выполняет поиск и применяет аффинное преобразование: > result = (value × factor) + offset Поскольку определения преобразований централизованы во внутреннем списке объектов, триггер может обрабатывать несколько случаев без модификации. В данной реализации:* Поддерживаются °C, K и °F* Все комбинации 3×3 предопределены* Логика динамически определяет правильный коэффициент и смещение Разработчику приложения необходимо лишь: 1. Настроить источники входных данных; 2. Настроить место назначения выходных данных Без переписывания формул. Без редактирования условной логики. Без структурных изменений. ## Почему это масштабируемо Такая структура позволяет:* Добавлять новые единицы измерения путём расширения списка объектов* Оставлять механизм вычислений без изменений* Сохранять архитектурную согласованность между приложениями* Быстро повторно использовать компоненты в нескольких проектах Компонент разделяет:* Настройку источников данных (этап ввода)* Логику выполнения (MAGIC)* Маршрутизацию результатов (этап вывода) Такое разделение обеспечивает безопасность, предсказуемость и масштабируемость системы. ## Разбор триггера — как работает MAGIC (выражение) Защищённый триггер MAGIC реализован в виде одного выражения:`(@Variable._temperatureInputValue * array_value_at_index( map_to_number_list(@Variable._temperatureConversionDefaults , 'factor'), array_index_of( map_to_text_list(@Variable._temperatureConversionDefaults , 'inputUnit-targetUnit'), @Variable._temperatureInputUnit + '-' + @Variable._temperatureTargetUnit )))+array_value_at_index( map_to_number_list(@Variable._temperatureConversionDefaults , 'offset'), array_index_of( map_to_text_list(@Variable._temperatureConversionDefaults , 'inputUnit-targetUnit'), @Variable._temperatureInputUnit + '-' + @Variable._temperatureTargetUnit ))`В общем плане это выражение выполняет три шага: ### 1. Построение ключа поиска Ключ динамически формируется из настроенных входных переменных: > inputUnit-targetUnit Например: > °C-°F Это гарантирует, что логика остаётся универсальной и работает для всех поддерживаемых комбинаций. ### 2. Определение коэффициента и смещения из списка объектов Выражение определяет коэффициент и смещение за один проход:* **map_to_text_list(..., 'inputUnit-targetUnit')** формирует список ключей поиска на лету.* **array_index_of(...)** находит индекс соответствующего ключа.* **array_value_at_index(...)** использует этот индекс для извлечения соответствующих значений из списков коэффициентов и смещений. Ключевым дизайнерским решением здесь является непосредственное объединение **array_index_of(...)** с **map_to_text_list(...)**. Это позволяет избежать хранения промежуточного списка ключей в отдельной переменной. Вместо этого список поиска генерируется непосредственно в коде и сразу же используется для извлечения как коэффициента, так и смещения в рамках одного выражения. Благодаря этому триггер MAGIC остается самодостаточным и сокращает объем настроек, при этом по-прежнему работая как структурированный поиск — без необходимости использования таблицы или логики агрегации. ### 3. Применение аффинного преобразования После определения правильного коэффициента и смещения выполняется вычисление: > result = (value × factor) + offset Поскольку логика поиска основана на индексах и управляется данными, триггеру не требуются условные ветвления или конструкции switch-case. ## Почему была выбрана именно эта структура - Это позволяет избежать жестко запрограммированной условной логики. - Она естественным образом масштабируется при добавлении новых комбинаций единиц измерения. - Расчет полностью зависит от данных. - Она поддерживает одно защищенное выражение вместо множества триггеров. Такая конструкция обеспечивает детерминированность, расширяемость компонента и защиту от случайного изменения логики. ## Расширение с помощью новых единиц измерения Чтобы добавить новую единицу измерения, расширьте объект _temperatureConversionDefaults, добавив новую запись, содержащую:* inputUnit-targetUnit (ключ)* коэффициент* смещение Как только новое сопоставление появляется в списке объектов, защищённый триггер MAGIC может автоматически его разрешить — изменения в основной логике не требуются. ### Обработка ошибок (шаблон безопасного поиска) Триггер MAGIC включает явное обнаружение сбоев, чтобы обеспечить безопасное выполнение в случае, если пара преобразований не найдена. Вместо того чтобы полагаться на пустой результат, триггер напрямую проверяет индекс поиска: > ARRAY_INDEX_OF( MAP_TO_TEXT_LIST(_temperatureConversionDefaults, 'inputUnit-targetUnit'), _temperatureInputUnit + '-' + _temperatureTargetUnit ) Если возвращаемый индекс равен -1, то соответствующего правила преобразования не существует. Последовательность выполнения: 1. Очистить _temperatureConversionResult в начале триггера. 2. Если индекс поиска = -1 → не производить вычисления. 3. В противном случае → произвести вычисления и сохранить результат. Затем на этапе OUTPUT выполняется проверка: Если _temperatureConversionResult пусто → отобразить сообщение об ошибке. Пример сообщения: > «Не найдено правила преобразования для выбранной пары единиц измерения. Проверьте формат единиц (°C, K, °F) и наличие этой пары в _temperatureConversionDefaults». Это гарантирует:• Отсутствие устаревших значений от предыдущих выполнений • Отсутствие попыток вычислений без действительного правила • Получение пользователем чёткого и понятного сообщения об ошибке Основная логика остаётся защищённой и неизменной, при этом обеспечивая детерминированное и безопасное поведение. ## Почему не использовать отдельные массивы для ключей, коэффициентов и смещений? Альтернативным подходом могло бы быть хранение:* ключей поиска в одном массиве;* коэффициентов — в другом массиве;* смещений — в третьем массиве Хотя технически это сработало бы, это создало бы структурный риск: позиционная взаимосвязь между массивами должна всегда оставаться идеально выровненной. Если порядок элементов в одном массиве изменится, а в остальных — нет, соотношение «ключ–коэффициент–смещение» нарушится незаметно, что приведет к некорректным преобразованиям. Благодаря хранению связанных атрибутов вместе в списке объектов каждая запись сохраняет логическую группировку значений **inputUnit-targetUnit**, **коэффициента** и **смещения**. Это снижает риск нарушения согласованности и делает структуру более безопасной и простой в обслуживании. ## **Присоединяйтесь** [Присоединяйтесь к сообществу](https://community.tulip.co/), чтобы делиться идеями по улучшению, предлагать новые единицы измерения, сообщать о проблемах или обсуждать архитектурные решения.