Александр Талалаев

Сразу отмечу что Юрий Бура отличный профессионал своего дела, курс его не изучал, но беглый взгляд показал что поход у него хороший, системный и он старается все же доносить суть. Главная целье его курса научиться пользоваться реактом, понять суть современного подхода к фроентенду в целом.
Далее уже по существу. Нужно погрузится в саму историю и причны появления Реакта. Инженеры в facebook в одно время сильно замучались строить интерфейсы, генерировать всё эту ерунду было сложно, еще проблемы уязвимостей (куча форм, для комментарией, постов, картинко и тп), недобный и громозкий PHP код заставил их задуматься об упрощении. Хотелось писать интерфейс как обычну функцию с параметрами, поэтому они придумали xhp, которые позволил буквально писать формы сразу в php (hack), легко, наглядно. Быстро видно что происходит, меньше ошибок, и легко использовать код формы (вместе с всей ее логикой построения, это и генерация формы на основе данных, и тп) заного много раз. Этот же подход был очень удобен и для других частей интерфейса, меня, списка постов и тп.
И это, с развитием новых концепций, браузеров, технологий и требований к быстроте интерфейса вдохновила их перенести этот концепт на JS, так родился React. Его революционность была в том, что на выходе резко упростились любые манипуляция с интерфейсом на фронтенде, сильно упал порог входа, получили легко читаемый и понятный код для решения практических задач (понятно, что при желании можно и тут засрать, но до этого в принципе большенство интерфейсов на js писалось через большие муки, с кучей неудобного кода, компромисами и тд и тп, а теперь все это взял на себя реакт).
Что мы имеем:
есть какая-либо часть интерфейса, логически независимая от других, с определенной структурой внутри - делаем компонент. Компонент это не только то, что мы обязательно будем использовать повторно (например), но понятная логически обособленная часть интерфейса, у которой может быть своя логика внутри, и своя функция на сайте снаружи.
Ничего страшного если сразу всё не продумал или на определенном этапе что-то идёт не идеально и тп.
Конечно хорошо иметь план на проект и проектировать многие вещи сразу, но рефакторинг, пивоты, изменения - вот реальность жизни.
Так что не волнуйся, первое что сделай измени восприятие самого интерфейса и приложения в целом. Теперь ты делаешь не сайт на html, а приложение с интерфейсом. Вот когда в таком ключе смотреть, то намного легче.

Главный спорный вопрос который вам стоит решить: где хранить статичный первод (надписи, что не меняются или меняются редко, например название кнопки - Отправить/Submit, те все то, что мы обычно не храним в БД и редко меняем).
Варианта два:
1. Использовать только реакт для этого, тогда берете пакет react-localization, там достаточно простые и понятные принципы, сложностей нет.
Преимущества: фронт полностью отдельно живёт и не зависит от бэкенда, нет дополнительных прослоек, нет привязки к определенному бэекенду и тп

2. Использовать возможности локализации Laravel. Но тут все таки все методы той или иной степени костыльности, либо как минимум добавляющий жесткую привязку фронтенд приложения к текущему стеку бэкенда
Преимущества: можно использовать разные пакеты для интеграции средств редактивования статической локализации в бэкенде.

Лично я всё же склоняюсь к первому варианту, так как люблю писать максимально (желательно полностью) назависимые фронтенд приложения.

Теперь вторая часть вопроса. Уже касаемо динамических переводов (это контент, комментарии, и тп, условно говоря всё что мы храним в бд, или храними информацию о них в бд).
Здесь я советую положится на Laravel, берёте пакет от spatie laravel-translatable, он позволяет быстро строить удобные интерфейсы редактирования/чтения переводов в БД, пишете простое API и ри инициализации react приложения получаете данные нужные вам локализации, либо даже отправляете все сразу (они хранятся в json поле mysql/ваше БД, даже доп преобразований особо не потребуется).
Но вариант с отправкой только нужной мне нравится больше, смена локали событие редкое, а вот экономия на размере переданных данных будет существенная.

Ну, а далее уже вешаешь всякие кеширования тп, чтобы всё летало и готово.

https://jsfiddle.net/bvuco1hj/
Дичь со

.stars div {
float: left;
}

Убираем.
Далее, stars_inner делаем realtive, а красный фон абсолютом

.stars__inner {
  position: relative;
}
.stars__progress {
  background: red;
  position: absolute;
  left: 0;
  top: 0;
  z-index: -1;
}

Лично я советую два источника:
https://www.codetriage.com/ - специальный сервис который позволяет удобно структурировать опенсурс проекты по issue и языкам, и выбрать для начала работы.
https://cultofmartians.com/ - интересный проект, приглашение к участию от одной из самых крутых команд в рунете. Ставят задачи, потом есть шанс и подружится с ними ближе.

Если проект для себе, либо быстрые прототипы, проверки теорий и тп, то делайте так как привыкли и удобно.
Если проект относительно крупный, работает несколько человек, то должен быть какой-никакой а стандарт кодирования. И тут нужно уже задуматься а всем ли так будет удобно, а что потом при расширении, а какие подводные камни. В целом, при усложнении логики и куче кастомных компонентов, то почти всегда JSX как минимум легче читается.
Я лично когда что-то простое и прозрачное, не выходящее за рамки использования стандартных шаблонов Vue, о JSX не вспоминаю. Но а если надо мудрить, то так просто удобнее читать код, это как минимум.

