Pull to refresh

Comments 13

Можно взять 52 битное кодирование ([a-zA-Z]+) или 64-битное ([a-zA-Z0–9_-]+)

Биты немного не так работают.
Base64 != "64-битное кодирование". А "шестнадцатеричное число" — не то же самое, что "16-битное число".

Согласен, терминологию можно уточнить.
А зачем так заморачиваться с хешами?
Не проще ли сделать последовательное переименование классов с добавлением новой буквы, когда алфавит кончается?
a, b, c, ... , y, z, aa, ab, ac, ... , ay, az, ba, bb, bc, ...
Экономия букв налицо.
В кодировке уже есть 1 байт под символ, поэтому мы берем всё что допустимо [a-zA-Z0–9_-] 64 значения. У вас в примере 26. А хеши нужны во избежание коллизий, потому что в css-modules глобальная видимость имён.
А хеши нужны во избежание коллизий, потому что в css-modules глобальная видимость имён.

Всё ещё не видно проблемы. Глобальный счётчик при сборке полностью решает проблему. Это вот как раз хеши имеют коллизии (что впрочем тоже можно решить сверившись с теми хешами, которые уже созданы, дабы не дублировать).

Глобальный счетчик порождает другие проблемы — рассинхрон сборки бека/фронта, нужен лишний проход сборки (или отдельный плагин), и разбивание долгосрочных кешей для всего проекта
или отдельный плагин

Там уже есть возможность указать метод для формирования имени. Но в целом соглашусь, что минусов хватает.

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

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

Насчет байтов понятно. Мой пример можно расширить под 64 значение: модифицировать так, чтобы закончился не только алфавит, но и A-Z0–9_-. А потом начать сначала по тому же принципу.
Но я, в данном случае, все равно, не понимаю назначения хеша. Ведь мы избегаем коллизий добавляя ещё один символ к строке.
префикс работает на уровне файла. на уровне проекта работает хеш по пути файла. чтобы не использовать хеш — нужно собирать файлы до начала сборки, сортировать их, и потом по списку работать. тогда будет глобальный нейминг и хеши не нужны. но первое же изменение любого файла сломает кеширование, и будет полностью новый билд. если говорить про большие проекты, то это недопустимо. текущее решение — компромисс перехода по кешу с уровня класса на уровень файла.
Думаю что такие бандлы будут хуже сжиматься gzip и итоговой результат (сколько передали в сжатом виде по сети) будет не особо лучше.
сжимается гораздо лучше, т.е. рандомый хеш != одинаковые строки. попробуйте
Sign up to leave a comment.

Articles