2016-02-19 5 views
1

Мое приложение загружает данные из Firebase в хранилище Redux при загрузке. Он загружается как объект, содержащий несколько сотен вложенных объектов.Хранение данных из хранилища Redux в другой структуре данных

Чтобы отобразить компонент таблицы (в частности, this one) для этих данных, я должен преобразовать его в массив объектов.

Мое текущее решение, чтобы преобразовать его в компонент таблицы mapStateToProps() как это (с помощью lodash библиотеки):

function mapStateToProps(state) { 

    return { 
     listingsData: _.values(state.config) 
    } 
} 

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

Мой вопрос: делает ли этот способ выполнения вещей в 2 раза потребление памяти для моего приложения (массив + магазин)?

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

Если это 2x память, есть ли более эффективный способ сделать это?

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

var x = {a:{var:1}, b:{var:2}, c:{var:3}}; 
var y = _.values(x); 

console.log(x, y); //values match 

x.a.var = 99; 

console.log(x, y); //values still match 

ответ

1

Насколько я понимаю _.values ​​функцию из loadash (не работает с loadash), в вашем случае, если вы не удвоение памяти (клонирование объектов) , но создавая массив ссылок на те объекты, которые у вас есть в магазине, все в порядке.

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

+0

спасибо - можете ли вы расширить свою точку фильтрации? ссылается на каждый obj субоптимальный, по производительности? В конечном итоге я включу фильтр с использованием пользовательских параметров, и я намеревался поместить его в mapStateToProps - это то, что вы имеете в виду? – Brandon

+0

Если у вас есть параметры, по которым вы фильтруете данные (в состоянии, возможно, что-то статичное), вы можете фильтровать состояние перед передачей его компоненту. Это скорее архитектурный вопрос, чем производительность в целом, но в вашем случае вопрос заключается в необходимости ссылки на каждый объект или только на некоторые? Будете ли вы использовать каждый объект? Если нет, вы можете создать список объектов только с теми, которые вам нужны. –

+0

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