Comments 32
Что случилось с хабр ?
Я думал будет раскрыто как переменную в отдельный js файл передать, или что то интересное.
У меня культурный шок.
tl;dr
И так, из всего выше перечисленного и выше приведенного за ранее делаем вывод, что для самых НОВИЧКОВ это просто - ПЕРЕДАЧИ. Программный код - это просто, для этого мы как обычно открываем теги JavaScript!
Чтобы это значение вывести на экран.
Спасибо за внимание, с вами был.
`window.Config = <?= json_encode($data, JSON_HEX_TAG) ?>` – и переменная в отдельном файле есть. Это один абзац, а не статья.
Если изменить на var TOWN = <?php echo json_encode($CITY); ?>; и объяснить почему именно так, то станет чуть менее печально.
А если у меня есть переменная $fn = function() { return 600;}, то её как передать? Почему не рассмотрели вариант запроса значения через fetch(), например?
Странная статья - только началась и вот уже закончилась. Это точно не для Хабра.
Смотря в какой момент передать PHP -> JS, то есть на фронт
При генерации страницы (PHP, server-side render):
echo "<span>" . $city . "</span>"; // подставится в HTML сразуПо запросу от клиента (AJAX):
fetch('/api/city').then(r => r.text()).then(t => TOWN = t);По инициативе сервера (WebSocket / SSE):
const ws = new WebSocket('wss://...'); ws.onmessage = e => TOWN = e.data; // сервер шлёт сам
Зачем это делать на клиенте? Как-то глупо. Меня вообще выворачивает от таких костылей. Есть сервер, есть логика взаимодействия клиент-сервер, зачем такую ерунду городить.
Это не костыль, так писали раньше. Да и пишут до сих пор, просто автор как то без интереса, чисто один пример написал, без практики конкретной.
Причин так писать много. Это может быть допустим стейт приложения. Первые гибридные приложения так и прокидывали состояние.
Первые гибридные приложения так и прокидывали состояние.
Да, я это помню в 2000-х. И тогда тоже не понимал этой чуши. Отправить можно запрос AJAX, да что угодно. Это убогая архитектура. Костыль самый настоящий.
Запрос на что? На подгрузку данных, которые можно сразу показать?
Есть определенные метрики перфоманса страницы, первичного рендера и вещи которые важны для SEO, аукциона рекламы и тд и тп. От мета тегов, до первичного контента. Это критически важно для разного рода сайтов и целей.
Но все же так сейчас почти никто не делает. На худой конец есть шаблонизаторы, которые худо-бедно разделяют представление от бизнес-логики
Хотя тут же js...
Но все же так сейчас почти никто не делает.
Напрямую да, но в целом любое SSR грубо говоря именно так и делает)
И да сейчас даже async/await шаблонизаторы поддерживают, но итог такой же, что-то вот подкладывается в HTML и потом используется.
Просто пост слишком базисный. Тему можно куда круче раскрывать))
подгрузку данных, которые можно сразу показать
Зачем тогда JS использовать для этого. Если сразу, тогда HTML.
Есть определенные метрики перфоманса страницы, первичного рендера
Парсинг такой как раз замедлит загрузку. Лучше сразу в JS все сделать без этих костылей - это будет быстрее, чем браузер спарсит строки, а потом это еще и JS обработает. В этом нет вообще смысла никакого.
Зачем тогда JS использовать для этого. Если сразу, тогда HTML.
Изоморфное приложение, стейт приложение, ssr, да даже просто jquery плагин с нужными параметрами с бека))
Парсинг такой как раз замедлит загрузку.
Сори про это все много чего написано. Тут нет смысла холиварить. Уже какой-то парсинг пошел)) Я выше дал направление если интересно куда копать
Лучше сразу в JS все сделать без этих костылей - это будет быстрее
Чтобы JS заработал он должен распарситься это верно. Но в вашей схеме только после этого пойдет ваш запрос, получит ответ, и наконец-то что-то покажет.
В случае же вставкой данных в JS - распарсится и покажется. Минус серверное взаимодействие понимаете? Не говоря уже том, это может быть комплексный запрос, который затрагивает разные системы, требует каких-то данных. Их тоже на фронт отправлять, что бы потом сделать запрос на данные, которые у нас уже могли быть на беке?
Не думал, что придётся это объяснять, ну))
Если это комплексный запрос, тогда это точно лучше делать на стороне сервера. Вообще клиенту надо доверять по-минимуму, вы его контролируете только частично.
В моей схеме выдача будет сразу того, что нужно показать быстро. Остальное распрасится, отработает и будет выведено.
Этой схеме уже 100 лет. Много где грузится сначала основное и выдается пользователю, потом подгружается остальное. Не сразу все, как вы хотите. Пример - это тайлы в картах. Вы все их будете грузить сразу, да? Или товары в каталоге.
Но я не наставиваю, можете делать, как хотите. Я бы такую хрень в жизни не сделал.
Много где грузится сначала основное и выдается пользователю, потом подгружается остальное. Не сразу все, как вы хотите. Пример - это тайлы в картах. Вы все их будете грузить сразу, да?
Я выше написал, что, когда и для чего, подходы и метрики, зачем вы опять спрашиваете.
Есть то, что можно показать сразу с HTML, есть то, что можно показать сразу с JS, и есть то, что можно показать динамически с запросом, comet сервером и так далее.
Каждый из способ валиден в той или иной ситуации. Если вы не встречались с этой "хренью", это не значит, что этого нет или это не нужно.
Я выше написал причины, почему этот подход не только не самый лучший, но по сути - костыль. Вываливать кучу данных в HTML, среди которых может быть и что-то про уязвимости (кстати), парсить это браузером, а потом парсить JS вместо нормальной обработки на сервере и загрузки JS только тем, что ему нужно... Ну ладно, похоже дискуссия бесполезна))))))))))))))
Я выше написал причины, почему этот подход не только не самый лучший, но по сути - костыль
В чем костыль?
Вываливать кучу данных в HTML
Это вы уже придумали, не нужно вываливать туда кучу данных
что-то про уязвимости (кстати)
Ну вы аккуратно))
парсить это браузером, а потом парсить JS
Вы так и не поняли, что ваш запрос на сервер, работает после того как парсится js)))
Просто почитайте как работает любое современное SSR приложение, на том же Next.js. Почитайте про gradual loading aka progressive loading, lazy loading
Ну ладно, похоже дискуссия бесполезна
Оставьте при себе этот гонор лол
Вы так и не поняли, что ваш запрос на сервер, работает после того как парсится js)))
Вы же даже не знаете, о каком запросе идет речь)))) Отвечу только на это, ибо все остальное в таком же духе.
Ладно, нет желания больше переливать из пустого в порожнее. Прошу прощения, время свое ценю.
Вы же даже не знаете, о каком запросе идет речь
Вы выше писали
Отправить можно запрос AJAX
SSR может сразу вставить данные в HTML/JS, например через inline-script или JSON в шаблоне или как вот в посте.
AJAX же отдельный клиентский запрос после загрузки страницы, и зачем вы развели тренд, рассказывая, что костыль, а что нет - никто не понял.
Если мне нужно передать одну-две переменных, то так гораздо проще и быстрее, чем возводить ещё один слой с дополнительными запросами и ответами, эндпоинтами, js, cors и прочим.
Эх, я уж подумал что статья будет как из php передать все данные в отдельный js файл, но увы, тут прямо для начинающих. Хотя, я и так это знаю - как передать в отдельный js файл, но почему-то подумал, что будет что-то новое
В языках с си-подобным синтаксисом, куда относятся и JS, и PHP, принято написание СПЛОШНЫМИ_ЗАГЛАВНЫМИ для констант, а для переменных всё-таки принято использовать нижний регистр. А уж использовать ли camelCase или snake_case для имён из нескольких слов — отдельный вопрос.
Ахаха. Что?
4:19: чтобы написать статью на хабре у вас не хватает кармы
4:20: ...
...а потом кто-то в переменную $CITY добавит символы
';
И будет весело :)
Передача значений переменной из PHP в JavaScript