-
-
Save markerikson/ad319fd7b04bd4eecdcfe7bf51dce7b1 to your computer and use it in GitHub Desktop.
// Example of using multiple / nested `createEntityAdapter` calls within a single Redux Toolkit slice | |
interface Message { | |
id: string; | |
roomId: string; | |
text: string; | |
timestamp: string; | |
username: string; | |
} | |
interface ChatRoomEntry { | |
id: string; | |
messages: EntityState<Message>; | |
} | |
const roomsAdapter = createEntityAdapter<ChatRoomEntry>(); | |
const messagesAdapter = createEntityAdapter<Message>(); | |
const fetchRooms = createAsyncThunk( | |
"chats/fetchRooms", | |
chatsAPI.fetchRooms | |
); | |
const fetchMessages = createAsyncThunk( | |
"chats/fetchMessages", | |
async (roomId) => { | |
return chatsAPI.fetchMessages(roomId); | |
} | |
) | |
const chatSlice = createSlice({ | |
name: "chats", | |
initialState: roomsAdapter.getInitialState(), | |
reducers: { | |
}, | |
extraReducers: builder => { | |
builder.addCase(fetchRooms.fulfilled, (state, action) => { | |
const roomEntries = action.payload.map(room => { | |
return {id: room.id, messages: messagesAdapter.getInitialState()}; | |
}); | |
roomsAdapter.setAll(state, roomEntries); | |
}) | |
.addCase(fetchMessages.fulfilled, (state, action) => { | |
const roomId = action.meta.arg; | |
const roomEntry = state.entities[roomId]; | |
if (roomEntry) { | |
messagesAdapter.setAll(roomEntry.messages, action.payload); | |
} | |
}) | |
} | |
}) | |
/* | |
Resulting state: | |
{ | |
ids: ["chatRoom1"], | |
entities: { | |
chatRoom1: { | |
id: "chatRoom1", | |
messages: { | |
ids: ["message1", "message2"], | |
entities: { | |
message1: {id: "message1", text: "hello"}, | |
message2: {id: "message2", text: "yo"}, | |
} | |
} | |
} | |
} | |
} | |
*/ |
@jeremyisatrecharm : yes, that's my point. getSelectors()
uses createSelector
inside. So, if you're using that in a reducer, there's a good chance that it's seeing the proxy wrapper and not detecting changes correctly.
Ah okay, I think one thing that confused me is the link you provided notes:
Besides re-exporting createSelector, RTK also exports a wrapped version of createSelector named
createDraftSafeSelector that allows you to create selectors that can safely be
used inside of createReducer and createSlice reducers with Immer-powered mutable logic.
...
All selectors created by entityAdapter.getSelectors are "draft safe" selectors by default.
and I am using upsertOne
inside reducers; so that made me think I wanted to use those selectors.
I'm all unblocked now - thank you!
Hmm. That's a good point, actually, I'd forgotten we do that, and thus there shouldn't be any update problems here 🤷♂️
How do you make a selector for nested properties?
AFAIK, it'd be something like below
export const messagesByIdSelector = createSelector(
curerntRoomSelector,
(state: RootState, messageId: EntityId) => messageId,
(room, messageId) => {
const items = room?.messages;
if (!items) {
return;
}
const allMessages = messageEntities
.getSelectors(() => items)
.selectAll(() => items);
return allMessages.find((item) => item.message_id === messageId);
}
);
I achieved the expected data, but the const allMessages = messageEntitties .getSelectors(() => items) .selectAll(() => items);
seems repeated many times.
Sorry for my ignorance, but I thought RTK encourages you to keep the state as flat as possible. We have a single API call that returns areaGroups
, each with an array of areas
. Our old Redux setup kept areas
within areaGroups
, but for RTK I was going down the path of separate areaGroups
and areas
entities.
const areaGroupsAdapter = createEntityAdapter();
const areasAdapter = createEntityAdapter();
const initialState = {
areaGroups: areaGroupsAdapter.getInitialState(adapterInitialState),
areas: areasAdapter.getInitialState(adapterInitialState)
};
export const entitiesSlice = createSlice({
name: 'entities',
initialState,
reducers: {},
extraReducers: builder => {
builder.addCase(SET_AREA_GROUPS, (state, action) => {
const { areaGroups, areas } = flattenAreaGroups(action.payload);
areaGroupsAdapter.upsertMany(state.areaGroups, areaGroups);
areasAdapter.upsertMany(state.areas, areas);
});
});
flattenAreaGroups
is a utility function that just extracts out the areas
and assigns an areaGroupId property before returning each entity type.
My plan was to create a selector such as selectAllAreasByAreaGroupId
.
Should I keep these entities nested?
(We're in the middle of migrating to RTK + Thunks so SET_AREA_GROUPS
is some leftover Saga hooha BS that'll be converted.)
@rickysullivan-gallagher : yeah, "flat" is a generally good state design principle, but like everything it's not an absolute. It can depend on how you expect the state to get both accessed and updated. No hard rule here.
Thanks for the reply, @markerikson. In the words of the great 90s punk rock band, The Offspring, I'm going to Keep 'Em Separated. I like the idea of knowing that each entity has its own home and along with it, auto-generated selectors to boot. Thanks for all your awesome work.
So I decided that I'd try my hand with nesting slices. This way I can keep all my entities reducers/thunks/selectors etc under their own slice, yet keep a top level "entities" slice. But i'm stumped. I can dispatch the actions, and see them working. I just can't workout how to get the slice reducers to combine in the parent slice. https://stackblitz.com/~/github.com/rickysullivan-gallagher/vitejs-vite-ctk89t
@rickysullivan-gallagher I'm not actually sure what you're trying to do there, and this gist isn't a great place to provide support :) Could you drop by the #redux
channel in the Reactiflux Discord ( https://www.reactiflux.com ) and ask there?
Will do @markerikson. I wasn't feeling confident this was the right place.
@markerikson thanks for the past response and for sharing - I didn't know about that.
I am not sure that's causing it, I am not using
createSelector
, simply making methods likeThen inside the reducer, this works:
But this doesn't: