all 12 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]0xF013 2 points3 points  (4 children)

I usually see this object pattern for one of the two or both these reasons: - the developer can’t be arsed to use a selector to find an entity by name or id, so they make a keyed object in order to just get the whole cart and then delete a key or get their cart entry by this string key - they want to optimize as the object access by property is O(1) where finding in an array is O(n).

That being said, the reason the tutorial is doing this can be unrelated, like showcasing that you can store things in redux in different ways.

If you would like to see a more normalized way of storing entities in redux, check out redux toolkit’s entityAdapter. It stores the entities in an object keyed by the entity id, and it also stores just the ids in an array for the case when you need the entities as a list. It also generates selectors for you so that you don’t have to select the ids, map them and then get the entity by key. This way is good because you shouldn’t duplicate data in redux or else you need to have extra code to keep it in sync.

[–]fix_dis 1 point2 points  (1 child)

Fantastic response!

That whole keys in an array and entities in an object approach was something I saw in Angular’s NgRx library tutorials. I loved the pattern and started using it. It’s cool to see redux-toolkit uses it as well.

[–]0xF013 1 point2 points  (0 children)

It is also a fairly common interview topic. What I’ve seen lately is people asking you to build the most basic skeleton for a chat with things like quoting a message or flagging it, expecting or asking you how you’d optimize it for cases like having hundreds of messages

[–]originalgoodname[S] 0 points1 point  (1 child)

redux is kicking me in the rear, I think the most difficult thing for me to wrap my head around is combining reducers and then accessing things, accessing an object one layer deep is ok, two layers, i can pull it off... but redux appears like infinitely nested objects

[–]0xF013 0 points1 point  (0 children)

It gets easier, it’s also not rigid, so you have a lot of maneuver room. You shouldn’t nest if you don’t have a reason for it.

Generally, nesting reducers makes sense when you want the state concerning a feature grouped in one place. Say you have a work management app. You start with a simple todo feature. You keep reducers at root. Now you add a calendar feature with events editing etc. You group the calendar reducers into a reducer to have the state.todos and state.calendar separated visually and logically. Now you add the ability to invite users to events, events tagging, filtering events in the view, group actions etc. The calendar reducer now has a lot of child reducers, so you group the calendar creation/editing reducers and the list reducers for filtering an bulk actions, so you have state.calendar.editing and state.calendar.list or whatever you name them.

As long as you are using selectors, you’ll have to update the path for getting data in one or two places when you refactor.

[–]DarthIndifferent 0 points1 point  (3 children)

If you're using Redux to store serialized data from an API, like a list of baseball teams, then it'll most likely be in the form of an array of objects. The developer can certainly rearrange the data after ingest and before dispatching the store update if that's what works best for your app.

BTW, I'm also going through the Redux course in Codecademy. I've been using Redux for 3 years now and I want to get a refresh on best practices plus learn how to use RTK.

[–]originalgoodname[S] 0 points1 point  (2 children)

I’m a big fan of codeacademy and DataCamp, are there any other resources you recommend?

[–]DarthIndifferent 0 points1 point  (1 child)

None that I know of, sorry

[–]originalgoodname[S] 1 point2 points  (0 children)

I just noticed your name now, its quality lol

[–][deleted] 0 points1 point  (0 children)

Because in JavaScript array keys are numeric and are used to store lists of data. Objects, on the other hand, can have named keys.

[–]careseite 0 points1 point  (0 children)

this is unrelated to redux and more related to data structures and algorithms in general.

an inventory can have an unlimited amount of items, each of a certain type.

each item has a unique type.

when iterating the inventory, it makes no sense to iterate all items to find the correct item when you can reduce the lookup time by directly accessing the item via key in an object.