Я не могу назвать Accounts.findUserByEmail() на стороне сервера через Meteor.call

Question

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

Похоже, что предлагаемый способ будет определять Meteor.method() и выполнять всю работу там. К сожалению, я, по-видимому, понятия не имею, что я делаю, потому что я получаю сообщение об ошибке, которое никто не получил.

component.js:

Meteor.call('confirm', email); 

methods.js:

Meteor.methods({ 
    'confirm': (email) => { 
    if (Accounts.findUserByEmail(email)) { 
     return; 
    } 
    } 
}); 

Все, что я получаю эту ошибку:

Exception while simulating the effect of invoking 'confirm' TypeError: Accounts.findUserByEmail is not a function

ли я полностью недопонимание динамику Метеор .methods + Meteor.call? Разве это не серверная сторона?

В настоящее время используется пакет Метеора accounts-password@1.3.3

Answer 1

Метеор имитирует метод вызывает в переднем конце тоже, запустив «заглушки» ваших методов. Идея состоит в том, чтобы иметь лучший пользовательский интерфейс, потому что пользовательский интерфейс обновляется непосредственно перед ответом сервера. Однако это также означает, что при запуске сервера только код в методах Метеор, вы должны убедиться, что код работает только на сервере:

Meteor.methods({ 
    'confirm': (email) => { 
    if (Meteor.isServer && Accounts.findUserByEmail(email)) { 
     return; 
    } 
    } 
}); 

В качестве альтернативы, вы можете разместить выше определение метода в файле который загружается только на сервере, как любой файл в каталоге /server или (рекомендуется) в /imports в файл, который только include d по серверному коду. Тогда вам не нужно будет использовать Meteor.isServer отдельно.

Answer 2

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

Возможно, было бы целесообразно реализовать различные версии (по крайней мере некоторых) методов для клиента и сервера и вообще не включать некоторые из них на клиенте.

Если вы решили использовать ту же функцию на клиенте и на сервере, есть Meteor.isServer, Meteor.isClient и this.isSimulation (последний специально для методов), которые позволяют выполнять некоторые из блоков только на клиенте/сервер.

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

Для этого конкретного случая использования, вы, вероятно, следует реализовать только метод на сервере (просто не импортировать свой код в клиентской сборки):

Meteor.methods({ 
    isEmailInSystem(email) { 
    check(email, String); 
    return !!Accounts.findUserByEmail(email); 
    } 
}); 

Вы можете прочитать больше о жизненном цикле метода в The Meteor Guide.

Из руководства (сутью, некоторые детали опущены):

1. Method simulation runs on the client - If we defined this Method in client and server code, as all Methods should be, a Method simulation is executed in the client that called it.

   The client enters a special mode where it tracks all changes made to client-side collections, so that they can be rolled back later. When this step is complete, the user of your app sees their UI update instantly with the new content of the client-side database, but the server hasn’t received any data yet.

2. A method DDP message is sent to the server
3. Method runs on the server
4. Return value is sent to the client
5. Any DDP publications affected by the Method are updated

6. updated message sent to the client, data replaced with server result, Method callback fires
   After the relevant data updates have been sent to the correct client, the server sends back the last message in the Method life cycle - the DDP updated message with the relevant Method ID. The client rolls back any changes to client side data made in the Method simulation in step 1, and replaces them with the actual changes sent from the server in step 5.

   Lastly, the callback passed to Meteor.call actually fires with the return value from step 4. It’s important that the callback waits until the client is up to date, so that your Method callback can assume that the client state reflects any changes done inside the Method.