Михаил Смирнов

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

И вот в один момент разработчики спецификации ECMA-script решили, а давайте мы всё же оправдаем первые 4 буквы в названии языка, а именно "Java", и дадим пользователям сахарок, нарисованный над нашим прототипным наследованием, чтобы они могли везде писать class, extends и implements, как и все остальные ООП-динозавры. И сделали это.

И с этим решением в наш прекрасный язык пришло понимание конструктора, как метода, создающего экземпляр класса. Конструктор очень сильно помогает с инкапсуляцией. В языках, имеющих настоящий ООП, есть приватные поля, которые не могут быть инициализированы прямым присваиванием в какой-то внешней функции, создающей объект, потому что к ним нет прямого доступа, и для такого придётся писать публичные сеттеры. А это плохо, потому что кто угодно сможет менять при помощи этих сеттеров то состояние, которое менять не надо.
А вот из конструктора к приватным полям прямой доступ имеется. В Javascript приватные поля появились, кстати, вот буквально совсем недавно.

class ClassWithPrivate {
  #privateField;
  publicField;

  constructor() {
    this.#privateField = "Доступ только изнутри класса";
  }
}

const instance = new ClassWithPrivate();

instance.publicField = "Доступ извне класса";
instance.#privateField; // Ошибка: SyntaxError: Private field '#privateField' must be declared in an enclosing class

Еще одной особенностью конструктора является то, что он активно используется при наследовании (крестится и плюётся через левое плечо от отвращения). Если в дочернем классе не описан свой конструктор, то будет использован конструктор родителя. Это упрощает ООП.

class Animal {

  constructor(name) {
    this.speed = 0;
    this.name = name;
  }

  run(speed) {
    this.speed = speed;
    alert(`${this.name} бежит со скоростью ${this.speed}.`);
  }

  stop() {
    this.speed = 0;
    alert(`${this.name} стоит.`);
  }

}

class Rabbit extends Animal {
  hide() {
    alert(`${this.name} прячется!`);
  }

  stop() {
    super.stop(); // вызываем родительский метод stop
    this.hide(); // и затем hide
  }
}

let rabbit = new Rabbit("Белый кролик"); // используется конструктор родителя

rabbit.run(5); // Белый кролик бежит со скоростью 5.
rabbit.stop(); // Белый кролик стоит. Белый кролик прячется!

Таким образом, если вдарились в классический ООП, пользуйтесь везде конструктором, потому что ООП развивается десятилетиями, люди прошли сквозь страдания и выработали определённые "лучшие практики" для ООП.
Если же вы используете объекты в основном как очень простые структуры без классической инкапсуляции с приватными полями, не используете наследование, а весь ваш код написан, в основном, на функциях, то делайте, ради бога, что вам вздумается, и отдельная функция-фабрика для создания объектов - это тоже вариант.

Во втором случае функцию в data вы не вызываете:
data().init

Эх, молодёжь...
copy *.sql fulldump.sql
Ещё во времена MS-DOS можно было

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

Человек с адекватным восприятием реальности сделает очень простое умозаключение: если в ответе появляются посторонние символы, то это значит, что они присутствуют в скрипте. После этого найдет эти символы и удалит. Тупо проверив все файлы, которые участвуют в обработке запроса.
А для неразрешимой проблемы "почему на локалке посторонних символов нету" найдет простое рациональное объяснение: файлы "на локалке" и "не на локалке" отличаются.

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

Ну и поскольку у меня глаза не могут смотреть на эти хаотичные телодвижения, то вот как этот код может выглядеть на самом деле

файл init.php

<?php
$conn = new PDO('mysql:host='.DB_HOST.';dbname='.DB_NAME.';charset=utf8mb4', DB_USER, DB_PASSWORD);  
$conn -> setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION ); 

set_exception_handler(function ($e)
{
    http_response_code(500);
    error_log($e);
    echo json_encode([
            'code' => 'error',
            'message' => 'Internal server error'
    ]);
});

