Да, уже понял про второй параметр, спасибо… хотя…
Как сравнить this.props и nextProps? Вернее, где теперь сравнить props, пришедшие, например, из redux??!
Вот именно, если бэкенды для разного — это да, нормально использовать разное. В таком случае вообще не проблема поднять ещё крохотный бэкендик на expresse() и не иметь никаких проблем. (((-:
Может я не так понял, но выше предлагали писать одно и тоже на php и на java.
И опять же: это всё — не проблема GraphQL.
Если Вы используете разные бэкенды — это не проблема GraphQL, это вопрос либо неправильной, либо странной архитектуры.
Клиенту фиолетово, что там на бэкенде, лишь бы он отдавал нужные ему данные в правильном формате. Если так сложно и больно делать бэкенд на php или чём-то там ещё, сервер на expresse поднимается несколькими строчками кода и забывается вся эта боль (-:
Посмотрел на graphql-java: не нашёл ничего страшного и сверхъестественного. У себя думаю для некоторых пользователей попробовать поднять GraphQL на Elixir-e.
Так что всё выше Вами описанное — это не проблемы GraphQL.
Видимо, я использую какой-то другой GraphQL (((-:
Ну и не только я, всякие канторки поменшьше, типа Facebook ((((-:
Быстрее и дешевле делать на GraphQL. Так что используйте GraphQL!
Вообще не проблема или я не понял вопроса (-:
Если у пользователя есть пермишины — он получает полные данные, скажем так, выполняется один запрос, если нету, то другой. Это если вы хотите решать на клиенте.
Если Вы решите это выяснять на сервере, то просто сами решаете, что возвращать пользователю в зависимости от его уровня доступа, так сказать.
Что-то я ничего не понял…
Нет никаких вообще проблем использовать React+Redux с Meteor. Лично я так и использую.
Правда я ещё GraphQL подсоединил. Хочешь методы, хочешь — Pub/Sub, хочешь всякие query с mutation. Вообще никаких проблем.
Ещё всякие папки, типа WIndows, Programm files, Documents and settings, etc тоже шифруются, становятся размером 0 и датой создания 1 января 1970. Странно то, что один диск С нормально подмонтировался, хотя бы смог посмотреть, что случилось, а с другой машины не подмонтировался даже…
да и вообще не понимаю, по какой логике заражались машины…
А с каких пор useQuery() из apollo или react-query стали не подходить?!
Ну вообще-то let и const тоже поднимаются (hoisted), только вот TDZ. Зачем Вы вводите людей в заблуждение?!
Типичная рашистка
Какой хороший файл! (-:
По поводу #2.
Я бы не советовал просто менять биндинг на стрелочную. Всё зависит от того, сколько экземпляров компонента будет на странице.
Как сравнить this.props и nextProps? Вернее, где теперь сравнить props, пришедшие, например, из redux??!
Может я не так понял, но выше предлагали писать одно и тоже на php и на java.
И опять же: это всё — не проблема GraphQL.
Клиенту фиолетово, что там на бэкенде, лишь бы он отдавал нужные ему данные в правильном формате. Если так сложно и больно делать бэкенд на php или чём-то там ещё, сервер на expresse поднимается несколькими строчками кода и забывается вся эта боль (-:
Посмотрел на graphql-java: не нашёл ничего страшного и сверхъестественного. У себя думаю для некоторых пользователей попробовать поднять GraphQL на Elixir-e.
Так что всё выше Вами описанное — это не проблемы GraphQL.
Ну и не только я, всякие канторки поменшьше, типа Facebook ((((-:
Быстрее и дешевле делать на GraphQL. Так что используйте GraphQL!
Всё пишется просто, комфортно.
И вообще не понял, причём тут graphqlCool к meteor. От слова совсем.
Если у пользователя есть пермишины — он получает полные данные, скажем так, выполняется один запрос, если нету, то другой. Это если вы хотите решать на клиенте.
Если Вы решите это выяснять на сервере, то просто сами решаете, что возвращать пользователю в зависимости от его уровня доступа, так сказать.
Нет никаких вообще проблем использовать React+Redux с Meteor. Лично я так и использую.
Правда я ещё GraphQL подсоединил. Хочешь методы, хочешь — Pub/Sub, хочешь всякие query с mutation. Вообще никаких проблем.
да и вообще не понимаю, по какой логике заражались машины…