Но повторюсь:

• маленький проект, быстрый, делаете лично вы - пиши как удобно и привык.
  
• что-то больше, несколько разработчиков - вы должны договорится о правилах и следовать им, использование JSX обычно будет хорошей практикой для написания и поддержки кода.
  

А так, Vue с JSX дружит, поддерживается.

Скорее всего настройки просто скешировались.
Выполните в консоле следующую команду
php artisan config:clear

Квизы (от англ. - quizzes - викторины), модный последние два года метод лидогенерации либо метод заставить пользователя проделать определенные шаги. Но в подавляющем числе случаев конечно же используется для сборы контактов.
К сожалению сегодня их стали слишком часто использовать там где не нужно.
Ну и да, один из кейсов это совмещение с чат ботом, что помогает сразу же направить человека к нужному специалисту, либо не тратить время менеджера на первичный опрос клиента, и тд и тп

Самый простой способ это:

public function page($slug) {
$page = Page::where('slug', $slug)->firstOrFail();

return view('template.pages', [
  'pages' => $page
 ]);
}

1. Проверить .env файл APP_URL= установи с https:// , хотя обычно это не влияет, но потенциально может использоваться где-либо и в зависимости от настроек http сервера выдавать ошибку.
2. Очищаем кеш настроек:
php artisan config:clear
php artisan config:cache
3. Очищаем общий кеш
php artisan cache:clear

Есть метод columns().data() - позволяет получать данные в ячейках из выбранного(по селектору) столбца(ов). Для отдельного столба аналогичная функция
Там же в примерах есть вот этот код:

var table = $('#example').DataTable();
 
var idx = table
    .columns( '.check' )
    .data()
    .eq( 0 ) // Reduce the 2D array into a 1D array of data
    .indexOf( '0' ); //Ищем нолик
 
if ( idx === -1 ) {
    alert( 'Нолик не найден' );
}
else {
    alert( 'Нолик найден' );
}

Уязвимости нет, в базе потенциально опасных пакетов опечатка на тип проверяемой версии, вот и вышло вместо проверки что версия не ниже 3.1.10 он проверяет чтобы было не ниже чем 3.110.
Насчет скриншота, я думаю он ругается так как вы при отключении интернета видимо выключили роутер(или отсоединили) и ваша внутренняя сеть упала, а значит адрес 192.168.43.201 стал недоступен.

$user = User::withCount('lists')
                    ->find(Auth::id());

Начну с того, что если вы таки активный разработчик и не очень можете понять этот принцип, возможно он вам просто не нужен. И это не значит что вы плохой разработчик, просто не пересекались с таким видом проблем.
Что касается serverless, название больше отражает не факт отсутствия сервера и работы с ним как таковым, а скорее еще меньше возни с настройкой и поддержкой серверного окружения (даже меньше чем с докером после того как все настроено и поднято). Те это следующие шаг после условных микросервисов.
Его часто удобнее называть функция как услуга, так как де факто часто реализуется запуск именно функции по запросу.
Если кратко описать для чего это нужно, то представим себе что у нас есть микросервис у которого затраты на содержания его постоянного аптайма как то слишком велики относительно времени работы/потребления ресурсов в живую. Да и в целом сервис выходит как то слишком микро даже для микросервиса.
Вот тут мы и придумываем такую штуку, которая будет ОЧЕНЬ быстро(относительно старта минимальной виртуалки/образа и чего другого) запускаться, быстро делает свою маленькую работу и выключается.
Из ключевых особенностей отмечу что функции должно быть в целом пофиг на своего состояние, она не знает изначально о предыдущем запуске и тп(те быть stateless). Все что нужно приходит в запросе.
Ври значит если у вас есть задача, которая удовлетворяет этим условиям, можно использовать этот удобный сервис и для масштабируемости, и для экономии и для кучи других фич.
Примеры:
ресайз изображений.
Генератор статистических сайтов(через админку производим обновление статистических файлов, это бывает не часто).
Чат боты
Разные спец информеры с определенной логикой.
И тд и тп, что хорошо ложится в определенную относительно простую функцию с простым входом данных(или без) и простым результатом работы.
В целом это решение не панацея, более того нужно четко понимать насколько выгодно/невыгодно переделывать на серверлесс платформы свою функцию, ведь мы точно жертвуем той же производительностью(помним что сервис не висит и не ждет нас постоянно, а пусть и очень быстро, но запускается), понижается прозрачность исполнения и усложняется отладка и прочее.
Но в любом случае, достаточно часто плюсы перебивают минусы, популярность у этого принципа есть. люди активно пользуются, так что много шишок уже набито, в целом зрелая штука.
А и да, насчет конкретного вашего вопроса.
PHP AWS Lambda нативно не поддерживает, все через костыли, впрочем с почти вменяемой производительностью.
И так как все таки AWS Lambda все же ближе к самому популярному нынче принципу serverless - функция как сервис, я не уверен что это правильная идея будет запускать атм Ларавел.
Те мы имеем минусы: отсутствие нативной поддержки PHP и такие заточенность под что-то простое, в итоге .. ну не знаю.
Я думаю плюшки serverless в виде нет мороки с настройкой сервера/облака можно решить многими другими сервисами. Впрочем может быть это будет не так выгодно в вашем случае, нужно исходить и рассчитывать по вашему сценарию работы вашего приложения. А потом решать, что лучше подходит.