2014-11-13 2 views
4

Я сейчас экспериментирую с переходом существующего веб-приложения с нокаута на ответ js.Реагировать на серверную визуализацию без опроса для изменений

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

Вопрос: Если бы я выполнял роль сервера рендеринга, как изменения могли быть перенесены на каждого клиента? Я только что начал читать на рендеринге на сервере, поэтому я, возможно, неправильно понимаю, как это работает, но, как я считаю:

Клиент выполняет действие, отправленное на сервер, сервер отвечает фрагментом html, который клиент затем заменяет его DOM

В случае приложения, в котором состояние может быть изменено сервером или другим клиентом, будет ли я вынужден использовать веб-сайты/HTTP-опрос для отображения этих обновлений?

Возможно ли, чтобы сервер сбрасывал новые фрагменты в противном случае?

ответ

7

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

Получите JSON с сервера с помощью websockets, SSE или опроса (это не имеет значения). Они должны быть в формате конверта. Это будет пример приложения чата.

{ 
    "type": "new-message", 
    "payload": { 
    "from": "someone", 
    "to": "#some-channel", 
    "time": 1415844019196 
    } 
} 

Когда вы получите это сообщение с сервера, вы испускают его как событие.

var handleMessage = function(envelope){ 
    myEventEmitter.emit(envelope.type, envelope.payload); 
}; 

Это форма диспетчера. Он просто получает событие и транслирует его всем, кто интересуется.Обычно заинтересованная сторона будет компонентом или магазином (в потоке).

var MessageList = React.createClass({ 
    componentDidMount: function(){ 
     myEventEmitter.on('new-message', this.handleNewMessage); 
    }, 
    handleNewMessage: function(message){ 
     if (message.to === this.props.channel) { 
      this.setState({messages: this.state.messages.concat(message)}); 
     } 
    }, 
    componentWillUnmount: function(){ 
     myEventEmitter.removeListener(this.handleNewMessage); 
    }, 
    ... 
}); 

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

Вы также можете сохранить список полученных сообщений в другом месте вашего кода (не в компоненте) или сделать запрос на получение последних сообщений с сервера.

Отправка html с сервера обычно является очень плохой, негибкой и неперспективной идеей. AJAX предназначен для получения данных клиенту, и клиент выбирает, как представлять эти данные пользователю.

+0

Чтение на флюсе это, кажется, стандартный подход, поэтому в данном случае рендеринг на стороне клиента является более или менее единственным вариантом? – ioseph

+0

Флюс - это один из подходов, некоторые используют его, а другие - нет. Вопрос в том, какая у вас причина для рендеринга на сервере? – FakeRainBrigand

+0

Мое мышление заключалось в том, что это могло бы повысить производительность на более медленных машинах/устройствах, поскольку приложение со временем станет чрезвычайно сложным. – ioseph

0

Если бы я выполнял роль сервера рендеринга, как изменения могли быть перенесены на каждого клиента?

Ну, вы только что сказали это, через Сокеты.

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

В случае приложения, в котором состояние может быть изменено сервером или другим клиентом, будет ли я вынужден использовать websockets/http polling для отображения этих обновлений?

Существует альтернатива WebSockets, называемая событиями на стороне сервера. Это похоже на WebSockets, но это односторонний, серверный> браузер. Браузер прослушивает серверные вещи так же, как и через WebSockets. Однако, связывая с сервером, вы можете использовать простой старый AJAX или формы или что угодно. Support is limited но есть полисы.

На самом деле, вы можете сделать то же самое с помощью WebSockets, просто используйте нижестоящую черту, но это может победить ее цель.