Это говорит о том, что в принципе изначально особо и не заморачивались на счет жесткости сравнения. И я когда на 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 сравнения используются гораздо шире.
Про безопасность в GraphQL — отдельная тема. Тем действительно есть моменты и очень серьезные, но пока про это рано. Расскажу позже, когда народ освоит хотя бы базис.
Про безопасность в REST ничего не скажу, не моя область.
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