файл с кодом

<?php
// Подключаемся к базе данных
require 'init.php';

// Получаем данные
$list = get_list($conn);

echo json_encode([
    'code' => 'success',
    'data' => $list
]);

Без всей этой кропотливой возни и самоповторов.
Отсутствие данных ошибкой не является. В JS можно проверить массив data и вывести сообщение, что он пустой. Никакой специальный код для этого передавать не нужно.
А настоящие ошибки надо обрабатывать единообразно, в одном месте. А не писать обработку после каждой строчки, причем каждый раз по-разному.

Берете любую вузовскую методичку по дисциплине "Теория языков программирования и методов трансляции".
Изучаете, с чем едят грамматики формальных языков, строите лексический анализатор, синтаксический анализатор, транслятор в свой машинный код, исполнитель машинного кода.
На выходе у вас должна получиться вот такая штука:
https://studfile.net/preview/937093/

Должен вернуть одну строку с id 10 (последняя строка в выборке на скриншоте)

Кому должен? Программа должна делать только то, что вы в ней написали. Строки по колонке mentions отсортированы, десятая строка выбрана. То, что нет других правил сортировки означает, что строки с одинаковым значением mentions можно выдавать в любом порядке.

Надо учиться отлаживать свой код самостоятельно.
Ну то есть вы уже начали, это очень хорошо.
Но выводить просто 'find data' не очень информативно. Вам надо понять, почему оно выводится.
Добавьте к var_dump ('find data'); результат strpos($value,'г ') и посмотрите на результат. причина сразу станет ясна.

И соответственно, код надо будет доработать, чтобы получить желаемый результат.
Кстати, если у вас 8 версия РНР, то в нем есть готовая функция для такой проверки, вместо strpos

Давайте вместе подумаем, почему ваш селектор, в котором чёрным по белому написано checkbox, не выбирает radio. Но есть вероятность, что придётся искать кого-то ещё и соображать на троих.

Проблема в том, что многие курсы рассказывают о различных web терминах, в
результате чего возникает каша, поскольку не знаешь где и что применять
Возьмём патерны проектирования, MVС, модуль и так далее. Насколько я понимаю они
и решают проблему разбивки кода...

В текущем, современном этапе разработки такими паттернами почти не пользуются. Сейчас у нас есть import/export - вот он ваш, нативный модуль. В остальном, просто положитесь на фреймворк.

Как подходить к оформлению кода, если мы не используем фреймворк Vue или иной...

Любой клиентский фреймворк - это уже своего рода архитектура, просто нужно следовать в начале пути общепринятым правилам. В отношении vue почитать про best practices. В этой папке компоненты, в этой папке сервисы, в этой папке утилиты, в этой папке типы и т.п. Разделяйте макет на части. Отдельный компонент фильтра, который состоит из множества компонентов самого фильтра, чекбокс фильтр, фильтр диапазона и т.п. Отдельно компонент товара и т.д.

Дмитрий Лаврик сказал, что бэкенд программисты в последнее
время создают API для сайтов. Так намного проще создавать бэк

Ну в какой-то степени он прав, бекендерам не нужно заниматься отображением, т.к. этим должен заниматься фронт. А так же удобнее создавать микросервисную архитектуру, т.к. каждый сервис на вход ждёт лишь данные, что бы отдать данные. Во всём остальном по сути своей ничего не поменялось.

Можно ли при помощи VUE создать fullstack приложения или без создания той же
структуры базы данны никак?

На vue нельзя написать фулстек, как и на react. Это браузерные фреймворки(клиентские), предназначенные для работы в браузере.

База данных - это всего лишь термин, который говорит, что есть какое-то хранилище данных. Им может быть любая из популярных БД или просто файлик(или множество файликов). Просто где лежат записи. Любое ПО, в котором вы можете редактировать или создавать записи, должно иметь базу данных, иначе никак.

выучил JS на уровне решении задач средней сложности

