feat(reducers): switch ordered to be just be keys instead of objects
See original GitHub issueI am not a 100% on this one, but I can’t immediately see why the same data is repeated between the firestore.data
and firestore.ordered
. This essentially doubles the size of the store and I can see how this becomes problematic for large apps with large documents if I want to persist state in localstorage.
Wouldn’t it be enough for firestore.ordered
to be simply an array of IDs so that I know the order of IDs and then get the data from the firestore.data
key?
Issue Analytics
- State:
- Created 4 years ago
- Reactions:2
- Comments:5 (4 by maintainers)
Top Results From Across the Web
Refactoring Reducers Example | Redux
Let's look at a demonstration of how a large single reducer function can be refactored into a composition of several smaller functions. Note: ......
Read more >React-Redux: Combining reducers: Unexpected Keys
Expected to find one of the known reducer keys instead: "events", "flash". Unexpected keys will be ignored. My initial state is passed in...
Read more >Understanding the magic behind StoreModule of NgRx ...
We'll examine how state, reducers, store and actions work with each other and ... initialState)) will combine all the reducers into one object,...
Read more >Redux Toolkit Combine Slices - polley-design
combineReducers takes an object full of slice reducer functions, and creates a function that outputs a corresponding state object with the same keys....
Read more >Learn mapStateToProps & Connect API - Frontend Masters
Steve demonstrates how to use mapStateToProps and reducers to pull and map objects from the Redux store instead of having a hard coded...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Yeah like I said, I agree that it is best practice to keep just the keys in the array, and that is what I use with other APIs anyways, so lets switch this to a ticket for capturing that. As always, I’m open to PRs if you get a chance to work on it.
Really glad to have folks giving input on the core architecture, especially on redux-firestore since it is still so young. Thanks for reaching out!
@illuminist In v1 the all subcollections are stored at the top level with the path in state including the name of the subcollection. With that in mind, all of the
ordered
state should just be a single level with different arrays of keys regardless of what level the in the collection/subcollection tree then data lives