The diffDOM Javascript sometimes throws an error if it can’t calculate
a diff between the original content of the page and the updated HTML
delivered via AJAX. The problem seems to be when there’s not one,
consistent top-level element for it to base its calculations on.
This commit:
- makes sure that all AJAX-delivered partials have a wrapping `<div>`
- that this `<div>` has a consistent class name to make it clear why
it’s there
Previously, the AJAX update for the dashboard was returning a big blob
of JSON with one key.
This commit splits it up to return:
- one key for each section of the page
- each containing a smaller chunk of HTML rendered from a partial
The jobs page was already working this way (pretty much) but just needed
a little tweaking to get it the same.
We can filter all notifications by status already. This commit reuses
the same code to filter the notifications for a job by status.
This means that, visually we can show the count on a job the same as
we do for all notifications, which is similar to how we show the counts
on the dashboard, so hopefully it feels like a bit more of a solid
thing.
This also applies to CSV downloads and AJAX updates, which will inherit
any filtering that their parent page has applied.
Currently, when we update a section of the page with AJAX we replace the
entire HTML of the section with the new HTML. This causes problems:
- if you’re trying to interact with that section of the page, eg by
inpecting it, clicking or hovering an element
- (probably) for screenreaders trying to navigate a page which is
changing more than is necessary
This commit replaces the call to `.html()` with a pretty clever library
called diffDOM[1]. DiffDOM works by taking a diff of the old element and
the new element, then doing a patch update, ie only modifying the parts
that have changed.
This is similar in concept to React’s virtual DOM, while still allowing
us to render all markup from one set of templates on the server-side.
1. https://github.com/fiduswriter/diffDOM
This is a first go at having the job page update without refreshing.
The approach I’ve taken is to do all the rendering of HTML on the server side,
rather than use a Javascipt templating engine like mustache. This ensures that
we don’t have to maintain two sets of templates.
So the approach is to split the job page into partials. These partials can then:
- be included in the job page to render the whole page
- be rendered indivudually and then returned as a blob of HTML inside a JSON
response
Then I’ve added a Javascript module which looks for areas of the page that should
be reloaded. For each area of the page it will poll a URL and re-render that
section of the page when it gets new HTML. It implements some throttling so that
API calls will never happen more frequently than 0.67 times/second.