Ну вам не кажется что из вышеперечисленного вами, вы не выучили js. Средней уровень сложности(хотя что можно считать "средним уровнем сложности" - это ещё вопрос), это наверно где-то джун+. А такие джуны уже умеют пользоваться инструментами.

Личный мой вывод:
Вы как и все начинающие окунулись в болото под названием js. Где царит хаос и анархия, когда можно всё, но не понятно как. У меня главный вопрос к таким людям, а зачем вам на данном этапе вашего развития "всё"? Ну вот серьёзно, зачем? Зачем вам сейчас знать, как устроена БД, как правильно создавать таблицы, как правильно создавать связи в них, зачем микросервисы, зачем, о госпади микрофронты, SSR, PWA, FullStack, Nodejs, Docker, Kubernetes, webpack, vite, TypeScript и прочая херня, которой полон мир фронтенда. Зачем вам всё это, если вы сами не можете ответить на этот вопрос. Зачем вам сейчас знать, как это работает. Если вы просто сайтик с чекбоксиками не можете сделать. Т.е. простая фильтрация html кода. Возьмите какую нибудь публичную rest api с фейковыми данными для своей песочницы и постройте маломальский сайтик с фильтром. Зачем вам фулстек? Почувствовать себя гением разработки? Забудьте про кучу не понятных терминов, просто выкиньте их из головы.
Зачем вам вообще vue или реакт, или им подобные? У вас в голове хоть есть понимание, зачем придуманы эти штуки, какую задачу то они призваны решать? Почему все так "дрочат" на эти SPA? Почему +- 90% вакансий фронта требуют знания SPA фреймворков? Каждый инструмент призван решать какую-то задачу, пока вы не поймёте, почему вам реально нужен этот инструмент, не трогайте его, пускай лежит до лучших времён.

Просто возьмите js или хрен с ним, возьмите vue, сделайте внутри ajax запрос, получите данные, отобразите их. Где в этих словах какие-то особенные или сложные термины? Вам идиоты напихали в голову сложных конструкций, вот вы и мучаетесь. Упростите себе жизнь, выкиньте из головы всякую хрень. Просто сядьте и пишите, не думая ни о чём! Просто берёте vue, разворачиваете как в доке написано и готово, работайте.
А когда сделаете, перекурите, а потом сядьте и посмотрите на своё творение и подумайте, как можно улучшить, возможно упростить. Не ждите быстрого успеха!

КОВАТЬ, КОВАТЬ И ЕЩЁ РАЗ КОВАТЬ! Только так можно научиться.

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

Функционально - разницы никакой, т.к. по факту и то и другое реализует одинаковую логику: создание объекта с определенными свойствами. Третий вариант можно назвать функциональным подходом: мы создаем функцию, которая решает свою задачу и не привязываем её к какому-то классу. `new` - просто способ сказать как компилятору, что надо вызвать функцию-конструктор такого-то класса, так и программисту, читающему данный код в будущем, что вот тут мы создаем новый экземпляр такого-то класса. Так же и, например, {} просто упрощенная запись new Object() для создания объекта.

ini_set('error_reporting',E_ALL);
ini_set('display_errors', 1);

/\+7\(\d{3}\)\d{3}-\d{2}-\d{2}/
https://regex101.com/r/jXMk30/1

1. Встраивают интерпретатор нужного языка, при необходимости урезают стандартную библиотеку (чтобы не давать коду плагинов лишних возможностей) и подсовывают туда средства общения с хост-программой.
2. Если нет нужды изолировать плагин от остальной программы, то полагаю что да, накладные расходы на поддержку плагинов уменьшатся в случае, когда плагин написан на том же языке, что и программа. В противном случае организация "песочницы" может занять столько же усилий, сколько встраивание интерпретатора.
3. Лучше, если язык плагина является или интерпретируемым (как Lua или JS), или компилируется в байткод (как Python/Java/C#). Также желательно, чтобы язык плагина имел средства интроспекции.