Fi1osof

ОК. Пусть у меня будут знания ниже среднего вообще во всем. Диалог закрыт.

и убедимся, что сравнение == это беда не только PHP, но и JS.

Я где-то говорил обратное, или просто доебаться хотелось?

Затем подтянем PHP и познакомимся с declare(strict_types = 1);

strict mode в js тоже есть, не знаю насколько их назначение идентично.

Не ты плохой (хотя это не точно). Мне тоже было этого достаточно. Это именно разные языки и подходы в них. К примеру, в том же GraphQL активно используется именно сравнение инстансов, а не каких-либо свойств объектов (имен или типа того). github.com/graphql/graphql-js/blob/49d86bbc810d1203aa3f7d93252e51f257d9460f/docs/APIReference-TypeSystem.md#example-3

тип строки (Hello world) не совпадает с типом нового объекта String (new String('Hello world'))

Совсем не удивительно, ведь тип строки (строка) не может совпадать с типом нового объекта (объект). «string» !== «object».

Столько этих «особенностей» нет ни в одном другом языке.

Для меня эти особенности — в том числе и возможности. Так что я не против.

В целом да, все субъективно. Но обрати внимание, что я не говорил про ужасы. Я говорил просто про то, что стал более внимательно относиться к типам. И расшифрую это так: я просто получил больше гибкости в условиях и т.п. Обрати внимание, даже в официальной документации в сравнениях используют два знака равно. https://www.php.net/manual/ru/function.empty.php

Используйте вместо него trim($name) == false

!isset($var) || $var == false

Это говорит о том, что в принципе изначально особо и не заморачивались на счет жесткости сравнения. И я когда на php программировал, в основном только и использовал if($val) да if(!$val), то есть просто простейшие сравнения использовал.
В js я использую:
1. foo === undefined чтобы проверить была ли вообще передана переменная (в php аналог isset).
2. foo === null, чтобы проверить, что переменная была передана, но значение установлено нулевое, то есть мне именно надо сбросить значение.

Говоря про эти два момента, в php обычно просто проверяют isset() и empty(), но если брать $foo = null, то isset($foo) и empty($foo) оба вернут true. Часто ли ты используешь сравнение с null?

При этом смотри какой интересный момент:

$v;
print (int) ($v === null);
print (int) (empty($v));

Получаем «PHP notice: Undefined variable: v», но «11», то есть необъявленная переменная таки === null.
В js undefuned !== null, то есть для меня это дополнительные условия сравнения.

3. instanceof.
4. typeof.

3 и 4 аналоги тоже есть в php, но я ими очень редко пользовался. В js повсеместно использую.

Еще раз уточню: в php в основном сравнения на уровне скалярных величин происходят. В js сравнения используются гораздо шире.

Вероятней всего, если ты вдруг начнешь плотно на js программировать, ты согласишься с нами. А пока нет, сложно будет для тебя примеры привести.

писать содержимое в формате markdown, компилировать его… Чем старый добрый html хуже?

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

<a href="#" onclick="alert('hacked')">click me</a>

С маркдауном этой проблемы нет (вроде как) и можно сохранять и выводить как есть.

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

<a href="#" onClick={() => {alert('secure message')}}></a>

У меня вот такое вообще оформление используется: front-editor.prisma-cms.com/topics/individualnoe-oformlenie-kazhdogo-topika-v-otdelnosti.html

Requirements
PHP 7.1.3 or higher. Check the required modules list
Check the Apache or IIS requirements

Чот падазрительна. Это точно можно будет потом на github.io вылить и оно будет работать там как статический сайт?

Не за что!

А можно уточнить в чём неоспоримость? Оба языка вроде как с динамической типизацией?

Да, так и есть. Но в JS это гораздо чаще выходит боком.

К примеру, в php + — это всегда суммирование, а для объединения строк используется точка («st».«ring»).
А в JS и для того, и для другого используется +. В итоге в php «1» + 1 = 2, а в js «1» + 1 = «11».

Ну а больше всего мне нравится вот этот мемас))



Объяснение: www.freecodecamp.org/news/explaining-the-best-javascript-meme-i-have-ever-seen/

Или вот такой пример: ['1', '7', '11'].map(parseInt) возвращает [1, NaN, 3].
habr.com/ru/post/456344/

Или вот: (![] +[])[+!![]] = 'а'

В общем, если в JS будешь невнимательным к типам, просто не сможешь программировать нормально.

В курсе, а ещё на куче других языков. Но в данном же случае обсуждается твой вариант реализации (на JS) и вариант Андрея (на PHP).

Но если бы я все еще писал на php, то практически все из описанного было бы так же, просто на php.

То есть, на примере ИМ, можно просто описать схему запросов и мутаций для msCategory, msProduct, msOrder и т.п. и оно поедет?

