frontend
frontend copied to clipboard
Refactor `SideContentReducer`
Description
Refactors SideContentReducer to use "RTK" and Immer, as well as splitting the logic of stories and non-stories side content into separate sub-reducers for better readability.
Type of change
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] This change requires a documentation update
- [x] Code quality improvements
How to test
Checklist
- [x] I have tested this code
- [ ] I have updated the documentation
@leeyi45 could I ask for your thoughts/preliminary comments on this proof-of-concept refactoring? If it's all good, I'll proceed to refactor the rest of the reducer.
Thanks!
Pull Request Test Coverage Report for Build 8678817523
Details
- 17 of 25 (68.0%) changed or added relevant lines in 1 file are covered.
- No unchanged relevant lines lost coverage.
- Overall coverage increased (+0.03%) to 33.11%
| Changes Missing Coverage | Covered Lines | Changed/Added Lines | % |
|---|---|---|---|
| src/commons/sideContent/SideContentReducer.ts | 17 | 25 | 68.0% |
| <!-- | Total: | 17 | 25 |
| Totals | |
|---|---|
| Change from base Build 8678811571: | 0.03% |
| Covered Lines: | 5284 |
| Relevant Lines: | 14842 |
💛 - Coveralls
Should we call createReducer every time? I think it's sufficient to perform the workspace location check, then just call the appropriate reducer
Should we call
createReducerevery time? I think it's sufficient to perform the workspace location check, then just call the appropriate reducer
How can we capture workspaceLocation via closure, in that case?
Should we call
createReducerevery time? I think it's sufficient to perform the workspace location check, then just call the appropriate reducerHow can we capture
workspaceLocationvia closure, in that case?
Do we need to capture workspaceLocation? Ideally the reducers should work for all workspaces right?
Should we call
createReducerevery time? I think it's sufficient to perform the workspace location check, then just call the appropriate reducerHow can we capture
workspaceLocationvia closure, in that case?Do we need to capture
workspaceLocation? Ideally the reducers should work for all workspaces right?
That's true, I had originally thought that it might be not very ideal to have to write a
const workspaceLocation = // ...
const sideContentState = // ...
every time. But now that I think of it, the duplicated getWorkspaceLocation calls in newWorkspaceLocation make more sense.
But I still feel that the reducer should be split between stories and non-story workspace locations. What do you think of something like:
export const SideContentReducer = (state, action) => {
state = storiesSideContentReducer(state, action);
state = nonStoriesSideContentReducer(state, action);
return state;
};
const storiesSideContentReducer = createReducer(
defaultSideContent,
builder => {
builder.addCase(someAction, (state, action) => {
if (action.payload.workspaceLocation === 'stories') {
// ... logic here
}
});
}
);
const nonStoriesSideContentReducer = createReducer(
defaultSideContent,
builder => {
builder.addCase(someAction, (state, action) => {
if (action.payload.workspaceLocation !== 'stories') {
// ... logic here
}
});
}
);
That way we group all the logic for non-story and stories together.
Though ideally, we remove the duplication entirely since the only differences would be how we access sideContentState.
Should we call
createReducerevery time? I think it's sufficient to perform the workspace location check, then just call the appropriate reducerHow can we capture
workspaceLocationvia closure, in that case?Do we need to capture
workspaceLocation? Ideally the reducers should work for all workspaces right?That's true, I had originally thought that it might be not very ideal to have to write a
const workspaceLocation = // ... const sideContentState = // ...every time. But now that I think of it, the duplicated
getWorkspaceLocationcalls innewWorkspaceLocationmake more sense.But I still feel that the reducer should be split between stories and non-story workspace locations. What do you think of something like:
export const SideContentReducer = (state, action) => { state = storiesSideContentReducer(state, action); state = nonStoriesSideContentReducer(state, action); return state; }; const storiesSideContentReducer = createReducer( defaultSideContent, builder => { builder.addCase(someAction, (state, action) => { if (action.payload.workspaceLocation === 'stories') { // ... logic here } }); } ); const nonStoriesSideContentReducer = createReducer( defaultSideContent, builder => { builder.addCase(someAction, (state, action) => { if (action.payload.workspaceLocation !== 'stories') { // ... logic here } }); } );That way we group all the logic for non-story and stories together.
Though ideally, we remove the duplication entirely since the only differences would be how we access
sideContentState.
I guess if we want to maintain the difference between story and non-story side content we could do that
What I had in mind was more like:
export const SideContentReducer = (state, action) => {
const [workspaceLocation, storyEnv] = getLocation(action.payload.workspaceLocation)
if (workspaceLocation === 'stories') {
const workspace = state.stories[storyEnv]
return {
...state,
stories: {
...state.stories,
[storyEnv]: reducer(workspace)
}
}
}
// and the same for non-story workspace locations
}
The whole idea is to treat each workspace identically. But I guess that's less idiomatic?