Flux Dispatch.dispatch (...) не может отправить в середине отправки

Мой код https://gist.github.com/ButuzGOL/707d1605f63eef55e4af Flux Dispatch.dispatch (...) не может отправить в середине отправки

Так что, когда я получаю знак в успех обратного вызова Я хочу сделать редирект,
редирект работает через диспетчера слишком.

И я получаю Dispatch.dispatch (...): Не могу отправить сообщение в середине отправки.

Есть ли какой-либо взломать вызов в середине?

источник

2014-10-27 ButuzGOL

Я не вижу, где в сущности, что вы отправили, вы делаете перенаправление. Я вижу действия AUTH_SIGNIN и AUTH_SIGNIN_SUCCESS, и они выглядят довольно просто.

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

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

источник

2014-10-27 05:48:47 fisherwebdev

+17

На самом деле это очень распространено, что, например, компонент А создает действие, которое изменяет магазин B какой компонент C прослушивает, и в ответном компоненте C необходимо получить данные с сервера, который является действием, но диспетчер все еще отправляет, поэтому он не может. Решение этого кажется довольно взломанным для меня (обертывание действия выборки в setTimeout или аналогичном) – Esailija

Я думаю, что лучше всего не вызывать отправку для * запуска * запроса (единственная причина, по которой это нужно сделать, - показать загрузочные прядильщики и т. Д. в любом случае, но на самом деле это не фактические данные приложения, а скорее состояние компонента). – Esailija

Компоненты не должны решать, когда извлекать данные. Это логика приложения на уровне представления. Эта логика принадлежит магазину, который может сбить XHR, а затем обратный вызов ошибки/успеха создает действия с новыми данными. – fisherwebdev

Вы можете заставить его работать на «планирование» следующее действие вместо того, чтобы называть его непосредственно, вот пример код:

// instead of doing this 
Dispatcher.dispatch(...); 

// go like this 
setTimeout(function() { 
    Dispatcher.dispatch(...); 
}, 1);

Это заставит вашу следующая отправка будет называться позже из текущей отправки процесс, и ошибки не будет.

Если ваш код отправки находится в обратном вызове любой другой асинхронной операции, которая также будет работать (например, в ответе на запрос Ajax).

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

источник

2015-04-02 22:53:29

shitty, но работает для меня –

uuughhh - setTimeout хаки ужасны. Лучше использовать обещания –

@DanOsborne Я не думаю, что обещает решить что-либо здесь, так как они автоматически не завершают текущий поток выполнения, как это делает 'setTimeout'. Если я не понимаю, не могли бы вы привести пример? Благодаря! –

дребезга является лучшим решением:

var _ = require('lodash'); 
var CHANGE_EVENT = "change"; 
var ApplicationStore = _.extend({}, EventEmitter.prototype, { 

    emitChange: function() { 
    this.emit(CHANGE_EVENT); 
    }, 

    addChangeListener: function(callback) { 
    this.on(CHANGE_EVENT, _.debounce(callback, 100)); 
    }, 

removeChangeListener: function(callback) { 
    this.removeListener(CHANGE_EVENT, callback); 
    }, 

    getState: function(){ 
    return { 
     showConsole: _showConsole 
    } 
    } 
});

источник

2016-03-28 08:09:14 backslash112

Это не правильный способ сделать это, потому что когда вы используете функцию debouncing, вы получите другую, поэтому удаление прослушивателя изменений не будет работать так, как ожидалось, вызывающие вызовы имеют другой контекст – Kamil

@Kamil _.debounce (callback) .cancel() ; – backslash112

-1

вы можете пользователя по «отложить» вариант диспетчера. В вашем случае это будет примерно так:

Dispatcher.dispatch.defer(...);

источник

2016-10-10 22:30:35 abhisekpaul

Диспетчер не имеет метода отсрочки. 'Uncaught TypeError: _dispatcher.dispatcher.dispatch.defer не является функцией' – rosencreuz

Вы можете проверить, если диспетчер находится диспетчерская, таких как:

if(!MyDispatcher.isDispatching()) { 
    MyDispatcher.dispatch({...}); 
}

источник

2017-03-31 14:03:54 Max

Flux Dispatch.dispatch (...) не может отправить в середине отправки

ответ

Смежные вопросы