Вопрос по meteor – Где должен быть определен Meteor.methods ()?

16

http://docs.meteor.com/#meteor_methods

Я пробовал это в publish.js в папке на моем сервере.

Я успешно звоню Meteor.apply и пытаюсь вызвать сервер с клиента. Я всегда получаю неопределенный ответ.

Также пробовал в bootstrap.js в Meteor.startup. Это тоже не сработало. Josh Petitt
Я также пытался в app.js в папке клиента (это не похоже). Josh Petitt

Ваш Ответ

4   ответа
27

призваниеMeteor.methods на сервере правильно. Это определит удаленные методы, которые выполняются в привилегированной среде и возвращают результаты клиенту. Чтобы вернуть нормальный результат, просто позвонитеreturn из вашего метода функции с некоторым значением JSON. Чтобы сообщить об ошибке, бросьтеMeteor.Error.

На клиенте,Meteor.apply всегда возвращаетсяundefinedпотому что вызов метода асинхронный. Если вы хотите вернуть значение метода, последний аргументapply Должен быть обратный вызов, которому будут переданы два аргумента:error а такжеresult, в типичном асинхронном стиле обратного вызова.

Код вашего сервера действительно вызывается? Вы можете проверить это, обновив БД в методе и посмотрев, получает ли кеш клиента новые данные, или вызвавconsole.log изнутри тела метода и глядя на вывод «метеора» процесс в вашем терминале.

Привет, спасибо за ваш ответ. Я не понимаю утверждение "Вызов Meteor.methods на сервере является правильным". Я не знаю, в какой файл поместить определение Meteor.methods? Можете ли вы сказать мне точно, куда бы вы поместили вызов Meteor.methods в приложении? Josh Petitt
любой.js файл вserver папка в порядке. Файлы JavaScript в этой папке просто загружаются и запускаются на сервере. Они естьnot отправлено клиенту.
Понял, спасибо! Josh Petitt
На клиенте нет способа вызвать метод синхронно. Браузер не позволяет вам ждать результата по сети. ТакMeteor.call а такжеMeteor.apply Вернись немедленно. Если вы заботитесь о результате, вы должны предоставить обратный звонок. Наserver, можно вызвать метод синхронно. (Например, один метод вызывает другой.) Это потому, что у нас есть волокна на сервере, и мы можем блокировать вашу функцию, пока результат метода не будет доступен.
Также, чтобы уточнить, документ для Meteor.apply говорит, что если обратный вызов не предоставляется, то метод должен быть синхронным? Это фактическое поведение? (Кстати, для моего приложения я бы хотел, чтобы вызов конкретного метода Meteor.apply был синхронным.) Josh Petitt
8

Я загрузил короткий пример здесь, если вам нужен рабочий пример этого:https://gist.github.com/2387816

Это помогло мне понять, как работают методы. Большое спасибо!
Обычно нет необходимости звонитьMeteor.methods внутриMeteor.startup, Это ловушка для кода, который вы хотите вызывать на сервере только после загрузки всех ваших файлов. С звонкаMeteor.methods просто регистрирует ваши методы - но не вызывает их - обычно нет необходимости откладывать их.
Спасибо. Другой момент, который я не совсем понял, заключается в том, что Meteor.methods () должен вызываться в Meteor.startup (). Ваш пример демонстрирует это хорошо. Josh Petitt
4

Я надеюсь, что некоторые найдут применение этому дополнению, и это не скрывает проблему, заключающуюся в том, что методы в первую очередь предназначены для запуска на сервере какdebergalis объяснил.

С помощьюMeteor.methods() на клиенте тоже полезно. (ищите & quot;stub& Quot; вMeteor.call() раздел тоже ...) Это позволяет клиенту (синхронно) моделировать ожидаемый эффект от вызова сервера. Как упомянуто в документах:

You use methods all the time, because the database mutators (insert, update, remove) are implemented as methods. (...)

Отдельный раздел, объясняющий использование заглушек на клиенте, может облегчить понимание вызовов методов на сервере.

Спасибо. Вот почему методы определены в «коллекциях». папка внутри приложения телескопа:github.com/SachaG/Telescope/blob/master/collections/posts.js
20

Есть несколько мест, где я могу определить свойMeteor.methods() (с за и против):

  1. On the server only - when the client calls the method, it'll have to wait for the server to respond before anything changes on the client-side
  2. On the server, and uses a stub on the client - when the client calls the method, it will execute the stub method on the client-side, which can quickly return a (predicted) response. When the server comes back with the 'actual' response, it will replace the response generated by the stub and update other elements according.
  3. The same method on both client and server - commonly used for methods dealing with collections, where the method is actually a stub on the client-side, but this stub is the same as the server-side function, and uses the client's cached collections instead of the server's. So it will still appear to update instantly, like the stub, but I guess it's a bit more accurate in its guessing.
@adrianmc Потому что иногда вы можете использовать в своем методе секретную информацию, которую вы не хотите, чтобы клиент знал.
Так зачем кому-то использовать вариант 2, если он может использовать вариант 3?
@danyll, вы должны представить PR, чтобы добавить этот текст вMeteor API docs!
@ d4nyll как ты реализуешь 2? Вы просто определяете две разные версии в коде клиента и сервера?
@aromero Да, именно так. Увидетьstackoverflow.com/a/17510929/3966682это по-прежнему актуально

Похожие вопросы