frontend icon indicating copy to clipboard operation
frontend copied to clipboard

Refactor `SideContentReducer`

Open RichDom2185 opened this issue 1 year ago • 7 comments

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

RichDom2185 avatar Mar 16 '24 10:03 RichDom2185

@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!

RichDom2185 avatar Mar 16 '24 10:03 RichDom2185

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 Coverage Status
Change from base Build 8678811571: 0.03%
Covered Lines: 5284
Relevant Lines: 14842

💛 - Coveralls

coveralls avatar Mar 16 '24 10:03 coveralls

Should we call createReducer every time? I think it's sufficient to perform the workspace location check, then just call the appropriate reducer

leeyi45 avatar Mar 20 '24 04:03 leeyi45

Should we call createReducer every 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?

RichDom2185 avatar Mar 20 '24 05:03 RichDom2185

Should we call createReducer every 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?

Do we need to capture workspaceLocation? Ideally the reducers should work for all workspaces right?

leeyi45 avatar Mar 21 '24 06:03 leeyi45

Should we call createReducer every 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?

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.

RichDom2185 avatar Mar 21 '24 07:03 RichDom2185

Should we call createReducer every 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?

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.

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?

leeyi45 avatar Mar 21 '24 16:03 leeyi45