В целом да, все субъективно. Но обрати внимание, что я не говорил про ужасы. Я говорил просто про то, что стал более внимательно относиться к типам. И расшифрую это так: я просто получил больше гибкости в условиях и т.п. Обрати внимание, даже в официальной документации в сравнениях используют два знака равно. 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?
Получаем «PHP notice: Undefined variable: v», но «11», то есть необъявленная переменная таки === null.
В js undefuned !== null, то есть для меня это дополнительные условия сравнения.
3. instanceof.
4. typeof.
3 и 4 аналоги тоже есть в php, но я ими очень редко пользовался. В js повсеместно использую.
Еще раз уточню: в php в основном сравнения на уровне скалярных величин происходят. В js сравнения используются гораздо шире.
писать содержимое в формате markdown, компилировать его… Чем старый добрый html хуже?
Ну, к примеру, тут, когда мы пишем комментарии, на сервере, прежде чем сохраниться, они обрабатываются джевиксом. А если этого не делать, то что произойдет? Правильно.
С маркдауном этой проблемы нет (вроде как) и можно сохранять и выводить как есть.
В случае рендеринга реактом тоже нет это проблемы, потому что реакт не принимает простые строчные значения для хендлеров, ему надо писать именно с передачей функции.
А можно уточнить в чём неоспоримость? Оба языка вроде как с динамической типизацией?
Да, так и есть. Но в JS это гораздо чаще выходит боком.
К примеру, в php + — это всегда суммирование, а для объединения строк используется точка («st».«ring»).
А в JS и для того, и для другого используется +. В итоге в php «1» + 1 = 2, а в js «1» + 1 = «11».
В курсе, а ещё на куче других языков. Но в данном же случае обсуждается твой вариант реализации (на 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?
Про безопасность в 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
strict mode в js тоже есть, не знаю насколько их назначение идентично.
Для меня эти особенности — в том числе и возможности. Так что я не против.
Это говорит о том, что в принципе изначально особо и не заморачивались на счет жесткости сравнения. И я когда на 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?
При этом смотри какой интересный момент:
Получаем «PHP notice: Undefined variable: v», но «11», то есть необъявленная переменная таки === null.
В js undefuned !== null, то есть для меня это дополнительные условия сравнения.
3. instanceof.
4. typeof.
3 и 4 аналоги тоже есть в php, но я ими очень редко пользовался. В js повсеместно использую.
Еще раз уточню: в php в основном сравнения на уровне скалярных величин происходят. В js сравнения используются гораздо шире.
С маркдауном этой проблемы нет (вроде как) и можно сохранять и выводить как есть.
В случае рендеринга реактом тоже нет это проблемы, потому что реакт не принимает простые строчные значения для хендлеров, ему надо писать именно с передачей функции.
У меня вот такое вообще оформление используется: front-editor.prisma-cms.com/topics/individualnoe-oformlenie-kazhdogo-topika-v-otdelnosti.html
PHP 7.1.3 or higher. Check the required modules list
Check the Apache or IIS requirements
Чот падазрительна. Это точно можно будет потом на github.io вылить и оно будет работать там как статический сайт?
К примеру, в 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 будешь невнимательным к типам, просто не сможешь программировать нормально.
В данном случае нет, потому что ИМ не на призме. Но если поискать, то можно наверняка что-нибудь найти для этого (но при условии наличия прямого доступа к БД, а не как я тут просто тяну POST-запросами). Вот вроде как пример: github.com/overblog/GraphQLPhpGenerator
Тут вопрос спорный. Уже довольно много средств есть для генерации всего и вся, в том числе резолверов. К примеру, на той же призме, достаточно описать схему и запустить деплой, будет не только структура БД создана, но и сгенерированы CRUD-резолверы, включая условия поиска, сортировки и т.п.
Нет, REST я не использую категорически. Что использую, описал здесь: modx.pro/development/18708
Про безопасность в GraphQL — отдельная тема. Тем действительно есть моменты и очень серьезные, но пока про это рано. Расскажу позже, когда народ освоит хотя бы базис.
Про безопасность в REST ничего не скажу, не моя область.
Ноду можно запускать с дополнительным флагом 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