{ "componentChunkName": "component---src-templates-blog-post-js", "path": "/blog/2018-01-28-on-the-importance-of-cleaning-up-after-your-react-component/", "result": {"data":{"markdownRemark":{"html":"

For the past few months, I've been working on/leading a pretty large feature\ngenerically named \"Assignments.\" It provides the ability for any admin on\nour platform, Learn, to give a student something to do.\nThat sounds simple enough in theory, but we had to build this feature with a lot\nof flexibility.

\n

Each assignment is due at a certain time and can have\nseveral collaborators who are also admins on Learn. In addition, each assignment has\nmultiple tasks that have many types. For example, a task can be either a\ncode challenge or a to-do, can have a submission type of url or checkbox,\nand can have a reviewable type of none, confirmed, or graded.

\n

The abundance of types makes this project unwieldy. That and the conflation\nof task with assignment because although we were designing this system to be\ngeneric, the primary immediate use case (for code challenges) was incredibly\nspecific. I'm not quite convinced that we handled the types sustainably, but\nit suffices for now. As the credo goes, make it work, make it right, make it\nfast. We definitely made it work...so I'm okay with that.

\n

Here are some sick gifs from our QA pass of the feature for your viewing pleasure.

\n

Admin Assignments Dashboard and Editor

\n

\"Admin

\n

Student Assignment Submission

\n

\"Student

\n

Admin Assignments Grading

\n

\"Admin

\n

Anyway, the feature has a React-Redux front end and a Rails backend. We\ndesigned the backend using domain-driven design (DDD), and as a result, in\nmany places, the backend feels more like the Phoenix framework than Rails.\nBy the way, Rails gets super angry about autoloading when you heavily\nnamespace. And when Rails gets angry, I also get angry, well, more\nfrustrated than angry.

\n

The Problem

\n

There are a ton of complex views that need varying amounts of data. But one\nissue that kept cropping up repeatedly while we built this feature was that\nwe kept forgetting to clear out the old assignment data when our routes and\nviews changed.

\n

We're using React Router to manage routes in our front-end app. This allows\nus to display different components when the routes change, or, in other\nwords, maintain state in the URL. But, when you try to render two different\ncomponents based on the state of a data at the same URL, things can get\ntricky.

\n

To illustrate the problem, I'll point to a specific case I recently solved.\nWhen an assignment is in a draft state, it's URL is basically\nBASE_URL/assignments/:id, where the id is the primary key of the\nassignment record. However, after the assignment is published, the URL\nstays the same, but we instead display a grading view of the assignment\nrather than the editing view. One URL: two very different components.

\n

To determine which view we display, we need to know some information about the\nassignment. However, we won't know that information at the time the\ncomponent renders because we have to ask the backend for that data.

\n

I thought about this for a long time and the simplest solution I could think\nof was to have a component that renders and mediates which component to\ndisplay: the Editor component or the Grading component. I also tossed\naround the idea of having the grading portion live at a different URL, but\nthat became a little unwieldy because the grading view has another two\nsubviews that we display: an overview as well as a master-detail view.

\n

So, I started with creating a new component I titled the\nAssignmentDirector.

\n

Here's a snippet from the pack file where our primary routes are declared:

\n
  render((\n    <Provider store={ store } >\n      <Router basename='/admin/assignments'>\n        <Switch>\n          <Route path='/:id(\\d+)/:activeTab?' component={ AssignmentDirector } />\n          <Redirect from='*' to='/search/assignments' />\n        </Switch>\n      </Router>\n    </Provider>\n  ), assignmentsContainer)\n
\n

When the route matches, we render the AssignmentDirector component, and we\ndon't yet have the data we need. Even\nthose few microseconds of waiting can throw an error in the view.

\n

The AssignmentDirector component below is a Redux-connected component\nreponsible for determining which sub-component to display.

\n
\nclass AssignmentDirector extends Component {\n  componentDidMount() {\n    const { fetchAssignment, history } = this.props\n    const { id } = this.props.match.params\n\n    fetchAssignment(id)\n      .catch(e => history.replace('/search/assignments'))\n  }\n\n  componentDidUpdate(prevProps) {\n    const { fetchAssignment, history } = this.props\n    const { id } = this.props.match.params\n\n    if (prevProps.match.params.id !== id) {\n      fetchAssignment(id)\n        .catch(e => history.replace('/search/assignments'))\n    }\n  }\n\n  render() {\n    if (this.props.loading) {\n      return <Spinner containerHeight={125}/>\n    }\n\n    if (this.props.published) {\n      return <GradingContainer\n        history={this.props.history}\n        id={this.props.match.params.id}\n      />\n    }\n\n    return (\n      <EditorContainer\n        activeTab={this.props.match.params.activeTab}\n        history={this.props.history}\n      />\n    )\n  }\n}\n\nconst mapStateToProps = ({assignments}) => {\n  return {\n    assignment: assignments.editor.active,\n    publishAssignmentModalOpen: assignments.editor.publishAssignmentModalOpen\n  }\n}\n\nexport default connect(mapStateToProps, {fetchAssignment})(AssignmentDirector)\n
\n

When the AssignmentDirector component mounts, we ask the backend for\ninformation on that assignment. If it doesn't exist or throws an error, we\nredirect to the dashboard's home. While that assignment is fetching, we\ndisplay a loading indicator. When the assignment data is received, we flip\nthe loading key to false and because the props have changed, the component\nre-renders. As you might be able to tell, the AssignmentDirector is\nreading its state from the editorReducer.

\n

In the render function, the next set of logic should execute. If the\nassignment is published, we render the GradingContainer. Otherwise, we'll\nrender the EditorContainer.

\n

One complication is that the fetching of the assignment actually returns all\nthe data required for the Editor but not the Grader. In a perfect world,\nwe'd probably rewrite that, but to cut down on network requests, I think\nthis works for the time being.

\n

So once again, if the assignment is published, we render the GradingContainer, which then\nissues a request to get the grading summary for the assignment. That request\nupdates a different key in our redux store and is actually handled by the\ngraderReducer rather than the editorReducer.

\n
// editorReducer.js\n\nexport default (state = defaultState, action) => {\n  const { type, payload } = action\n  const { active } = state\n\n  switch (type) {\n    case RECEIVE_ASSIGNMENT:\n      return { ...state,\n        active: payload,\n        loading: false,\n      }\n
\n

Here, the editorReducer responds to the RECEIVE_ASSIGNMENT action and\nupdates state accordingly.

\n

Let's say that when this assignment was received, it was actually published.\nIn that case, the GradingContainer would render.

\n

For simplicity, I'm only showing part of the component's code.

\n
// GradingContainer\n\nclass GradingContainer extends Component {\n  componentDidMount() {\n    const { id, fetchAssignmentGradingSummary, history } = this.props\n    fetchAssignmentGradingSummary(id, history)\n  }\n\n  componentWillUnmount() {\n    this.props.clearActiveStudent()\n    this.props.clearAssignmentGradingSummary()\n  }\n\n  render() {\n    return (\n      //some markup\n    )\n  }\n}\n\nconst mapStateToProps = ({\n  assignments: {\n    grader: {\n      gradingSummary: {\n        assignment\n      },\n      gradingSummaryLoading\n    }\n  }\n}) => ({\n  assignment,\n  gradingSummaryLoading\n})\n\nexport default withRouter(connect(mapStateToProps, {\n  clearActiveStudent,\n  clearAssignmentGradingSummary,\n  fetchAssignmentGradingSummary\n})(GradingContainer))\n
\n

So, when the GradingContainer mounts, we dispatch an action to fetch the\ngrading data. That action eventually updates the state in graderReducer.

\n
// graderReducer\n\nexport default (state = defaultState, { type, payload }) => {\n  switch (type) {\n    case RECEIVE_ASSIGNMENT_GRADING_SUMMARY:\n      return {\n        ...state,\n        gradingSummaryLoading: false,\n        gradingSummary: {\n          ...payload\n        }\n      }\n  }\n}
\n

Now, when the GradingContainer unmounts, you see that I was smart enough\nto remember to clean up the data in the store, but the AssignmentDirector\nis still hooked up to the editorReducer and looking at the state of the\nassignment in there.

\n

This discrepancy resulted in odd behavior on the front end. When you clicked\non a published assignment from the dashboard and then clicked onto an\nunpublished one, you'd momentarily see a flash of the grading view before\nthe assignment fetch resolved. You'd also see a 500 request appear in the\nconsole.

\n

I spent some time hanging out in the Redux Dev Tools inspector and noticed\nthat the FETCH_STUDENT_ASSIGNMENT_GRADING_SUMMARY kept getting called\nbefore the FETCH_ASSIGNMENT action. Even though the URL was changing, the\nAssignmentDirector was still trying to render the GradingContainer!

\n

And that's when I realized that the\nAssignmentDirector wasn't getting updated in the right order when the\nassignment and URL changed.

\n

To fix this, I added an action to clear the active assignment from the\neditorReducer when the AssignmentDirector unmounts, which reset the\ndefaults for the assignment and the loading state within the\neditorReducer and stop the GradingContainer from rendering prematurely.

\n
  componentWillUnmount() {\n    this.props.clearActiveAssignment()\n  }
\n

And that, friends, is why it's important to clean up after your React\ncomponents.

","frontmatter":{"title":"On the Importance of Cleaning Up After Your React Component"}}},"pageContext":{"slug":"/blog/2018-01-28-on-the-importance-of-cleaning-up-after-your-react-component/"}}, "staticQueryHashes": ["3128451518","3649515864"]}