Как вариант имплементации BIF — нормализация данных через описание трансформационных схем средствами normalizr, с попутным декларированием типов входных и результирующих данных через JSDoc комментарии, что позволяет хранить документацию к используемым моделям в одном месте, переиспользовать схемы, а засчет, например, явного преобразования входных сущностей с валидацией ожидаемых свойств — иметь всегда предсказуемую модель на выходе с дефолтными значениями
Согласен с вами, подход с измерением отступов от контейнеров существенно упростил бы задачу, обеспечив приемлемый результат с минимальными различиями на уровне текстовых метрик. Но в то же время для качественного соответствия и выдержки отступов между компонентами, как мне кажется, нужна их проработанная композиция, которую гораздо проще создать при разработке проекта с нуля или же при достаточно гибкой имплементации элементов интерфейса.
Описанное решение является следствием ряда факторов, на каждый из которых по отдельности или на их совокупность в целом невозможно было оказать существенного влияния.
Представьте ситуацию, когда степень педантичности и уровень точности, предъявляемый к желаемому результату, имеют решающее значение, а проект представляет унаследованную кодовую базу, где элементы интерфейса и их стили уже описаны «магическими» значениями в попытке добиться желаемой точности для поддержки 10+ локализаций, часть из которых используют шрифты с процентом пустых областей порядка 10-15% от необходимого размера. Модификация интерфейса в этом случае подразумевает многочисленные ручные пересчеты, что существенно сказывается на итоговых временных оценках. Добавим сюда распределенную команду дизайнеров со стороны клиента, работающих одновременно с десятком направлений и без унифицированного стайлгайда.
Кейс очень и очень специфический, поэтому предлагаю рассматривать описанный подход не как золотую пулю, подходящую каждому проекту, но как не совсем стандартный способ решения достаточно распространенной задачи. Возможно кто-то найдет в нем свои преимущества.
Как вариант имплементации BIF — нормализация данных через описание трансформационных схем средствами normalizr, с попутным декларированием типов входных и результирующих данных через JSDoc комментарии, что позволяет хранить документацию к используемым моделям в одном месте, переиспользовать схемы, а засчет, например, явного преобразования входных сущностей с валидацией ожидаемых свойств — иметь всегда предсказуемую модель на выходе с дефолтными значениями
Описанное решение является следствием ряда факторов, на каждый из которых по отдельности или на их совокупность в целом невозможно было оказать существенного влияния.
Представьте ситуацию, когда степень педантичности и уровень точности, предъявляемый к желаемому результату, имеют решающее значение, а проект представляет унаследованную кодовую базу, где элементы интерфейса и их стили уже описаны «магическими» значениями в попытке добиться желаемой точности для поддержки 10+ локализаций, часть из которых используют шрифты с процентом пустых областей порядка 10-15% от необходимого размера. Модификация интерфейса в этом случае подразумевает многочисленные ручные пересчеты, что существенно сказывается на итоговых временных оценках. Добавим сюда распределенную команду дизайнеров со стороны клиента, работающих одновременно с десятком направлений и без унифицированного стайлгайда.
Кейс очень и очень специфический, поэтому предлагаю рассматривать описанный подход не как золотую пулю, подходящую каждому проекту, но как не совсем стандартный способ решения достаточно распространенной задачи. Возможно кто-то найдет в нем свои преимущества.