econplayground.js

Nov 14, 2022: This code is now managed in the Django project’s repository here: https://github.com/ccnmtl/econplayground

econplayground.js

Environment for authoring and interacting with economics graphs. This React application is intended to be used with the Django back-end found here: https://github.com/ccnmtl/econplayground

Requirements

You need to install these packages in order to build econplayground. These are all requirements of mathjax.

Debian:

• libfreetype6-dev
• pkg-config
• libcairo2-dev
• g++
• libjpeg-dev

macOS / homebrew:

• freetype
• pkg-config
• cairo
• jpeg-turbo
• You will also need a C++ compiler, which can be installed through Apple’s “Command Line Development Tools” download.

Development Notes

Here’s how to develop econplayground.js in the econplayground django application:

• cd econplayground
• ./scripts/link.sh
• make runserver

Then, in a new terminal:

• cd ~/public_html/econplayground.js
• make dev

Now you can make changes in the econplayground.js repository, and the build will be updated when you access the tool in the Django application.

Overview

The Django application displays either Viewer.js or Editor.js. The graph create route displays Editor.js, while the graph detail route displays Editor.js. The Editor and Viewer in turn render either GraphEditor or GraphViewer, which contain the actual DOM elements. Note that if an instructor visits the detail route of a graph, Viewer.js gives them a GraphEditor, not a GraphViewer, because instructors can edit graphs.

I’m not using react-redux for XHR calls. To me, redux seems like a complicated solution to very simple problems: GET, PUT, and POST requests. I realize there are more complicated situations where I’m sure it’s indispensable, but for now, I’ve been fine without it. But again, I need to branch out more and see how other people are using redux. Because it’s also true that I just don’t know how to use redux.

So instead of using redux, I’m connecting state to the django server with a few fetch calls, and a mapping to the Graph model in GraphMapping.js. If you look at, for example, how I’m instantiating the GraphEditor in Editor.js, you can see that I’m passing in tons of attributes to the GraphEditor. The properties that are part of the Graph model are prepended with ‘g’ - these are the properties sent to and from the API via GraphMapping.js. These have been slowly growing over the course of development. I made the decision early on to just do it this way and run with it. What I gain out of this is that React is aware of any changes to any of these attributes, and is able to keep everything up to date throughout the entire application. For example, if I update line 1’s slope, the jsxgraph part of the application is notified, and the change is displayed immediately. At the same time, the rest of the application is still up to date and ready for a new PUT request to the API if I want to save this change.

I don’t think I would reap that same benefit if I was passing along a graph object throughout my application, but there may be ways of achieving the same ends that I’m not aware of yet. There’s a discussion about this here.

Anyways, I took this method and ran with it for the time being because it just works, and will continue to, because it’s just using the basic notion of React props and state.

This site is open source. Improve this page.