В данном случае нет, потому что ИМ не на призме. Но если поискать, то можно наверняка что-нибудь найти для этого (но при условии наличия прямого доступа к БД, а не как я тут просто тяну POST-запросами). Вот вроде как пример: github.com/overblog/GraphQLPhpGenerator

В данном случае автор т.н. API, которое мы фактически парсим, ничего нам не должен и в любой момент может поменять любой тип данных от чего GraphQL начнёт ругаться.

Так-то оно так. Но если бы на той стороне использовалось graphql-API, то я мог бы посмотреть сгенерированную API-документацию и легко сориентироваться что там не так, и что можно запрашивать, а что нет. Ведь graphql-документация всегда актуальная.

то RESTful подойдёт, он же проще ставится и работает только на PHP, на котором и сам MODX крутится.

GraphQL реализация есть и на php.

Правда работы изначально придётся провести довольно много, чтобы прописать всё взаимодействие (запросы, мутации, подписки) в резолверы.

Тут вопрос спорный. Уже довольно много средств есть для генерации всего и вся, в том числе резолверов. К примеру, на той же призме, достаточно описать схему и запустить деплой, будет не только структура БД создана, но и сгенерированы CRUD-резолверы, включая условия поиска, сортировки и т.п.

Ну вот как освоишь оба способа, так сравнишь какой лучше :)

В целом согласен. Но этот тренд еще не в конце пути, так что нас ждут еще новые вариации и новые виды взлома (как то «github взломали, сотни тысяч сайтов оказались заражены»).

Если комменты disqus, обратная связь Netlify и т.д. и т.п., то это уже практически полностью статический html-сайт без большинства современных прелестей. Но в таком случае да, он действительно будет безопасен :)

Николай, насколько я знаю, в вашей cms используется как раз rest api для работы с данными, исходя и накопленного опыта можешь рассказать, какие есть проблемы в безопасности при работе с rest api?

Нет, REST я не использую категорически. Что использую, описал здесь: modx.pro/development/18708

Про безопасность в GraphQL — отдельная тема. Тем действительно есть моменты и очень серьезные, но пока про это рано. Расскажу позже, когда народ освоит хотя бы базис.

Про безопасность в REST ничего не скажу, не моя область.

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

Здесь, конечно, слукавил немного. Какая разница в какой момент происходит обращение к базе данных (в момент серверного рендеринга или потом по API)? В любом случае есть тонкий клиент к БД (окно). При чем вот в таком современно формате это окно более открытое и опасное, потому что в классическом варианте бОльшую часть из БД можно получать не давая пользователю доступ к этим запросам (то есть извне не вызвать просто так, можно только страницу вызвать). А в случае с JAM используется более обширное API, позволяющее получить практически всю информацию (иначе она не подтянется и просто не отобразится на сайте). Так что где безопасней, это еще бабка надвое сказала.

Николай, разработка сайта в целом — это бэк и фронт. MODX — это только бэк. А по фронту здесь мало информации. Получается, делаешь сайт на MODX, на сервере все ОК, а фронт — как будто школьник учится. По фронту информация нужна однозначно. А фильтроваться будет само — кому не интересно, тот пропускает. А тратить свои калории и писать часто что-то не интересно — не каждый станет. И по большому счету львиная часть топиков здесь — это вопросы из серии «как мне вставить чекбокс?». И что теперь? Сказать им «Не пишите такие статьи, они бесполезные, пишите только очень интересные и полезные статьи»? Вот такая статья стоит десятков среднестатистических заметок здесь.

Кстати, хотелось бы еще аргумент высказать в защиту серверной реализации JS.
Ноду можно запускать с дополнительным флагом node --experimental-modules и получать некоторые дополнительные фишки, к примеру, esm. habr.com/ru/post/433964/
Для браузеров пока esm совсем не стандарт, но на сервере, когда ты знаешь, что окружение единое (а не как 100500 браузеров пользовательских), я считаю использование нативного js без всяких там пре/пост процессоров, сборщиков и т.п. очень даже оправдано. Во-первых, никакой предварительной компилляции. Во-вторых, логи ошибок, где бы они не возникли, ссылаются четко на строки в исходниках, а не на сжатые версии, где ты не разберешься без допсредств. В-третьих, потребление памяти меньше, а производительность выше. В-четвертых, можно линковать компоненты не только в рамках одной рабочей директории. Да и вообще плюсов много.
Серверная часть prisma-cms у меня все на mjs написана. github.com/prisma-cms/boilerplate/tree/master/src/server

Если нет разграничения прав, то такой подход допускается. Но если ты хочешь выдавать различный контент в зависимости от прав пользователя? Или фильтры у тебя и большой объем исходных данных? Или контент очень активно прирастает?
Сгенеренная статика подходит для небольшого сайта, но вот для крупного уже не очень. Представь, что ты modx.pro будешь генерить в статику. Кстати, в свое время был у меня такой эксперимент: modxclub.ru/blog/research/210.html