Haml: Запрос функции: импорт папки

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

Я понимаю ваш аргумент, однако не думаю, что вы видите ситуацию другого типа, в которой это необходимо. В настоящее время у меня есть папка, в которой будет более 60 файлов Sass. Без возможности @import папки мне нужно поддерживать файл, который импортирует каждый файл индивидуально.

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

Кроме того, у нас есть приоритет, что импорт папки - это «хорошо». Оператор импорта Java позволяет вам импортировать целые пакеты или определенные классы этих пакетов.

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

Такие проблемы с упорядочением отсутствуют в коде, и там, где они есть (например, в ruby), такой функции нет.

Мне было бы интересно узнать, есть ли способ сделать это в Sass без изменения механизма импорта ядра sass. Это позволит фреймворкам и отдельным лицам, использующим sass, разработать свою собственную систему глобализации по своему усмотрению. Например:

<strong i="8">@import</strong> file-list("foo/*.sass");

Раньше у нас была специальная логика синтаксического анализа для @import , которая препятствовала бы этому, но теперь мы этого не делаем.

Проблема с разрешением по-настоящему динамического импорта (например, через функции) заключается в том, что тогда структуру зависимостей документа становится невозможно определить динамически. Это означает, что кеширование и выборочная компиляция становятся менее полезными.

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

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

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

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

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

Так же, как импорт определенных файлов работает. он подходит для одних ситуаций, но не подходит для других.

Выбор остается за разработчиком.

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

Расширение, которое я бы рассмотрел, допускало бы стандартные файловые глобусы - вероятно, те, которые поддерживаются Dir.glob . Это будет разрешено во время компиляции и обеспечит разумную степень мощности.

Однако я все еще не уверен в полезности.

Важно учитывать, что порядок через Dir.glob зависит от файловой системы и может меняться на разных платформах - меня действительно укусила эта разница между Mac и Linux. Поэтому, если мы в конечном итоге реализуем такую ​​функцию, для нас важно отсортировать список в соответствии с хорошо документированным и понятным подходом (например, сортировка по нижнему регистру)

Я тоже все еще немного склоняюсь к этой особенности. Подход к импорту, который использует компас, на самом деле не является бременем обслуживания. Однако это, безусловно, часто запрашиваемая функция. Я думаю, что он поднимался в списке рассылки и в твиттере примерно 4 или 5 раз.

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

Я согласен. Я как бы против возможности передавать параметр напрямую в Dir.glob. Это действительно кажется ненужной функцией. Можете ли вы, ребята, придумать сценарий, в котором будет выгодно иметь такую ​​степень контроля?

Похоже, что следующих двух вариантов должно хватить:
-Cherry pick файлы с помощью @import
-Импортировать весь каталог, используя @import имя_папки

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

Импорт каталогов через <strong i="5">@import</strong> dir слишком неоднозначен с импортом отдельных файлов. Мы обязательно должны добавить как минимум * globs.

Однако все еще не убежден.

это полезно, если у вас разные «стили» для страницы. пример:
generic / (здесь xx файлы sass)
style1 / (здесь xx файлов sass, которые добавляют / перезаписывают стили к стилям в общем)
style2 / (здесь xx файлы sass, которые добавляют / перезаписывают стили к стилям в общем)
style1.sass (просто: @import generic / _, style1 / _)
style2.sass (просто: @import generic / _, style2 / _)

Почему у вас не было просто _generic.sass, который импортирует все в общий каталог?

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

Определить "таблицы стилей с ограниченным объемом"?

Таблицы стилей, в которые вложено большинство или все их селекторы. например, body.foo

Не гарантируется, что они будут независимыми от порядка. Другая таблица стилей в другом месте может определять body.foo ... или что-то еще с более высокой специфичностью.

Тогда у вас действительно нет работающего фреймворка, потому что ваши файлы не разделены правильно.

Есть много способов испортить свой CSS. Мы можем предоставить им это решение и объяснить, когда его следует использовать при импорте отдельных файлов.

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

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

body.foo .baz {
  color: blue; }

body.bar .baz {
  color: red; }

Эта таблица стилей хорошо разделена, но по-прежнему зависит от порядка.

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

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

Тихое игнорирование импорта, который не найден, больше не является проблемой в sass3. Только импорт css будет игнорироваться.

У меня есть один файл sass, который импортирует около 60 других. Я меняю его, когда файлы добавляются или удаляются, и я всегда думаю о порядке, когда я это делаю. Мне это никогда не казалось обузой, а скорее необходимым шагом.

Если мой импорт не найден (я всегда указываю .sass для импорта), мои тесты терпят неудачу.

Есть добавка: как можно проще и не проще.

Моя интуиция подсказывает мне, что это делает вещи слишком простыми, и вся экономия времени теряется из-за одного сеанса отладки. Я голосую за то, чтобы мы отложили это на время. Если кто-то захочет создать плагин sass, который предоставляет эту возможность, мне было бы очень интересно посмотреть, как это работает для этих пользователей.

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

Я собираюсь закрыть это.

ага, это отстой ... у меня есть папка page_specific / в моих активах приложения rails ...
все они должны быть скомпилированы в большой двоичный объект, и каждый из них полностью завернут в
body # page1 {}, body # page2 {} и т. д.

нет никаких шансов, что они будут зависеть от порядка, и, честно говоря, все это «вы упустите его! нет !!!!!!» хрень обидно.

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

конечно, мы можем придумать способ минимизировать эту незначительную проблему заказа. детерминированное упорядочение - это начало. назвав его @ import-dir, и документация о потенциальной проблеме с заказом также может помочь. rails уже предоставляет require_tree, и там все работает нормально. единственным исключением является то, что файлы компилируются индивидуально, в результате чего мои миксины и переменные падают на пол. Я отмечаю, что миксины - это та часть, которая была размещена как явно независимая от порядка, так почему это не может работать для sass, когда это работает для всех остальных?

https://github.com/chriseppstein/sass-globbing

@chriseppstein круто ! (и извините за разглагольствование, как маньяк всем)