wakenbyWork, вопрос холиварный.
Миксины как вы видите несут в себе подводные камни.
Общее правила такое: использовать модификаторы всегда, когда возможно и логично. Если видно, что в других элементах дублирования кода, это повод задуматься о миксах.
При этом миксы крайне желательно чтобы обозначал всякие нестандартные вещи, которые в базовом элементе/модификаторах не использует и не пересекается.
Те в вашем случае это прям стандартная модификация(width), почему микс?
Нужно так разделить модификаторы и миксы, чтобы избежать дублирования кода.
Вот и смотрите.
Что может быть в button - ага, там цвета, форма, размеры, цвета.
А вот в миксе button__card - ага, тут могут быть внешние отступы, какие либо свойства которые отвечают за взаимодействия с окружением внутри родителя (условно позиционирование, марджины).
Вот тогда куча проблем исчезнет.
В целом это все делается ещё с дизайнером на уровне проектирования, тут нередко сами дизайнеры могут подложить бомбу, нужно с ними заранее договариваться о принципах и правилах. Разбираются стандартные элементы и вкладывается логика сборки всего в удобную структуру. Отдельно разбивается сам вид базовых элементов (шрифты, паддинги, оформление). Отдельно как они могут быть внутри других элементов (вот тут уже могут появляться миксины).
Вот так и будет складываться. поэтому начинаете в любом случае с модификаторов, если видно, что модификатор выходит за рамки логики элемента (как независимого), тут можно подумать о миксинах.
Это всё примерно описал, лучше согласовывать с командой и дизайнером.
wakenbyWork, а в чем экономия? К тому же логика БЭМ немного нарушается тогда. Ну и вот, выскакивают такие проблемы.
Вы конечно можете просто написать хитрую логику сборки, перепридумать структуру папок чтобы угадывать специфичность и тп. Но ИМХО это переусложненным проект выйдет.
Я бы совместил советы из первого комента с нормальным БЭМ где он нужен.
Позволит всё упростить и уменьшить повторяемость кода.
Сергей delphinpro, а, я не понял, что вы имели в виду конкретное содержание. Тогда да, я чёт подумал про абстрактное содержание, не просто width, а может там разные. Тогда конечно же это обычные стандартные модификаторы.
Сергей delphinpro, где размещать уже варианты, зависит от практик в проекте.
Лично я тоже склоняюсь к вашему(хотя могут быть варианты), но написал иначе, чтобы быть ближе к тому, что у топикастера (как мне показалось).
vigaset12, тут история относительно "старая" уже. основные споры были 2012 - 2014 годах.
Если кратко:
- рост популярности и мощности мобилок, они заметный, либо даже основной клиент
- рост производительности, css будет применяться не десктоп версия, а затем дангрейды для омбильных, а в начале общие свойства + мобильные, а потом модификации усложнения десктоп версии.
- зачастую меньше кода, если есть сверху вниз, либо указывать min max, будет слишком много повторения кода. А так, делая отсечения по min-width у вас всегда будет возможность добавить необходимые изменения для большего ширины. понятно что возможно исключения, но это исключения. В целом правила работает.
- ну и проще и понятнее сам код, ты видишь в одном месте основной код css, а далее модификаторы для брейкпоинтов. Удобно всё даже в голове выстраивается
- снова таки, конечно такой подход удобен где адаптивная вёрстка. Если вы строете сложную ERM//CRM, то у вас скорее всего будут отдельные версии мобильная и десктоп, слишком сложная будет адаптация. И там мобайл фёрст подход будет лишним, если основное устройство это компьютер.
В целом можете погуглить про этот вопрос, статей на этот счёт много.
Так же изучить подход например того же Tailwind, как они через модификаторы сделали суперлегкую адаптивность, что зачастую даже css почти не нужно писать (не факт что всегда этот подход лучший. но нередко удобно чтобы быстро что-то собрать). Либо же более классический Bootstrap, но у них тоже подход mobile first.
Так что если кратко: оптимизация кода, оптимизация производительности, более мягкая и понятная адаптивность сайта.
Отдельно отмечу что и верстать и рисовать(макет) нужно в этом случае тоже начиная с мобильной версии. Таким образом будет меньше логических ошибок, ну и значительно быстрее работа пойдёт.
vigaset12, нет. Сегодня принято писать в rem исходя от базового значение шрифта по умолчанию 16px. В пикселях только тени, ширина границ, фильтры(blur).
А так. начиная проект:
определяете точки срабатывания media queries(снизу вверх), лучше подсмотреть у лидеров эти ключи, бутстрап или tailwind
верстайте мобильную версию.
Делайте нужные модификации для нужного разрешения от меньшего к большему. Конечно же не все ключи разрешения нужны в каждом проекте, поэтому не обязательно их всех заполнять/использовать
primitiv, почему. Не бросайте идею. В целом это отличная практика. Такой проект сделать интересно.
Далее, можно ещё сразу его делать opensource и возможно даже приглашать друзей, знакомых для разработки.
Далее, если у вас бесплатное приложение, то часть нагрузки вы можете распределить, допустим энтузиасты будут ставить его к себе на хостинг и использовать свои ключи api (многие api привязаны к ip или url сервера, поэтому просто иметь у каждого свой ключ не всегда выйдет).
Поэтому в любом случае советую не бросать, возможно трансформировать даже в мобильное приложение (сегодня для этого не сильно много кода нужно менять, а в случае android можно даже просто apk выкладывать на сайте), там может будет легче и с api ключами, нужно изучить этот вопрос.
Короче говоря, трудности, описанные мной, не повод прям бросить. Другое дело если вы строили тот или иной комерческий проект, там не сходит юнит экономика и тп. Тут отдельная тема конечно же.
JRBRO, мне кажется вы немного усложняете. Лучше взять небольшую png, сделать в ней основу сетки с нужным шагом, потом повесить поверх экрана сайта нужной ширины див, ему задним фоном с повторением эту пнг. Ну основную идею вы поняли. Выйдет и гибко(можно подготовить несколько пнг с разных шагом) и удобно и не нужно говородить тысяча пятьсот элементов в ДОМ
Немного непонятен ваш подход. Лучше написали какую проблему нужно решить и какая задумка. Возможно, в целом подход неверный и вам нужны к примеру разные layout.
damarkuzz, там кастинг из массивов. В документации ларавел всё есть.
Ещё отдельно хотел отмтеить касаемо моего ответа, лучше наверное сделать отдельные поля в таблице title и тп, а уже внутри них en : blah blah
А в целом, для этих целей возьмите пакет https://github.com/spatie/laravel-translatable , там трейт для ваших моделей, которые всю рутину возьмёт на себя. Очень удобный.
gmtd, а в чем проблема. Не выходит с sail, так установите себе любой локальные сервер сборку, тот же laragon, правьте на здоровье. Sail то всего лишь обертка помощник для докер окружения, чтобы разрабатывать сильно прям не нужен(но конечно хорошо, чтобы у всех разрабов было похожее окружение.)
VladislavNaida, ну он выходит совсем неизвестен? Ведь ограничения же будут, у вас же там потом, после условного explode (не важно), будет логический разбор. Как я понял, это категория, и далее подкатегория, под под категория и тп
А так. Тогда нужно залочить функции/методы в одном месте(ну те выходит в двух) условный сбор/разбор всей вышей штуки.
Возможно написать свой хелпер обёртку вокруг route(name, params[]); который будет выглядет типа route_endless(name, params[]), а уже внутри объединяет массив со slug категорий в строку path и передаёт уже в route(name, ['path' => $path]).
Так же и обратный разбор вывести, например в свой новый миддлвар в котором вы необорот разбиваете эту строку, для работы уже в методах контроллера с массивом данных. Таким образом уменьшить шанс человеческих ошибок, типа той что у вас случилось.
Как я понял, раз нет 404, то вы валидируете только последний параметр. Если у вас там есть запросы в БД и по другим параметрам(ну допустим вы выводите из названия и тп) то наверное имеет смысл и их тоже проверять, чтобы в таких урл была 404.
Короче здесь нужно немного архитектурно поработать и де факто продублировав часть "волшебного" функционала ларавел под себя.
VladislavNaida, как мне кажется не очень удачная идея, выходит это 89 строка и вы потом сами раскладываете категории и подкатегории? Почему бы тогда их тут сразу не расписать /catalog/{type?}/{subtype?} ?
Сергей delphinpro, я не говорил что всегда лучше. Тут скорее практический подход. Просто есть нюансы, дедлайн и тп. Поэтому нужно принимать решение в зависимости от этого. Просто остальные варианты мы ему рассказали, поэтому далее уже выбор за человеком.
То, что вполне рабочий вариант, когда передают уже готовую верстку - тоже верно. Лучший он? Нет. Но используется повсеместно, не такая уж и редкость.
Sergio Kuspekov, лучше использовать то что вам удобно. Ведь главное качество и время.
А так, повторюсь, отдадите готовые html/CSS/js статику, человек сам потом разобьёт на шаблоны.
Но вы можете и сами сразу писать вместе с ним, в тч в одном репозитории. Шаблоны будут blade (там простая схеме, как во многих других шаблонизаторах), а для JS/SCSS Laravel Mix - обертка над Webpack с упрощенным удобным синтаксисом.
Евгения Сатонина, В идеальном случае конечно ту, в котором у вас траты и платежи.
Кстати многие используют американский доллар даже если своя валюта, тк у них оплата эдсенс в $ и основные траты(хостинг и бОльшая часть издержек в $), так делают многие цифровые сервисы. В целом в вашем случае лучше всего подойдет в $.
На самом деле, не столь принципиально, если прям не используется сквозная аналитика и всякие автоматические выгрузки в бухгалетрию и тп для высчета налогов, всяких других штук.
Короче говоря выбирайте для себе наиболее понятную валюту и используйте её.
