SherbakovFirst, та, идеальный код это миф) Главное чтобы приносил пользу(профит компании, удобство пользователям продукта и тп и тд от контекста), минимизация дыр в безопасности, удобство разработки(прежде всего в команде) и производительность. Примерно в таком порядке. И тк польза на первом месте, то нередко легаси и тп может быть весьма странным.
Поэтому в целом по жизни отходите от задачи, потом от понимания кода(командой, но и в тч собой, чтобы через пол года открыв было понятно что тут), а потом уже оптимизации и правильные вещи. Нередко две последние связаны между собой, ну и со временем уже параллельно в голове работает. Но стараться сделать идеально, да даже хорошо с первого раза, бывает вредно для главной задачи.
Скорее всего всё же дело в настройках в соответвующем .env файле. Проверь для dev окружения, вдруг там другая БД или что ещё из этого контекста не то указал.
zorro222, иногда и обществу. Но в контексте работы фронтендера в подавляющем числе случаев это работодатель, в том или ином виде: напрямую повышая его прибыль, либо решая проблемы их пользователей (к примеру повыщая отзывчивость интерфейса) и уже косвенно повышая прибыль.
В целом нужно мыслить категорями продукта, и то что часть вашей работы - это важные этапы создания продукта.
Так же можете почитать ещё про Agile подход в целом и про Scrum в частности, последний у нас наиболее часто пытаются использовать в компаниях(с переменным успехом). В целом знаниея Scrum уже хороший плюс при трудоустройстве во многие команды/компании.
Froggyweb, не фу, а ок — это же просто пример для другой части вёрстки. Но вы правы, что я не задумался зачем так автор вопроса мучался. Спасибо за указание Антон Литвиненко тут можно блок с текстом вывести в оверлей. Обновил пример
Такой код не катит, выложи кусок этот рабочий на Codepen/Jsfiddle
PS а разгадка вопроса кроется что absolute нужно использовать в крайних случаях. В вашей ситуации можно сделать просто на flex
happyofheaven, кредиты дают не только банки. К тому же если у вас нет нарушения законодательства, то и нет проблем.
Ещё раз подчеркну.
Конечно же, если нет возможности взять кредит, нужен рост и тп и тд, то варианты только искать ангелов/венчурные фонды.
Просто помните, кредиты - самая выгодная штука. Свои деньги на месте, доля на месте, рост есть.
А для стартапа (если вы стартап) только рост и есть топливо и жизнь. Нет роста - не стартап, не интересно и тп. Ну кроме случая, когда вы уже лидер и всё захватили в своем сегменте. Тут уже думать о повышении доходности, либо продаже себя. В зависимости от целей.
Мой основной месседж все-таки помнить про кредиты и не закрывать для себя такую возможность из-а стереотипов, которые прежде всего идут от потребительского кредитования. Где ты потребляешь, нередко просто потакая слабостям, а не зарабатываешь. Разница принципиальная.
mifa, безусловно. Это один из лавных стереотипов начинающих или относительно мелких предпринимателей.
Более того, кредит даже выгоднее чем вложение личных средств.
При верной стратегии, хорошем кредите и нужном уровне роста, у вас с кредитами просто выходит бесплатный генератор денег. Свои личные деньги при этом вкладываете в депозиты/что-то другое выше инфляции.
Свои деньги тратить на стартап минимум минимум, желательно только чтобы запустить продажный лендинг с рекламой/описанием вашего продукта, ну или на первое MVP.
Далее, если есть продажи, сходится юнит экономика и дают кредиты, рост исключительно за счёт кредитов..
а вот если пока минус выходит, но есть бешенный рост, можно подаваться к инвесторам
Если мне не верите, можете взять бумажку, эксель и тп и убедиться, что кредиты для бизнеса почти всегда перебивают выгоду инвесторов, которые съедают вашу прибыль и долю. Это даже актуально для стартапов которые делают под продажу, хотя там относительно чаще прибыльных выгоднее идти к инвесторам.
С кредитами в основном проблема что тут чувствительнее относятся к вашей репутации и не везде есть интересные условия и нужные суммы сразу.
Я настоятельно рекомендую прежде всего исходить из получения кредита. если с стартапом бизнесом все хорошо и нужен дешевый рост. Инвестиции — это уже дорогой рост. А если с кредитом у вас не сходится маржинальность, это значит и инвесторы будут на такую маржинальность смотреть скептически.
Ну и в целом конечно всё зависит от ваших планов.
Короче задумайтесь
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 ключами, нужно изучить этот вопрос.
Короче говоря, трудности, описанные мной, не повод прям бросить. Другое дело если вы строили тот или иной комерческий проект, там не сходит юнит экономика и тп. Тут отдельная тема конечно же.
Поэтому в целом по жизни отходите от задачи, потом от понимания кода(командой, но и в тч собой, чтобы через пол года открыв было понятно что тут), а потом уже оптимизации и правильные вещи. Нередко две последние связаны между собой, ну и со временем уже параллельно в голове работает. Но стараться сделать идеально, да даже хорошо с первого раза, бывает вредно для главной задачи.