Проблема в том, что я и написал — в том, что без него будет создаваться фрагментирванность сообщества, увеличиваться изоляционизм и уменьшаться коллабориционизм.
Сейчас GitLab не сможет заменить Github по одной причине — это "личный" инструмент. Он не сможет (пока что) быть центральным хабом, единым и всем понятным инструентом для Open Source общества. Он будет создавать фрагментированность, что в данном случае плохо.
Альфа-Банк Украина без каких-либо предупреждений вчера отключил интеграцию с WebMoney, а сегодня из админ. панели пропали все упоминания о WebMoney. Оператор сказал что с сегодняшнего дня банк больше не работает с WebMoney.
Ремарка: буду продолжать говорить исключительно о Sass, поскольку с Less у меня опыт не полноценный и там скоупинг работает иначе.
Мы объявляем локальные переменные внутри компонентов с флагом !default. Пока мы не пытаемся их переопределить извне, всё хорошо — переменные локальные, соседним компонентам не мешают.
Здесь проблема в том, что вы пытаетесь создать инкапсуляцию кустарным методом.
Для инкапсуляции в Sass уже есть миксины, и они как раз решают вашу проблему. Да, их нужно вызывать после импортирования, но это нормально. Думайте о функциях в JavaScript — как правило, их также нужно вызвать после импортирования. Но как раз это и дает нам возможность инкапсуляции и позволяет между импортированием и вызовом переназначить любые нужные параметры.
Локальные переменные становятся глобальными и у нас сразу же возникает необходимость разделять их при помощи префиксов. Разделение по неймспейсу — это имитация инкапсуляции. Такое разделение требует значительных усилий по поддержанию порядка.
Как я уже говорил, неймспейсить нужно только глобальные переменные, это нормальная практика для большинства языков программирования. Неймспейсить "локальные"" переменные (даже если они в глобальном скоупе, но используются только локально) — затея, как вы уже сами сказали, болезненная, но она и не нужная. Она ничего не дает. В том же Ruby и Python так не далают. В JavaScript иногда тоже можно встречаться с этой проблемой, но и в этом случае ничего неймспейсить не нужно — последний let myVar перезапишет переменную с нужным нам значением в текущем скоупе.
В Бутстрапе на Less так и сделано, есть переменные общего назначения без префикса, а также у каждого компонента есть свои глобальные переменные с префиксом. Но переменные всех компонентов хранятся в одном внешнем файле и общие не отличаются от компонентных по формату написания имени.
Мы запутались и не справились с поддержанием порядка в именовании. Сначала использовали общие переменные в своих компонентах, потом по невнимательности стали использовать переменные из соседних компонентов.
Если я правильно понял из описание, то вот как раз это "инвертированное" или "всеобщее" прифексирование в Бутраспе и создает эти неприятные запутывания.
Там где нужны были действительно глобальные переменные — нужно было префексировать. В остальных случаях было логичней инкапсулировать параметры как дефолтные в миксины.
Для простых случаев можно помещать "локальные" переменные прямо в файл, без префиксов и скоупинга в классе, но это будет подходить только для стилей сайтов. В остальных случаях — миксины и дефолтные значения.
Значения общих переменных было менять слишком опасно — они использовались во многих местах. Каждый раз надо было лезть в файл с переменными, искать среди сотен переменных нужную, а потом проверять, а не используется ли эта переменная ещё в каких-нибудь компонентах. И если используется, то создавать новую переменную. Вменяемые имена переменных быстро закончились. Проблемы росли как снежный ком.
Не скажу что там у Бутстрапа хранится, но по идее в глобальных переменных нужно хранить только действительно глобальные конфигурационные значения, которые легально могут влиять на весь проект. На то он и является конфигурационным файлом, и это нормально, что он влечет за собой каскад изменений. Правда, нормально это только если это предусмотренный архитектурно каскад. Мне сложно судить о наличии или отсутствии проблем в архитектуре вашего проекта без вида кода и того, что вы действительно хранили в глобальном конфигурационном файле, но судя по описанию — хранили вы там не совсем то, что нужно, иначе этой проблемы не возникало бы и вы бы всегда понимали результат изменений той или иной глобальной переменной.
Посмотрите на глобальный конфиг стилей Kotsu — там нет глобальных переменных, которые можно использовать где-то случайно и потом не понимать, к чему приведет их изменение. Разве что в команде есть проблемы с людьми, которые делают что-то бездумно, но это уже совсем другого рода проблема.
$padding — объявлена в глобальной области видимости и без префикса. Значит в компоненте №3, №4 и так далее паддинг будет равен 20px. Это уже ошибка.
Именно так, я это и пытался подчеркнуть в своем посте выше.
Переменная $padding действительно является глобальной, но используется только локально.
Это нормально, в этом нет никакой проблемы и как раз не нужно ее префексировать и нет необходимости помещать в скоуп класса (без острой на то необходимости). Нам лишь главное знать, что она никогда не перепишет глобальную конфигурационную переменную, но поскольку глобальные значения как раз всегда префексированы, этого никогда не случится.
Кроме этого, для её определения использована переменная из другого файла. Т.е. ваш компонент не сможет скомпилироваться самостоятельно без внешнего файла, в котором объявлена переменная ekzo-space().
Это был пример зависимости от глобальной конфигурации. Ее можно сделать опциональной с помощью
Но если начать так делать, то это уже верный признак того, что лучше использовать миксин с дефолтными значениями.
Значит в компоненте №3, №4 и так далее паддинг будет равен 20px
Этой проблемы не должно возникать, поскольку если компонент №3 и №4 используют ту же "локально-глобальную" переменную $padding, она должна всегда объявляться в начале файла. Я не могу себе представить компонент, который без объявления переменной вдруг с бухты-барахты начнет использовать неизвестную переменную $padding.
Нужно понимать, что Sass во многом наследует Ruby, а в нем, как и в Python, скоупинг переменных работает иначе, чем в JavaScript. К примеру, ситуация когда по скоупу выше будет встречаться по своей сути глобальная переменная с весьма общим названием padding = 10, а потом глубже — padding = 20 абсолютно нормальная, в этом нет никакой проблемы. Проблемы могут быть разве что у разработчика, который почему-то забывает объявить нужные переменные, чтобы случайно не использовать глобальное значение.
Так это работать, конечно, не будет. !default нужен для других случаев. И, в общем-то, глядя на ваши примеры, я бы сказал что случай этот не ваш.
С переменными как параметрами миксина тоже не то. Чтобы миксин отренедерил в CSS свой код, его обязательно нужно вызвать, с параметрами или без.
В этом нет никаких проблем. Миксин — это по сути своей функция, как раз форма инкапсуляции. И я уже писал выше о том, что во многих языках это нормально вызвать функцию после импорта, и это как раз ожидаемое поведение. Необходимость что-либо импортировать, а потом внезапно вызвать какие-то другие непонятные миксины (а в случае Sass еще и прописывать внезапную переменную $*-override) для конфигурации другого миксина — это это как раза не ожидаемое поведение.
К слову, стоит отметить, что переменная $*-override никак не заизолирована, и из-за того что она не является обязательной, да еще и автоматически мерджится с дефолтными настройками, шансов случайно закинуть что-либо в нее из другого компонента весьма много.
В моей системе компонент достаточно заинклюдить, тогда он отрендерит CSS с дефолтными параметрами. Если нужно его настроить, перепределить нужные переменные в конфиге. В сам компонент изменения вносить не нужно.
Да, но для этого у вас целый свой огород с велосипедами. Если в Less-версии они смотрятся по крайней мере приемлимо, сам язык предрасположен к таким манипуляциям, то по Sass явно видно как он сопротивляется всему этому и результат не просто для конечного восприятия и использования. Это как-то уже намекает на то, что в подходе что-то не так.
Сначала мне показалось что идея забавная, но потом понял что перемудрили.
С точки зрения Sass, логичней было использовать флаг !default, это позволило бы избежать использование объектов в целом и связанной с ними проблемы склеивания, а также весьма громоздкий способ извлечения данных из этого самого объекта, и вообще приличного количества boilerplate-кода только для того, чтобы это работало в каждом компоненте.
Кроме того, с точки зрения оптимизации, в Sass все эти склейки, проверки на присутствие переменной, а также map-get в больших количествах неприятно отразятся на скорости компиляции в больших проектах, и это так даже, увы, с libsass.
Что касается глобальных переменных, то их было бы достаточно именовать с префиксами, как уже было сказано в статьи, (global или именим фреймворка, как у нас. Это эффективно изолирует их от локальных переменных, в следствии чего в локальных файлах можно смело использовать переменные без каких-либо префиксов и хитрых оберток в виде объекта — они ничего не сломают, потому что с глобальными переменными конфликтовать никогда не будут, а если такая же локальная переменная ($padding) встретится в другом компоненте, это тоже ничего не сломает, при условии что все используемые в данном файле локальные переменные всегда будут объявляться в начале файла:
Вот пример как компонент Kotsu устанавливает локальное значение $padding, которое по умолчанию устанавливается на глобальное значение ekzo-space(). Просто и без каких-либо излишеств.
Если же в проекте нужна истинная конфигурация именно компонента, который предположительно будет экспортировать или многократно использоваться, то с описанной методикой тоже есть какой-то неоправданный overhead. К примеру, если бы упомянутый bettertext.less писался на Sass, то все хитро передаваемые значения по умолчанию было бы куда логичней поместить в аргументы самого миксина:
Пример такого миксина:
@mixin Component-1(
$width: ekzo-space(16),
$height: ekzo-space(10)
) {
// включать сюда название класса — вопрос спорный, но пост не об этом
.Component-1 {
width: $width;
height: $height;
}
}
@include Component-1();
@include Component-1($width: 200px);
В итоге, нам не нужно ничего придумать, чтобы как-то передавать, записывать, переопределять и выводить значения, все это уже предусмотренно самим языком.
Но, на практике, такие миксины для многих сайтов являются избыточными, поскольку требует больше времени на декларирование компонента, а также сам вызов миксина немного негативно сказывается на скорости компиляции.
Пожалуй, стоит добавить, что никакого парадокса в этом явлении нет, потому что транзисторные усилители, увы, все еще не способны удовлетворить все потребности музыкантов. Вот и имеем такую ситуацию.
Зашел в ожидании полезных софтинок для эмуляции усилителей, вдруг чего нового появилось. а увидел кучку технарей, знающих «в теории», обсирающих ламповые усилители, словно это еще одна религия.
Не уверен что отсутствие материальной ответственности (или затрат — в Вашем оригинальном посте было так) говорит о фиктивной демократии. Во всяком случае, в правовых науках материальная часть не является признаком данной формы правления.Можете привести какие-либо источники?
Нельзя применять термин демократия к данному вопросу, потому что материальные затраты на проект вы не несёте, как и любой другой ответственности. По сути, вы просто пользуетесь бесплатными информационными услугами.
Не могу понять какое отношение наличие материальных затрат имеет к возможности применения термина "демократия"
Поправьте, если не прав.
Discord тоже на Electron, но работает вполне хорошо. Может быть дело все таки не в Electron?
Про "полный фарш". Возможно, кому-то будет полезно:
Проблема в том, что я и написал — в том, что без него будет создаваться фрагментирванность сообщества, увеличиваться изоляционизм и уменьшаться коллабориционизм.
Сейчас GitLab не сможет заменить Github по одной причине — это "личный" инструмент. Он не сможет (пока что) быть центральным хабом, единым и всем понятным инструентом для Open Source общества. Он будет создавать фрагментированность, что в данном случае плохо.
Удивительно, как много людей в последнее время хвалят MS за работу в направлении Open Source, и не замечают, что это очередной акт EEE.
Хинт для тех, кому нужно куда-то вывести WMU — в Украине Steam все еще их принимает...
О каких конских комиссиях идет речь? К примеру, в Альфа-Банк Украина комиссия за вывод была всего 1%.
Альфа-Банк Украина без каких-либо предупреждений вчера отключил интеграцию с WebMoney, а сегодня из админ. панели пропали все упоминания о WebMoney. Оператор сказал что с сегодняшнего дня банк больше не работает с WebMoney.
В этой новости речь идет об API для платформы.
Здесь пытаются добавить поддержку CSS-переменных в IE11 и выше.
Ремарка: буду продолжать говорить исключительно о Sass, поскольку с Less у меня опыт не полноценный и там скоупинг работает иначе.
Здесь проблема в том, что вы пытаетесь создать инкапсуляцию кустарным методом.
Для инкапсуляции в Sass уже есть миксины, и они как раз решают вашу проблему. Да, их нужно вызывать после импортирования, но это нормально. Думайте о функциях в JavaScript — как правило, их также нужно вызвать после импортирования. Но как раз это и дает нам возможность инкапсуляции и позволяет между импортированием и вызовом переназначить любые нужные параметры.
Как я уже говорил, неймспейсить нужно только глобальные переменные, это нормальная практика для большинства языков программирования. Неймспейсить "локальные"" переменные (даже если они в глобальном скоупе, но используются только локально) — затея, как вы уже сами сказали, болезненная, но она и не нужная. Она ничего не дает. В том же Ruby и Python так не далают. В JavaScript иногда тоже можно встречаться с этой проблемой, но и в этом случае ничего неймспейсить не нужно — последний
let myVarперезапишет переменную с нужным нам значением в текущем скоупе.Если я правильно понял из описание, то вот как раз это "инвертированное" или "всеобщее" прифексирование в Бутраспе и создает эти неприятные запутывания.
Там где нужны были действительно глобальные переменные — нужно было префексировать. В остальных случаях было логичней инкапсулировать параметры как дефолтные в миксины.
Для простых случаев можно помещать "локальные" переменные прямо в файл, без префиксов и скоупинга в классе, но это будет подходить только для стилей сайтов. В остальных случаях — миксины и дефолтные значения.
Не скажу что там у Бутстрапа хранится, но по идее в глобальных переменных нужно хранить только действительно глобальные конфигурационные значения, которые легально могут влиять на весь проект. На то он и является конфигурационным файлом, и это нормально, что он влечет за собой каскад изменений. Правда, нормально это только если это предусмотренный архитектурно каскад. Мне сложно судить о наличии или отсутствии проблем в архитектуре вашего проекта без вида кода и того, что вы действительно хранили в глобальном конфигурационном файле, но судя по описанию — хранили вы там не совсем то, что нужно, иначе этой проблемы не возникало бы и вы бы всегда понимали результат изменений той или иной глобальной переменной.
Посмотрите на глобальный конфиг стилей Kotsu — там нет глобальных переменных, которые можно использовать где-то случайно и потом не понимать, к чему приведет их изменение. Разве что в команде есть проблемы с людьми, которые делают что-то бездумно, но это уже совсем другого рода проблема.
Именно так, я это и пытался подчеркнуть в своем посте выше.
Переменная
$paddingдействительно является глобальной, но используется только локально.Это нормально, в этом нет никакой проблемы и как раз не нужно ее префексировать и нет необходимости помещать в скоуп класса (без острой на то необходимости). Нам лишь главное знать, что она никогда не перепишет глобальную конфигурационную переменную, но поскольку глобальные значения как раз всегда префексированы, этого никогда не случится.
Это был пример зависимости от глобальной конфигурации. Ее можно сделать опциональной с помощью
Но если начать так делать, то это уже верный признак того, что лучше использовать миксин с дефолтными значениями.
Этой проблемы не должно возникать, поскольку если компонент №3 и №4 используют ту же "локально-глобальную" переменную
$padding, она должна всегда объявляться в начале файла. Я не могу себе представить компонент, который без объявления переменной вдруг с бухты-барахты начнет использовать неизвестную переменную$padding.Нужно понимать, что Sass во многом наследует Ruby, а в нем, как и в Python, скоупинг переменных работает иначе, чем в JavaScript. К примеру, ситуация когда по скоупу выше будет встречаться по своей сути глобальная переменная с весьма общим названием
padding = 10, а потом глубже —padding = 20абсолютно нормальная, в этом нет никакой проблемы. Проблемы могут быть разве что у разработчика, который почему-то забывает объявить нужные переменные, чтобы случайно не использовать глобальное значение.Так это работать, конечно, не будет.
!defaultнужен для других случаев. И, в общем-то, глядя на ваши примеры, я бы сказал что случай этот не ваш.В этом нет никаких проблем. Миксин — это по сути своей функция, как раз форма инкапсуляции. И я уже писал выше о том, что во многих языках это нормально вызвать функцию после импорта, и это как раз ожидаемое поведение. Необходимость что-либо импортировать, а потом внезапно вызвать какие-то другие непонятные миксины (а в случае Sass еще и прописывать внезапную переменную
$*-override) для конфигурации другого миксина — это это как раза не ожидаемое поведение.К слову, стоит отметить, что переменная
$*-overrideникак не заизолирована, и из-за того что она не является обязательной, да еще и автоматически мерджится с дефолтными настройками, шансов случайно закинуть что-либо в нее из другого компонента весьма много.Да, но для этого у вас целый свой огород с велосипедами. Если в Less-версии они смотрятся по крайней мере приемлимо, сам язык предрасположен к таким манипуляциям, то по Sass явно видно как он сопротивляется всему этому и результат не просто для конечного восприятия и использования. Это как-то уже намекает на то, что в подходе что-то не так.
Спасибо за статью!
Сначала мне показалось что идея забавная, но потом понял что перемудрили.
С точки зрения Sass, логичней было использовать флаг
!default, это позволило бы избежать использование объектов в целом и связанной с ними проблемы склеивания, а также весьма громоздкий способ извлечения данных из этого самого объекта, и вообще приличного количества boilerplate-кода только для того, чтобы это работало в каждом компоненте.Кроме того, с точки зрения оптимизации, в Sass все эти склейки, проверки на присутствие переменной, а также
map-getв больших количествах неприятно отразятся на скорости компиляции в больших проектах, и это так даже, увы, сlibsass.Что касается глобальных переменных, то их было бы достаточно именовать с префиксами, как уже было сказано в статьи, (
globalили именим фреймворка, как у нас. Это эффективно изолирует их от локальных переменных, в следствии чего в локальных файлах можно смело использовать переменные без каких-либо префиксов и хитрых оберток в виде объекта — они ничего не сломают, потому что с глобальными переменными конфликтовать никогда не будут, а если такая же локальная переменная ($padding) встретится в другом компоненте, это тоже ничего не сломает, при условии что все используемые в данном файле локальные переменные всегда будут объявляться в начале файла:Результат:
Вот пример как компонент Kotsu устанавливает локальное значение
$padding, которое по умолчанию устанавливается на глобальное значениеekzo-space(). Просто и без каких-либо излишеств.Если же в проекте нужна истинная конфигурация именно компонента, который предположительно будет экспортировать или многократно использоваться, то с описанной методикой тоже есть какой-то неоправданный overhead. К примеру, если бы упомянутый bettertext.less писался на Sass, то все хитро передаваемые значения по умолчанию было бы куда логичней поместить в аргументы самого миксина:
Пример такого миксина:
Результат:
В итоге, нам не нужно ничего придумать, чтобы как-то передавать, записывать, переопределять и выводить значения, все это уже предусмотренно самим языком.
Но, на практике, такие миксины для многих сайтов являются избыточными, поскольку требует больше времени на декларирование компонента, а также сам вызов миксина немного негативно сказывается на скорости компиляции.
Есть еще подобный плагин для проверки в рантайме, но для Flow: babel-plugin-tcomb. Сам tcomb тоже стоит внимания.
Простите, огорчило.
Автору спасибо за статью.
Не уверен что отсутствие материальной ответственности (или затрат — в Вашем оригинальном посте было так) говорит о фиктивной демократии. Во всяком случае, в правовых науках материальная часть не является признаком данной формы правления.Можете привести какие-либо источники?
https://www.google.com.ua/search?q=mitsubishi+pajero+sport+2004&source=lnms&tbm=isch&sa=X&ved=0ahUKEwjvrLaaxb7PAhWDkCwKHf28BvIQ_AUICCgB&biw=1920&bih=974
Не могу понять какое отношение наличие материальных затрат имеет к возможности применения термина "демократия"
Суть в том, что переключение на нейтралку не приведет к каким-либо катастрофическим последствиям.
Писали выше. Проблема в том, что педаль тормоза в это время, скорее всего, не работала, либо не реагировала должным образом.