- This is so that if a site loads slowly users know which/how many problems they need to wait for.
- Spinner gets replaced automatically by problem content when it loads.
Before this commit, calling the student_view on a capa problem would
cause it to render an empty placeholder <div>, wait for the
DOMContentLoaded event to be fired, and then make AJAX requests to the
the problem_get handlers to retrieve the HTML it needed to render the
actual problems. This can significantly increase the end user load
times for pages, particularly when there are many problems in a
vertical.
This commit takes a very conservative approach and has the server side
add the rendered HTML into a new data-content attribute on the <div>
enclosing the problem. When Capa's JS initialization runs, it grabs
from that data-content attribute rather than reaching over the network
for an AJAX request.
I had attempted to make it somewhat smarter and push the rendered
problem straight into the document instead of relying on the
data-content attribute. This was faster, and should be our long term
goal. However, it caused odd bugs, particularly around MathJAX
rendering, and I never quite tracked the issue down. I'm still going
forward with these changes because it's significantly better than the
current situation that students have to deal with, and we can make the
JS more performant in a future iteration.
[PERF-261]
Before this commit, calling the student_view on a capa problem would
cause it to render an empty placeholder <div>, wait for the
DOMContentLoaded event to be fired, and then make AJAX requests to the
the problem_get handlers to retrieve the HTML it needed to render the
actual problems. This can significantly increase the end user load
times for pages, particularly when there are many problems in a
vertical.
This commit takes a very conservative approach and has the server side
add the rendered HTML into a new data-content attribute on the <div>
enclosing the problem. When Capa's JS initialization runs, it grabs
from that data-content attribute rather than reaching over the network
for an AJAX request.
I had attempted to make it somewhat smarter and push the rendered
problem straight into the document instead of relying on the
data-content attribute. This was faster, and should be our long term
goal. However, it caused odd bugs, particularly around MathJAX
rendering, and I never quite tracked the issue down. I'm still going
forward with these changes because it's significantly better than the
current situation that students have to deal with, and we can make the
JS more performant in a future iteration.
[PERF-261]
