Page tree
Skip to end of metadata
Go to start of metadata

There is a lot of interest in having edX move from Backbone to React for rich client-side application work. See Modernizing the edX front end stack for an analysis of the various ways in which React would be beneficial to Open edX as a platform. This document describes how we propose to evaluate React though a short one-sprint spike.

What are we evaluating?

  • ES2015
  • React
  • Redux
  • Webpack
  • Benefits of having complex UI live outside edx-platform

Benefits of React

There are a number of benefits that we see to moving to React:

  • state management
  • repaint speed
  • modular UI through components
  • developer productivity
  • better debug tools
  • larger pool of developers
  • framework in active development
  • active community
  • better integration with modern tooling

Why React versus other frameworks:

  • React is less opinionated and so can mix with other libraries
  • incremental adoption in existing Backbone pages
  • well defined upgrade path from Backbone
  • clear separation of rendering versus state management

Goals

  • Product
    • Demonstrate the ability to fix bugs more easily
    • Demonstrate the ease of switching to the new (mobile-friendly) Discussion API
  • Architecture
    • Support edX discussions as a pluggable feature
    • Reduce the size and complexity of edx-platform
  • Engineering
    • Demonstrate viability of React for complex client-side applications
    • Determine the relative complexity of React code versus Backbone for the same functionality
    • Improve turnaround time for developers when making changes
    • Demonstrate how XBlocks can interact with React
    • Provide examples for the community that wish to use React with edX
    • Demonstrate how well React can work with the edX Pattern Library

Spike

The detailed plan is as follows:

  • create a new edx-discussions repo
  • implement a React-based UI which implements a self-contained aspect of the Discussion UI
    • Use the new Discussion API to fetch data
    • Render the view of a single post
    • Have the ability to add comments to the post
    • Show a list of posts to allow simple navigation to the post
    • Use Redux, primarily so that it can hydrate the initial state from the server

    • Ensure that hot swapping works for efficient development

    • Note: no ability to add a new post
  • provide both an XBlock and a full page version of the UI
    • register a new XBlock entry point (with a different name than the current Discussion XBlock)
    • Support viewing the XBlock within the XBlock Workbench
    • Provide an index.html to render the full page version (aka the Discussion Board)
    • Add routing support to navigate between the list of posts and an individual post
  • integrate the new Python package into edx-platform
    • pip install the package
    • the XBlock should automatically be picked up
    • register a new Discussion tab that renders an empty div and then includes the JS into the page
    • decide how to consume the static assets
      • should the Python package include pre-bundled JavaScript and CSS?
      • should raw files be provided as input to the edx-platform pipeline?
      • probably still want the raw files for developers in debug mode
    • Note: hot swapping will not be supported within edx-platform
  • provide some limited set of tests 
    • React unit tests should be straightforward with Jasmine and Karma
    • Python unit tests implemented using Nose
    • Determine how to write integration tests for the XBlock that test Python and JavaScript (maybe out-of-scope for the spike)
  • technical details
    • Will need to determine how the XBlock can declare its dependencies (or do we just hard-code React into edx-platform in the branch?)
    • Use the Pattern Library for the styling, plus bare bones styling of custom HTML elements
    • Use Babel for ES2015 support
    • Use ESLint to lint the code (will need a new ES2015 version of the linting rules)
    • Support hot swapping for the index.html page for rapid development

Rubric

The following are the criteria by which React will be evaluated against Backbone:

CriteriaBackboneReactConclusion
How fast were the JavaScript aspects implemented?N/A

Refresh time for a single JS change


Refresh time for a single CSS change


JavaScript code complexity for keeping all subviews in sync


JavaScript code complexity for managing navigation history


CPU performance for complex repaint


See Also

  • No labels

1 Comment

  1. First off: Thank you so much for tackling this. Our front end stack desperately needs reworking, and I'm so happy that you folks are getting cycles to do this.

    One of the big questions/concerns I have for any framework is how we plan to deal with version differences and upgrades in mixed environments – especially in the case of something like XBlocks, where we are not the primary authors. Say the pattern library and toolkit get widespread adoption (and eventually a v2). Say our plan for making more of the UI pluggable (course nav, instructor dashboard, whatever else) is successful, and we see growth in that area comparable to what we have with XBlocks. Assume the current trend of third party XBlocks continues, and they start adopting pattern library/toolkit components, but inconsistently. How does all of that hold together as we update versions? What assumptions will we allow about the availability of React or other libraries?

    Do we have a writeup of what React/Redux means for XBlocks and their interaction with each other? Do we have to set up stricter barriers in parent/child communication?

    I think that doing a proof of concept where you folks use the discussion API to create a new UI will yield a great developer experience. You're free from most of the baggage of edx-platform, and can really stretch your legs. I believe that it's absolutely a worthwhile exercise to compare against the existing implementation and state modeling when doing the comparison against Backbone, and an important part of the evaluation process.

    But in addition to that, I'd also like to understand the logistics of how this will work and what our long term pluggable platform story is with these technologies.