Метеор, связь между клиентом и сервером

Question

Этот фрагмент из учебника списка дел. Переменная checked представлена ​​как на стороне клиента, так и на стороне сервера? Как клиент и сервер общаются, чтобы сделать checked согласованным?

Template.task.events({ 
    'click .toggle-checked'() { 
    // Set the checked property to the opposite of its current value 
    Tasks.update(this._id, { 
     $set: { checked: ! this.checked }, 
    });                            
    }, 
    'click .delete'() { 
    Tasks.remove(this._id); 
    }, 
}); 

Answer 1

Метеор любит размывание линий между клиентом и сервером. Есть вещи, которые вы можете сделать для абстрактного кода - например, файлы javascript (среди всех файлов) внутри каталога /server, чтобы ограничить доступ к нему. Это означает, что клиентские пользователи не могут видеть этот код.

/client очевидно противоположное. Вы можете проверить файл с помощью isClient и isServer.

Теперь, что это значит для вашего кода?

В зависимости от того, где находится ваш код, существуют разные уровни доступа. Однако внутри скрипта в принципе нет разницы. checked известен на сервере/клиенте внутри этого скрипта, потому что так работает Meteor, размытая линия между клиентом и сервером делает это возможным.

Meteor использует что-то, называемое «база данных везде», что означает, что не имеет значения, где вызывается код, потому что он будет работать.

Answer 2

checked - это аттрибут, определенный на объекте Tasks, как определено в этом приложении.

В Meteor окончательная запись этого объекта хранится на сервере (в MongoDB), однако есть кеш-клиент, который также обрабатывается здесь, известный как MiniMongo. Структура Meteor выполняет большую работу в фоновом режиме (через протокол DDP), чтобы синхронизировать объекты сервера и клиентской стороны.

В этом случае происходит следующее, когда пользователь нажимает на флажке (обжиг кода 'click .toggle-checked' событий) в Tasks.update методе:

1. Первой сторона клиента обновления MiniMongo Cache - это известно как Optimistic UI, и позволяет клиентскому UI быстро реагировать (не дожидаясь сервера)
2. Отправить сообщение серверу (Meteor Method), что клиент хочет обновить объект Tasks, установив переменную clicked в новое значение.
3. Сообщения запроса обновления, полученное сервер, который проверяет это действует операция, а также обрабатывает его (обновление MongoDB версии Tasks объекта, или отказывается обрабатывать обновления по мере необходимости.
4. сервер будет отправлять DDP обновления полученный статус Tasks объекта для всех клиентов, которые подписались на публикацию, которая включает его.
5. клиентов, которые ранее подписавшихся получат это DDP обновление и заменят их версию MiniMongo с версией Сервера от Tasks объекта, чтобы все клиенты находились в синхронизации с сервером.

Теперь в идеальном случае, когда сервер принимает изменения клиентов, новая версия Tasks, полученная (на шаге 5) инициирующим клиентом, будет соответствовать объекту, который он оптимистически обновляет (на шаге 1).

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

К счастью, все это обрабатывается рамкой Meteor, и все, что вам нужно сделать, это позвонить Tasks.update для всей этой магии!