2015-10-05 10 views
39

Мне интересно, как люди, использующие Redux, приближаются к их постоянному упорству. В частности, вы храните «действия» в базе данных или используете только последнее известное состояние приложения?Redux: Мнения/примеры того, как сделать упорство на бэкэнде?

Если вы храните действия, вы просто запрашиваете их с сервера, а затем воспроизводите их все, когда загружается данная страница? Не могли ли это привести к некоторым проблемам производительности с крупномасштабным приложением, где есть много действий?

Если вы сохраняете только «текущее состояние», как вы на самом деле сохраняете это состояние в любой момент времени, когда действия происходят на клиенте?

Есть ли у кого-нибудь примеры кода того, как они соединяют редукторы редукции с backis-хранилищем apis?

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

Спасибо всем.

+1

Я думаю, что бэкэнд обычно довольно классический (нормальный БД), не отличающийся от других приложений CRUD. Однако вас могут заинтересовать такие подходы, как https://www.rethinkdb.com и http://www.confluent.io/blog/turning-the-database-inside-out-with-apache-samza/. –

ответ

33

Определенно сохраняйте состояние своих редукторов!

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

Пример: сохраняется состояние одного редуктора на сервер

Мы начнем с тремя дополнительными типами действий:

// actions: 'SAVE', 'SAVE_SUCCESS', 'SAVE_ERROR' 

Я использую redux-thunk делать вызовы асинхронного сервера: это означает, что одно действие создатель может dispatch дополнительных действий и проверить текущее состояние.

Создатель действия save отправляет одно действие немедленно (чтобы вы могли показать счетчик или отключить кнопку «сохранить» в своем пользовательском интерфейсе). Затем он отправляет SAVE_SUCCESS или SAVE_ERROR действия после завершения запроса POST.

var actionCreators = { 
    save:() => { 
    return (dispatch, getState) => { 
     var currentState = getState(); 
     var interestingBits = extractInterestingBitsFromState(currentState); 

     dispatch({type: 'SAVE'}); 

     window.fetch(someUrl, { 
     method: 'POST', 
     body: JSON.stringify(interestingBits) 
     }) 
     .then(checkStatus) // from https://github.com/github/fetch#handling-http-error-statuses 
     .then((response) => response.json()) 
     .then((json) => dispatch actionCreators.saveSuccess(json.someResponseValue)) 
     .catch((error) => 
     console.error(error) 
     dispatch actionCreators.saveError(error) 
    ); 
    } 
    }, 

    saveSuccess: (someResponseValue) => return {type: 'SAVE_SUCCESS', someResponseValue}, 

    saveError: (error) => return {type: 'SAVE_ERROR', error}, 

    // other real actions here 
}; 

(нотабене $.ajax будет полностью работать на месте window.fetch вещей, я просто предпочитаю, чтобы не загружать весь JQuery для одной функции!)

Редуктор просто отслеживает любой запрос выдающегося сервера.

function reducer(state, action) { 
    switch (action.type) { 
    case 'SAVE': 
     return Object.assign {}, state, {savePending: true, saveSucceeded: null, saveError: null} 
     break; 
    case 'SAVE_SUCCESS': 
     return Object.assign {}, state, {savePending: false, saveSucceeded: true, saveError: false} 
     break; 
    case 'SAVE_ERROR': 
     return Object.assign {}, state, {savePending: false, saveSucceeded: false, saveError: true} 
     break; 

    // real actions handled here 
    } 
} 

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

Я надеюсь, что это помогает, это работает хорошо так далеко для меня!

+0

Спасибо за вход Dan! Кажется, это работает хорошо! – Lee

+1

Это отличная помощь.Сторона примечания: если вы храните как уменьшенное состояние, так и действия, вы можете использовать методы проектирования, основанные на событиях, чтобы обеспечить возможность перемещения на стороне сервера или управления версиями на стороне сервера. Полезно для некоторых вещей! –