Lynn «Кофеман», возможно, перегрузку имеет смысл использовать, когда комбинаций действительно много, и/или типы данных какие-нибудь специфические? Но в этом случае, скорей всего, будет смысл вообще сделать разные функции, а то получится что функция слишком много всего делает. Хотя суть примеров с nodejs мне ясна, но полагаю, реальная необходимость использовать перегрузку возникает не так часто?
atumbochka, т.е. вам нужно именно прям сам файл изменить? Недавно писал небольшой скрипт для минификации картинок, может, пригодится. По сути именно это и делает - берет картинки из папки и меняет ширину, высоту и качество. Возможно, вам немного придется переделать под свои нужды.
Это какой-то чисто спортивный интерес?) Ума не приложу, для чего такое может понадобится.
Можно отправить пост-запрос с фронта, и в тело передать текущие размеры окна браузера.
Ankhena, я в итоге сказал дизайнеру, что он придумал дичь, и мы решили отказаться от этой идеи))
С vw теоретически можно заморочиться, но там адская функция получится, т.к. надо еще учесть ширину общего контейнера (которая тоже на разных брейкпоинтах разная), сайдбара, всяких паддингов... В этом случае проще, наверное, на js что-то написать. А еще проще - немного пересмотреть дизайн, что мы и сделали)
Ankhena, тогда каждый .grid-element будет шириной по 50% от родителя. В каждой строке каждого .grid-element будет по две карточки. Выглядеть будет вот так. Собственно, код, который я привел в вопросе так и делает. И если в каждом .grid-element хотя бы по две карточки, то всё супер.
Проблема же в том, что если, скажем в первом .grid-element одна карточка, то он все равно занимает 50% от родителя. Мне же нужно, чтобы его ширина сокращалась до ширины этой одной карточки, т.е. занимала 25% от родителя. Причем, ширину карточки я тоже не могу задать статично, она разная при разной ширине экрана.
А если, скажем, три карточки - то третья переносится на новую строку в том же контейнере. То есть у .grid-element должна быть как бы min-width 25% и max-width: 50%.
Георгий Еремеев, спасибо, но, боюсь, это совсем не то. Базовая структура должна остаться неизменной, т.к. у меня в дочерних гридах еще много чего есть, помимо карточек, да и сайт динамический, и я заведомо не могу знать, где и в каком месте должен будет находится .grid-two
, а в props this.component_path кладу путь на уровне папки вызывающего import компонента.
Вообще так себе решение, конечно, надо все равно подумать, как сделать более универсально.
Да это довольно незамысловатый (хоть и здоровенный) json на выходе. А те связи, что там есть - настолько простые, что там просто нет смысла дискутировать о реляционной или документоориентированной природе. Разницы в данном случае нет.
В любом случае, в итоге так и сделал, как вы предлагаете, в этом действительно гораздо больше смысла, чем в этих попытках преобразований)
WapSter, это означает, что подобное вообще невозможно? Или возможно, но ценой низкой производительности? Мне просто доводилось делать простые связи между разными сущностями в mongodb, поэтому я знаю, что связи в целом там возможны. Поэтому уточняю, что именно имеется в виду под "не предназначена")
Антон Тихомиров, я, кажется, нигде не написал, что php не нужен) Но тем не менее, да, он нужен далеко не везде. Вы наверняка сами знаете, что бэкенд можно написать на питоне, на ноде, да хоть на джаве, а можно вообще использовать какой-нибудь firebase. И не очень понятно, почему вы считаете, что это плохо? И что плохого в возможности использовать уже готовый php и api cms-ки в качестве headless? Когда клиентская часть полностью и собирается на клиенте, а бэк - только для админки и апи-запросов. Если, конечно, речь не идет о написании какой-нибудь мощной и сложной web-app. Да и в целом, это же естественный процесс - одни языки и инструменты отмирают (хотя, повторюсь, к php это пока не слишком относится), другие появляются. Разумеется, со временем вообще не станет никакого php, никакого js, а будет что-то совершенно другое.
В моем случае не сработало. Скорей всего, если в точности воспроизвести полностью вашу сборку - не только конфиг, но и версии пакетов, то сработает. Но у 5-го вебпака какие-то свои особенности... Решил в итоге не париться, а перенести всё в rollup, как рекомендовали в комментарии.
По идее, никак. Сначала выстраивается DOM-дерево, применяются стили, и только потом отрабатывает js. Можно просто скрыть блок изначально, а когда код отработал - симпатично анимировать его появление.
PS. $('#checkbox').click() - плохая идея, лучше использовать $('#checkbox').change().
