Флюс без кэширования данных?

Question

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

В системе я думаю об использовании React/Flux, у одного пользователя может быть 100 тысяч тысяч основных данных, которые мы храним (и 1 запись, вероятно, имеет не менее 75 свойств данных). Кэширование этого большого количества данных на стороне клиента кажется плохой идеей и, вероятно, делает вещи более сложными.

Если бы я не использовал Flux, у меня просто была бы ORM-система, которая может разговаривать с REST API, и в таком случае запрос, как userRepository.getById(123), всегда будет работать с API независимо от того, запрашивал ли я данные на последней странице. Моя идея состоит в том, чтобы иметь в магазине эти методы.

Неужели Flux считает, что если бы я должен был запрашивать данные, они всегда попадали в API и никогда не извлекали данные из экземпляра локального кеша? Могу ли я использовать Flux таким образом, что большинство запросов на поиск данных всегда попадают в API?

Answer 1

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

Answer 2

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

В качестве альтернативы флюсу вы можете просто использовать обещания и простой mixin с api для изменения состояния. Например, с Блюберд:

var promiseStateMixin = { 
    thenSetState: function(updates, initialUpdates){ 
    // promisify setState 
    var setState = this.setState.bind(this); 
    var setStateP = function(changes){ 
     return new Promise(function(resolve){ 
      setState(changes, resolve); 
     }); 
    }; 

    // if we have initial updates, apply them and ensure the state change happens 
    return Promise.resolve(initialUpdates ? setStateP(initialUpdates) : null) 
     // wait for our main updates to resolve 
     .then(Promise.params(updates)) 
     // apply our unwrapped updates 
     .then(function(updates){ 
      return setStateP(updates); 
     }).bind(this); 
    } 
}; 

И в ваших компонентов:

handleRefreshClick: function(){ 
    this.thenSetState(
     // users is Promise<User[]> 
     {users: Api.Users.getAll(), loading: false}, 

     // we can't do our own setState due to unlikely race conditions 
     // instead we supply our own here, but don't worry, the 
     // getAll request is already running 
     // this argument is optional 
     {users: [], loading: true} 
    ).catch(function(error){ 
     // the rejection reason for our getUsers promise 
     // `this` is our component instance here 
     error.users 
    }); 
} 

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