Мое приложение загружает данные из 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
спасибо - можете ли вы расширить свою точку фильтрации? ссылается на каждый obj субоптимальный, по производительности? В конечном итоге я включу фильтр с использованием пользовательских параметров, и я намеревался поместить его в mapStateToProps - это то, что вы имеете в виду? – Brandon
Если у вас есть параметры, по которым вы фильтруете данные (в состоянии, возможно, что-то статичное), вы можете фильтровать состояние перед передачей его компоненту. Это скорее архитектурный вопрос, чем производительность в целом, но в вашем случае вопрос заключается в необходимости ссылки на каждый объект или только на некоторые? Будете ли вы использовать каждый объект? Если нет, вы можете создать список объектов только с теми, которые вам нужны. –
это имеет смысл. данные в основном представляют собой список записей пользователя, поэтому текущий предполагаемый ux - это то, что пользователь видит все записи в табличной форме при загрузке, а затем может применять фильтры по мере необходимости. если я правильно вас понимаю, если позже я выясню, что пользователь интересуется только некоторым подмножеством своих записей при первой загрузке, я думаю, что ваш метод фильтрации перед переходом на компонентные звуки, как будто он был бы оптимальным. – Brandon