Промахнулся и не туда ответил. Сорри. «Чем лучше чанки, чем дописывать в конец?»
Всяким минификаторам и библиотекам можно сказать не трогать чанк. Например: Пнгшка генерится с упором на скорость, а потом хочется сжать её получше для долгосрочного хранения.
Любое количество чанков хорошо дружит между собой, а «вконецфайла» всего один. Например: Пользователь захочет криптографически подписывать содержимое, а подписывалка тоже пишет данные в конце файла. Потенциальный конфликт.
Кастомные чанки можно двигать вперёд и назад. Например: Можно передвинуть важные данные поближе к началу, и при загрузке по сети или другом стриминге не загружать остаток файла.
Наконец, если формат и так предоставляет возможность хранить метаданные, то почему бы и нет?
То есть, это плагин, который берёт текст человека, переписывает его машиной так, чтобы человек или машина на там конце провода подумали, что он написан не машиной, а человеком?
Понял, я что-то подумал, что «первых анимаций» — это про анимацию открытия.
Засовывать в обёртку какую-то обработку событий — это не дело конечно, но это и не значит, что она была бы полностью бесполезной. Например, можно возвращать null и не монтировать «тяжёлую» часть можно только пока компонент не был виден ни разу.
Модалка не открывалась ни разу: Обёртка возвращает null
Модалка открыта: Обёртка возвращает return value модалки.
Модалка снова закрыта: Обёртка возвращает return value модалки, но он равен null.
Чтобы хранить состояние «было открыто хотя бы раз», нужен один реф на каждый экземпляр обёртки. Не очень много.
После закрытия модалки её стейт останется в памяти — это да, но сколько модалок юзер должен протыкать вручную, чтобы это стало ощутимо заметно?
Да, дурацкое SEO с этим придурочным лайтхаусом, где почему-то решили, что юзер не хочет пялиться на пустой экран пока скрипты загрузятся, распарсятся и исполнятся.
Динамика с адекватным cache-contol + CDN тоже неубиваемая штука
Яростно плюсую насчёт раздельных запросов. Http/2 уже десять лет как везде поддерживается, оверхед у трёх параллельных запросов уже почти нулевой. А один-два из них, глядишь, и попадут или в кэш браузера, или в кэш эджа CDN; и скорость ответа быстрее, и нагрузка на бэк меньше.
Стили конечно особняком стоят, соглашусь. Но тут есть нюанс: Бандлер постарается сохранить порядок импортов в выхлопе, но совершенно не факт, что у него это получится если структура чанков станет сложнее плоского списка: при наследовании энтрей и аснхронном импорте. Хорошо, что у нас теперь есть @layer, и мы можем вручную устанавливать специфичность, а не полагаться на порядок импорта!
А IDE — ну так у IDE есть оператор. Вводить автомат чтобы он огородился от действий других автоматов — Скайнет уже победил?)
Чувствую, что нахватаю минусов, но… не очень понимаю, зачем люди сортируют импорты.
От этого же нет практической пользы: машинам наплевать на порядок, а люди всё равно эту простыню импортов не читают и проматывают сразу на реализацию.
Я видел мерж реквесты, которые откладываются на день из-за неправильного переноса строки между импортами. Я видел мерж конфликты от того, что кто-то решил отсортировать импорты по алфавиту. Человеческие усилия и время впустую, и чего ради?
Кажется, вы изобрели японскую ISO-2022-JP, со всеми её минусами. Из-за переключения режима кодирования эта кодировка сложна при обработке строк и создаёт риски XSS, настолько, что современные браузеры её или не автодетектят или вообще не поддерживают.
Её «младшая сестра» Shift-JIS проще, но даже её уже почти полностью вытеснила UTF-8.
Ну вот я не вижу, где в примере о бронировании номера хоть какая-то транзакционность или просто атомарность. Незанятость номера проверяется, ага. А если через 1 мс она изменится потому что кто-то другой забукал номер? Если всё это завёрнуто в одну большую транзакцию, то где обработка нарушения ограничений при её коммите?
Похоже, что эти безусловно красивые абстракции только помешают довести этот прототип до уровня production ready
Пишу: для получения списка элементов (например, имена файлов или список урлов, ничего не писал про их содержимое!), нужно прочитать объект-коллекцию (например, директорию), вы говорите, что это штука инородная и чуждая.
А потом говорите, что чтобы получить метаданные файла нужно прочитать файл директории.
Просто мысли вслух по поводу круда (не статьи), если позволите.
Мы можем создать элемент, прочитать его, обновить и удалить. А как насчёт получить список элементов? В этом месте говорят: легко! Это тоже Read, но не элемента, а коллекции. Но по такой логике создание и удаление элемента — это просто обновление коллекции, верно. Тогда зачем в C.R.U.D нужны C и D?
Промахнулся и не туда ответил. Сорри. «Чем лучше чанки, чем дописывать в конец?»
Всяким минификаторам и библиотекам можно сказать не трогать чанк. Например: Пнгшка генерится с упором на скорость, а потом хочется сжать её получше для долгосрочного хранения.
Любое количество чанков хорошо дружит между собой, а «вконецфайла» всего один. Например: Пользователь захочет криптографически подписывать содержимое, а подписывалка тоже пишет данные в конце файла. Потенциальный конфликт.
Кастомные чанки можно двигать вперёд и назад. Например: Можно передвинуть важные данные поближе к началу, и при загрузке по сети или другом стриминге не загружать остаток файла.
Наконец, если формат и так предоставляет возможность хранить метаданные, то почему бы и нет?
То есть, это плагин, который берёт текст человека, переписывает его машиной так, чтобы человек или машина на там конце провода подумали, что он написан не машиной, а человеком?
Заняться нечем?
Плохому менеджеру код-ревью мешает
В этом случае делайте так же, как IDAT: если все данные не влезают в один 2 Гб чанк, создайте второй
Хи (χ). Пусть она и пишется chi, но в словах греческого происхождения ch произносится как к (на крайняк как х): alchemy, technology и т.п.
Понял, я что-то подумал, что «первых анимаций» — это про анимацию открытия.
Засовывать в обёртку какую-то обработку событий — это не дело конечно, но это и не значит, что она была бы полностью бесполезной. Например, можно возвращать
nullи не монтировать «тяжёлую» часть можно только пока компонент не был виден ни разу.Модалка не открывалась ни разу: Обёртка возвращает
nullМодалка открыта: Обёртка возвращает return value модалки.
Модалка снова закрыта: Обёртка возвращает return value модалки, но он равен
null.Чтобы хранить состояние «было открыто хотя бы раз», нужен один реф на каждый экземпляр обёртки. Не очень много.
После закрытия модалки её стейт останется в памяти — это да, но сколько модалок юзер должен протыкать вручную, чтобы это стало ощутимо заметно?
Про анимацию немного не понял, о чём речь
Можно же возвращать из компонента
nullпока модалка не открыта и не нужна?— А вы не боитесь, что они у вас обучатся и уйдут работать в другое место?
— Нет, я боюсь, что они ничему не научатся и останутся.
Да, дурацкое SEO с этим придурочным лайтхаусом, где почему-то решили, что юзер не хочет пялиться на пустой экран пока скрипты загрузятся, распарсятся и исполнятся.
Динамика с адекватным cache-contol + CDN тоже неубиваемая штука
Яростно плюсую насчёт раздельных запросов. Http/2 уже десять лет как везде поддерживается, оверхед у трёх параллельных запросов уже почти нулевой. А один-два из них, глядишь, и попадут или в кэш браузера, или в кэш эджа CDN; и скорость ответа быстрее, и нагрузка на бэк меньше.
Стили конечно особняком стоят, соглашусь. Но тут есть нюанс: Бандлер постарается сохранить порядок импортов в выхлопе, но совершенно не факт, что у него это получится если структура чанков станет сложнее плоского списка: при наследовании энтрей и аснхронном импорте. Хорошо, что у нас теперь есть
@layer, и мы можем вручную устанавливать специфичность, а не полагаться на порядок импорта!А IDE — ну так у IDE есть оператор. Вводить автомат чтобы он огородился от действий других автоматов — Скайнет уже победил?)
Чувствую, что нахватаю минусов, но… не очень понимаю, зачем люди сортируют импорты.
От этого же нет практической пользы: машинам наплевать на порядок, а люди всё равно эту простыню импортов не читают и проматывают сразу на реализацию.
Я видел мерж реквесты, которые откладываются на день из-за неправильного переноса строки между импортами. Я видел мерж конфликты от того, что кто-то решил отсортировать импорты по алфавиту. Человеческие усилия и время впустую, и чего ради?
Кажется, вы изобрели японскую ISO-2022-JP, со всеми её минусами. Из-за переключения режима кодирования эта кодировка сложна при обработке строк и создаёт риски XSS, настолько, что современные браузеры её или не автодетектят или вообще не поддерживают.
Её «младшая сестра» Shift-JIS проще, но даже её уже почти полностью вытеснила UTF-8.
Ну вот я не вижу, где в примере о бронировании номера хоть какая-то транзакционность или просто атомарность.
Незанятость номера проверяется, ага. А если через 1 мс она изменится потому что кто-то другой забукал номер?
Если всё это завёрнуто в одну большую транзакцию, то где обработка нарушения ограничений при её коммите?
Похоже, что эти безусловно красивые абстракции только помешают довести этот прототип до уровня production ready
SQL-транзакций в языке бизнеса нет, поэтому и в коде не будет?
Я вас не понимаю.
Пишу: для получения списка элементов (например, имена файлов или список урлов, ничего не писал про их содержимое!), нужно прочитать объект-коллекцию (например, директорию), вы говорите, что это штука инородная и чуждая.
А потом говорите, что чтобы получить метаданные файла нужно прочитать файл директории.
Ну как так?
Я имею в виду самый обычный листинг. Чтобы получить список файлов в папке, не обязательно же читать их содержимое?
Understandable, have a nice day.
Просто мысли вслух по поводу круда (не статьи), если позволите.
Мы можем создать элемент, прочитать его, обновить и удалить. А как насчёт получить список элементов?
В этом месте говорят: легко! Это тоже Read, но не элемента, а коллекции.
Но по такой логике создание и удаление элемента — это просто обновление коллекции, верно. Тогда зачем в C.R.U.D нужны C и D?
Тут опечатка? Потому что изменять и модифицировать — это вроде одно и то же