<ul class="us-footer-list list-unstyled">
{% for information in informations | slice(6, 6) %}
<li class="us-footer-item us-footer-information"><a href="{{ information.href }}" {% if information.rel is defined and information.rel %}rel="nofollow"{% endif %} class="us-footer-link">{{ information.title }}</a></li>
{% endfor %}
</ul>
PS по хорошему конечно на самом бекенде/опенкарте нужно делать два отдельных массива informations, независимых друг от друга и со своими данными внутри. Это так, быстрое решение.
BranchInCode, я поэтому и уточнил.
В вашем случае выбирайте удобный шаблонизатор и делайте в нём. Иначе выйдет что вы будете городить свои велосипеды. Я дал пример просто для статичных html файлов, думал вы хотите их вывести.
picka, сути не меняет. Вы запускаете в ручную, процесс работает, пока у вас открыта консоль(так как в ней же и запущен). pm2 делает так, что процессы работают независимо (плюс доп фишки, но это отдельная история).
Сам скрипт запуска node server/index.js
С помощью cross-env мы можем делится переменными, в вашем случае NODE_ENV=production.
Поизучайте документацию pm2, там можно сгенерировать файл конфигурации pm2 ecosystem, а далее в нём рулить
Horder, может зная размер файла вы эмпирическим(чтобы не тратить время на проверку размера) путём будете разбивать его, допустим новый файл раз в день/час или другой промежуток.
Может дело в размере и/или количестве записываемых в потоке данных.
Я тут точно сейчас не скажу, уже не помню, но для атомарной записи вроде бы важен размер кластера файловой системе. Попробуйте покопать в эту сторону.
Rouslan943, ну начнём с того что может и js в браузере, в независимом поток(в Service worker) делать какие-то тяжёлые вычисления. Или выполнять сетевой запрос и ждать ответа.
Но значения кто делает это вторично. Суть в том, что с помощью асинхронности мы делаем две штуки:
-не блокируем основном поток.
-знаем что ждём результата для выполнения дальнейшей логики.
Сегодня основной и более удобный способ это использовать Promise(промисы, обещания) - у них хорошо читаемый синтаксис, встроенная поддержка ошибок, ну и сразу ясна логика работы.
Старый, но всё ещё живой, через колбеки. Где мы в параметры фукнции передаём ссылку на другую, которая как бы и будет ждать результата. Этот способ не плохой, но у него больше ручной работы для обработки ошибок и гораздо хуже читабельность хода при сложной логике запросов/ожиданий(куча мемов на этот счёт даже есть, callback hell).
Вот советую ознакомится с простым и понятным руководством на эту тему: https://developer.mozilla.org/ru/docs/Learn/JavaSc...
Антон В., смотрите. Эти два мидвара изначально добавлялись из расчёта умолчаний и максимального использования "волшебства" Оаравел для уменьшения кода. А значит подразумевалось использование массовых присвоений и чтобы это всё работало, без лишних доп проверок, а просто на автомате с валидацией автоматической и автоматическим присовением, ввели эти два мидлвара, так как очень часто делали: обрезку пробелов, и в null пустые строки.
Насчёт null вместо пустых строк, да и вообще в null в mysql и подобных:
- не нужен null не делайте его. Зачастую он не нужен, а на производительность он влияет отрицательным способом.
Про строки: почему null, потому что хранение пустой строки в базе - это все таки хранение информации. И дело тут не в объеме информации, а в логическом смысле и архитектуре-логики приложения в целом. Если нам важно знать и отличать наличие инфы и её отсутвие, тогда уместно использовать null в mysql, чтобы работали все встроенные функции типа LENGTH, сортировок, COUNT. поэтому и в ларавел есть удобное обертки типа whereNotNull и тп и тд.
Супероптимизации БД не должна вас заводить в рамки, мешающими работать логике приложения. Но это не значит что на всё нужно забить, везде null, никакой нормлаизации Базы данных и тп.
Как то так, если кратко.
Владислав Лысков, так я с этим по большей же части и согласен. Я больше поражен что предложено использоваться однозначно неподходящий для этого инструмент. Ну и в споре истина рождается, так что.. может я хочу учиться новому. Вот учусь в общении.
jazzus, ну как нет. https://laravel.com/docs/8.x/seeding - нужно использовать исключительно для:
-автоматизация тестирования в целом
-сидирования базы данных на машине разработчиков чтобы легче и быстрее строить/дебажить приложения.
ВСЁ. Дальше, будут только костыли, проверка чтобы кто-то не то запустил и тп.
И даже если вы пройдётесь по топу гитхаба(согласен что не показатель, но) вы там в сидерах не увидите ничего, кроме непосредственно сидирования базы данных только для нужд тестирования и разработки.
А вот использования миграций для разных целей, попадается постоянно, тк это намного безопаснее и прямо подразумевает открытым способом изменения в БД(изначально задумывалось только схемы, но..)
Просто даже банальный пример, у чего то в БД нужно поменять допустим префикс, я конечно сделаю миграцию и пройдусь по всем значеним(ну после изменения логики работы уже внутри приложения.)
Вот примеры от других разработчиков:
BookStack - приложение для организации документации и около того, установки и создание ролей поумолчнию.
Spatie - одни из крупных популязаторов и разработчиков пакетов для Ларавел, у них множество примеров, вот на их оф сайте например есть такая миграция да и другие там есть, и в целом они миграции в этом ключе используют.
Laravel-Backpack у себя ив демо и в других штуках бывает
Ну короче. Снова таки, я не говорю что это прям хороший патерн и тд и тп, но довольно часто он таки не антипатерн. позволяет в некотором роде использовать и автоматизацию и гит для контроля БД и тп.
В основном конечно встречается не обычных библиотеках, цмсках и тп, а в продуктовых решениях, где есть кейсы допустим хранения поддерживаемых языков и бывает что-то меняется(ну ввели вначале что просто ru, en и тп, а потом поняли что нужно ru_RU, en_US и тп ) и бывает такую логику удобнее всего писать именно в миграциях из-за прозрачности работы.
А использования db:seed портит многое, нарушает и принципы для чего создан механизм(блин да там даже по набору инструментов видно что это для тестирования и или локальной разработки), легче совершить фатальную ошибку с рефрешем всего, те нужна доп слежка, доп ключи для обхода защиты на продакшене и тп и тд. Да и тупо в сидерах будут лежать не те классы что ожидаешь. Ну камон.
jazzus, ну допустим разный опыт, разные проекты и тп.
А насчёт миграций советую пересмотреть ваше отношения. Очень удобный инструмент, удобно что потом он и в гит и тп отправляется. Всё работает прозрачно в плане populate my database. Или изменений чего либо.
Миграций вовсе не только для создания и изменения таблиц.
И я могу спокойно знать что моё приложение развернется так, как я хочу. Либо обновится у клиента так как я хочу и тп.
В общем кейс и использование распространенное, не всегда лучший вариант, иногда вредный, нередко полезный и удобный. Каждый раз принимаются решения в зависимости от ситуации.
Вот db:seed для случаев отличных от разработки и тестирования - зло однозначно
FanatPHP, пример же условный, всё оттачивается уже на конкретных сценариях и тп. Потом даются реокмендации и тп. Более того, саму генерацию картинок можно и делать отложено после загрузки, зная популярные форматы что будут использоваться..
Ну короче, дальше уже дело касается конкретных сценариев работы.
jazzus, ну вот, вы сами аппелируете к документации, где прямо и написано что сидирование(seeding) в ларавел - для тестов. Это даже видно из логикии работы механизма, различных фейкров и автоочищения и запрета на продашене запускать.
Насчёт миграций, то так делают люди в реальных проектах.
Это нормально, удобно и прозрачно.
Повторюсь, не для всех кейсов.
Но:
-позволяет легко и прозрачно откатится, как и с обычными миграциями
-позволяет дальше регулировать и менять данные(или это тоже не в миграциях делать?)
Ну к примеру, храню я роли и название ролей по умолчанию не в хелпер классе статитикой, а в базе данных.
Вот создал миграцию, упростим, айди роли, название роли, права.
Следующей миграцией я ее заполнил: Админ, Модератор, Юзер.
Пользуемся всё ок.
Потом решили что лучше пусть Юзер будет Пользователь называться
делаю новую миграцию, переименовал.
Чем это лучше чем в админке? А тем что у меня остается чёткость, история изменения и если я разворачиваю свое приложение где-то ещё(не важно продаю лия короболчное решение, или новый сервак, но с нулевой установкой и тп и тд), то всё будет как нужно.
Да полной кейсов когда это удобно.
Отдельно отмечу, что по хорошему часто могут нужны отдельные сервисы, алгоритмы и тп, возможно более сложные, встроеные в общую систему деплоя и развёртывания. Тогда миграции идут лесом, это отдельные классы и функционал для этой цели.
Ваш же совет юзать сидеры для этого через db:seed просто вредный, и потом, при росте приложения или расширения тестирования приведет к проблемам. Я уже молчу что там выстрелить себе в ногу ГОРАЗДО легче при развёртывании приложения. Тут даже спорить не о чем.
Повторюсь, если вам удобны эти фейкеры и прочие сид штучки, так их можно спокойно использовать в любом вам нужном месте приложения, своих сервисах и в тч миграциях, если вам нужно.
НО! Конечно же я бы тоже не советовал его использовать, сам навозился в свое время. Хотя, мне иногда говорят что в последние годы ситуация получше. А мне вот слабо верится, тк им то и не нужно делать лучше, их часто "советуют" или впаривают безальтернативно. А если продажи итак будут, зачем парится...
jazzus, а и кстати да, если вам нужен просто тот функционал, то конечно же в миграциях вполне можно использовать сид классы, когда это нужно.
Ну и отдельно отмечу. Можно, можно и в сидах делать эту логику, добавлять различные доп проверки и условия и логику, чтобы отслеживать что сейчас продашн и тп.. но это уже костыли и обход прямого предназначения автоматизации всего движа с artisan db:seed и тп. Этот инструмент не для этого затачивался
jazzus, занимаюсь. Вы просто слишком остро спорите. Скажу ещё раз, в целом насчёт миграций я согласен, просто отметил что их можно использовать и для наполнения БД начальными значениями, умолчаниями и тп.
Те сиды с ларавел(отмечаю ссылкой только чтобы сказать что мы говорим об одном и тоже) нее предназначены для этой цели, более того это вредит в дальнейшем, так как потом будет мешать и тестированию и тп. Прошу заметить что на проде по умолчанию даже нельзя их запустить. И я как раз это всё говорю и в рамках развития проекта дальше. Противоречий в этом нет. Те штуки о которых вы говорите делать в админке это отдельная история и другие кейсы. Здесь же ситуация как раз таки и развити проекта(в процессе разработки) и развертывания проекта. И очень много случаев когда удобно и заполнять и корректировать данные в таблицах именно в отдельной специально для этого нужной миграции.
И кстати в миграциях тоже все делается просто, без лишнего кода и, главное , остается та же поддержка отмены шагов и тп.
Повторю ещё раз: ваш супер вредный совет использовать это: https://laravel.com/docs/8.x/seeding для чего-то помимо штук касаемых тестирования приложения вредны. В миграциях в некоторых случаях можно и вполне ок, а часто нужно писать отдельную нормальную логику. В админках и тп это вообще отдельная тема.
jazzus, пф. Меняешь следующей миграцией.
Снова таки, я не говорю что это единственный и истинно праивльный путь. Я говорю что:
Эти сидеры - точно нет, разве что у вас просто проект вот прям на раз, быстренько набросали, запустили и забыли. А так нет.
В определенных сценариях устанавливать данные через миграцию вполне себе ок, так же пишешь логику и установки и откатки изменений. А потом если нужно можно и менять в дальнейшем следующими миграциями по необходимости. Снова таки, безусловно это на айс, но рабочее решении при многих ситуациях.
А так конечно же отдельная логика разворачивания приложения, где один из этапов пишешь свою, да даже через потом и в тот же артизан для удобства добавляешь команду php artisan dbpopulate, которая и будет делать всё что нужно.
А так... сильных ужасных подводных камней в заполнении некоторых данных в миграции специальной нет, выстрелить себе в ногу конечно можно, но в целом, при многих простых сценариях, допустимо.
jazzus, ну конечно. Поэтому я и написал зависит от ситуации. Тут тогда в целом и сами миграции не всегда удобны. Но конкретно инструмент сидов встроенные в ларавел таки предназначен и логически и по устройству и по работе в логие приложения ларавела для сидов тестовой базы в рамках различных видов тестирования приложения. Поэтому сами изначальные данные, вполне ок, при многих сценариях, заливать и в миграциях, тем более там можно соблюдать достаточную гибкость и абстракцию по необходимости.
Ну а так, в более сложных кейсах, это уже конечно же отдельная тема и рассматривается индивидуально.
PS по хорошему конечно на самом бекенде/опенкарте нужно делать два отдельных массива informations, независимых друг от друга и со своими данными внутри. Это так, быстрое решение.