darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-06-20 05:02:30 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
ec724ce417cfb7e9febda8dbbfe420f2c015b280
notifications-admin/app/assets/javascripts/updateContent.js

55 lines
1.2 KiB
JavaScript
Raw Normal View History

Stop AJAX updates queuing requests The `updateContent` module updates a section of the page based on an AJAX request. The current implementation will poll every `x` seconds. If the server takes a long time to respond, this results in a the browser queuing up requests. If a particular endpoint is slow, this can result in one client making enough requests to slow down the whole server, to the point where it gets removed from the loadbalancer, eventually bringing the whole site down. This commit rewrites the module so that it queues up the render operations, not the requests. There is one queue per endpoint, so for `http://example.com/endpoint.json`: 1. Queue is empty ```javascript { 'http://example.com/endpoint.json': [] } ``` 2. Inital re-render is put on the queue… ```javascript { 'http://example.com/endpoint.json': [ function render(){…} ] } ``` …AJAX request fires ``` GET http://example.com/endpoint.json ``` 3. Every `x` seconds, another render operation is put on the queue ```javascript { 'http://example.com/endpoint.json': [ function render(){…}, function render(){…}, function render(){…} ] } ``` 4. AJAX request returns queue is flushed by executing each queued render function in sequence ```javascript render(response); render(response); render(response); ``` ```javascript { 'http://example.com/endpoint.json': [] } ``` 5. Repeat This means that, at most, the AJAX requests will never fire more than once every `x` seconds, where `x` defaults to `1.5`.
2016-06-11 12:02:47 +01:00
(function(Modules) {
Make job page poll for updates 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.
2016-03-02 17:36:20 +00:00
"use strict";
Stop AJAX updates queuing requests The `updateContent` module updates a section of the page based on an AJAX request. The current implementation will poll every `x` seconds. If the server takes a long time to respond, this results in a the browser queuing up requests. If a particular endpoint is slow, this can result in one client making enough requests to slow down the whole server, to the point where it gets removed from the loadbalancer, eventually bringing the whole site down. This commit rewrites the module so that it queues up the render operations, not the requests. There is one queue per endpoint, so for `http://example.com/endpoint.json`: 1. Queue is empty ```javascript { 'http://example.com/endpoint.json': [] } ``` 2. Inital re-render is put on the queue… ```javascript { 'http://example.com/endpoint.json': [ function render(){…} ] } ``` …AJAX request fires ``` GET http://example.com/endpoint.json ``` 3. Every `x` seconds, another render operation is put on the queue ```javascript { 'http://example.com/endpoint.json': [ function render(){…}, function render(){…}, function render(){…} ] } ``` 4. AJAX request returns queue is flushed by executing each queued render function in sequence ```javascript render(response); render(response); render(response); ``` ```javascript { 'http://example.com/endpoint.json': [] } ``` 5. Repeat This means that, at most, the AJAX requests will never fire more than once every `x` seconds, where `x` defaults to `1.5`.
2016-06-11 12:02:47 +01:00
var queues = {};
Patch update sections of the page on AJAX 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
2016-04-27 09:28:42 +01:00
var dd = new diffDOM();
Stop AJAX updater consuming ever-increasing memory The pages with AJAX on were feeling quite sluggish, and it felt like they were making the whole browser slow down. Looking at the performance stuff in Chrome, the number of DOM nodes was going up and up, which is weird because the number of things on the page wasn’t changing. This was causing the page to consume more and more memory in order to store all these nodes. This is kinda beyond my understanding, but I tried a few things and it looks like the browser was having a hard time garbage collecting the temporary bits of DOM used to update the page. By assinging these bits of DOM to variables before using them it seems that the browser has an easier time cleaning them up.
2016-08-03 08:06:22 +01:00
var timer;
var getRenderer = $component => response => function() {
var component = $component.get(0);
var updated = $(response[$component.data('key')]).get(0);
var diff = dd.diff(component, updated);
dd.apply(
component, diff
);
};
Make job page poll for updates 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.
2016-03-02 17:36:20 +00:00
Stop AJAX updates queuing requests The `updateContent` module updates a section of the page based on an AJAX request. The current implementation will poll every `x` seconds. If the server takes a long time to respond, this results in a the browser queuing up requests. If a particular endpoint is slow, this can result in one client making enough requests to slow down the whole server, to the point where it gets removed from the loadbalancer, eventually bringing the whole site down. This commit rewrites the module so that it queues up the render operations, not the requests. There is one queue per endpoint, so for `http://example.com/endpoint.json`: 1. Queue is empty ```javascript { 'http://example.com/endpoint.json': [] } ``` 2. Inital re-render is put on the queue… ```javascript { 'http://example.com/endpoint.json': [ function render(){…} ] } ``` …AJAX request fires ``` GET http://example.com/endpoint.json ``` 3. Every `x` seconds, another render operation is put on the queue ```javascript { 'http://example.com/endpoint.json': [ function render(){…}, function render(){…}, function render(){…} ] } ``` 4. AJAX request returns queue is flushed by executing each queued render function in sequence ```javascript render(response); render(response); render(response); ``` ```javascript { 'http://example.com/endpoint.json': [] } ``` 5. Repeat This means that, at most, the AJAX requests will never fire more than once every `x` seconds, where `x` defaults to `1.5`.
2016-06-11 12:02:47 +01:00
var getQueue = resource => (
queues[resource] = queues[resource] || []
);
var flushQueue = function(queue, response) {
while(queue.length) queue.shift()(response);
Make job page poll for updates 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.
2016-03-02 17:36:20 +00:00
};
Handle AJAX errors when updating content With the change in implementation in the previous commit, any error (eg server responds with `500`) would cause the page to not be updated again. This is better than the previous implementation, whereby the browser would re-request as fast as it could until it got a successful response. This commit handles errors by clearing the render queue if the server returns an error. So: - Any updates that would have been performed based on this request are dropped - Subsequent updates will be attempted as if it was the first load of the page, ie after a delay of `x` seconds
2016-06-12 08:40:56 +01:00
var clearQueue = queue => (queue.length = 0);
Stop AJAX updates queuing requests The `updateContent` module updates a section of the page based on an AJAX request. The current implementation will poll every `x` seconds. If the server takes a long time to respond, this results in a the browser queuing up requests. If a particular endpoint is slow, this can result in one client making enough requests to slow down the whole server, to the point where it gets removed from the loadbalancer, eventually bringing the whole site down. This commit rewrites the module so that it queues up the render operations, not the requests. There is one queue per endpoint, so for `http://example.com/endpoint.json`: 1. Queue is empty ```javascript { 'http://example.com/endpoint.json': [] } ``` 2. Inital re-render is put on the queue… ```javascript { 'http://example.com/endpoint.json': [ function render(){…} ] } ``` …AJAX request fires ``` GET http://example.com/endpoint.json ``` 3. Every `x` seconds, another render operation is put on the queue ```javascript { 'http://example.com/endpoint.json': [ function render(){…}, function render(){…}, function render(){…} ] } ``` 4. AJAX request returns queue is flushed by executing each queued render function in sequence ```javascript render(response); render(response); render(response); ``` ```javascript { 'http://example.com/endpoint.json': [] } ``` 5. Repeat This means that, at most, the AJAX requests will never fire more than once every `x` seconds, where `x` defaults to `1.5`.
2016-06-11 12:02:47 +01:00
var poll = function(renderer, resource, queue, interval) {
Make job page poll for updates 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.
2016-03-02 17:36:20 +00:00
Handle AJAX errors when updating content With the change in implementation in the previous commit, any error (eg server responds with `500`) would cause the page to not be updated again. This is better than the previous implementation, whereby the browser would re-request as fast as it could until it got a successful response. This commit handles errors by clearing the render queue if the server returns an error. So: - Any updates that would have been performed based on this request are dropped - Subsequent updates will be attempted as if it was the first load of the page, ie after a delay of `x` seconds
2016-06-12 08:40:56 +01:00
if (queue.push(renderer) === 1) $.ajax(
resource
).done(
Stop AJAX updates queuing requests The `updateContent` module updates a section of the page based on an AJAX request. The current implementation will poll every `x` seconds. If the server takes a long time to respond, this results in a the browser queuing up requests. If a particular endpoint is slow, this can result in one client making enough requests to slow down the whole server, to the point where it gets removed from the loadbalancer, eventually bringing the whole site down. This commit rewrites the module so that it queues up the render operations, not the requests. There is one queue per endpoint, so for `http://example.com/endpoint.json`: 1. Queue is empty ```javascript { 'http://example.com/endpoint.json': [] } ``` 2. Inital re-render is put on the queue… ```javascript { 'http://example.com/endpoint.json': [ function render(){…} ] } ``` …AJAX request fires ``` GET http://example.com/endpoint.json ``` 3. Every `x` seconds, another render operation is put on the queue ```javascript { 'http://example.com/endpoint.json': [ function render(){…}, function render(){…}, function render(){…} ] } ``` 4. AJAX request returns queue is flushed by executing each queued render function in sequence ```javascript render(response); render(response); render(response); ``` ```javascript { 'http://example.com/endpoint.json': [] } ``` 5. Repeat This means that, at most, the AJAX requests will never fire more than once every `x` seconds, where `x` defaults to `1.5`.
2016-06-11 12:02:47 +01:00
response => flushQueue(queue, response)
Handle AJAX errors when updating content With the change in implementation in the previous commit, any error (eg server responds with `500`) would cause the page to not be updated again. This is better than the previous implementation, whereby the browser would re-request as fast as it could until it got a successful response. This commit handles errors by clearing the render queue if the server returns an error. So: - Any updates that would have been performed based on this request are dropped - Subsequent updates will be attempted as if it was the first load of the page, ie after a delay of `x` seconds
2016-06-12 08:40:56 +01:00
).fail(
() => clearQueue(queue)
Stop AJAX updates queuing requests The `updateContent` module updates a section of the page based on an AJAX request. The current implementation will poll every `x` seconds. If the server takes a long time to respond, this results in a the browser queuing up requests. If a particular endpoint is slow, this can result in one client making enough requests to slow down the whole server, to the point where it gets removed from the loadbalancer, eventually bringing the whole site down. This commit rewrites the module so that it queues up the render operations, not the requests. There is one queue per endpoint, so for `http://example.com/endpoint.json`: 1. Queue is empty ```javascript { 'http://example.com/endpoint.json': [] } ``` 2. Inital re-render is put on the queue… ```javascript { 'http://example.com/endpoint.json': [ function render(){…} ] } ``` …AJAX request fires ``` GET http://example.com/endpoint.json ``` 3. Every `x` seconds, another render operation is put on the queue ```javascript { 'http://example.com/endpoint.json': [ function render(){…}, function render(){…}, function render(){…} ] } ``` 4. AJAX request returns queue is flushed by executing each queued render function in sequence ```javascript render(response); render(response); render(response); ``` ```javascript { 'http://example.com/endpoint.json': [] } ``` 5. Repeat This means that, at most, the AJAX requests will never fire more than once every `x` seconds, where `x` defaults to `1.5`.
2016-06-11 12:02:47 +01:00
);
Stop AJAX updater consuming ever-increasing memory The pages with AJAX on were feeling quite sluggish, and it felt like they were making the whole browser slow down. Looking at the performance stuff in Chrome, the number of DOM nodes was going up and up, which is weird because the number of things on the page wasn’t changing. This was causing the page to consume more and more memory in order to store all these nodes. This is kinda beyond my understanding, but I tried a few things and it looks like the browser was having a hard time garbage collecting the temporary bits of DOM used to update the page. By assinging these bits of DOM to variables before using them it seems that the browser has an easier time cleaning them up.
2016-08-03 08:06:22 +01:00
timer = setTimeout(
Stop AJAX updates queuing requests The `updateContent` module updates a section of the page based on an AJAX request. The current implementation will poll every `x` seconds. If the server takes a long time to respond, this results in a the browser queuing up requests. If a particular endpoint is slow, this can result in one client making enough requests to slow down the whole server, to the point where it gets removed from the loadbalancer, eventually bringing the whole site down. This commit rewrites the module so that it queues up the render operations, not the requests. There is one queue per endpoint, so for `http://example.com/endpoint.json`: 1. Queue is empty ```javascript { 'http://example.com/endpoint.json': [] } ``` 2. Inital re-render is put on the queue… ```javascript { 'http://example.com/endpoint.json': [ function render(){…} ] } ``` …AJAX request fires ``` GET http://example.com/endpoint.json ``` 3. Every `x` seconds, another render operation is put on the queue ```javascript { 'http://example.com/endpoint.json': [ function render(){…}, function render(){…}, function render(){…} ] } ``` 4. AJAX request returns queue is flushed by executing each queued render function in sequence ```javascript render(response); render(response); render(response); ``` ```javascript { 'http://example.com/endpoint.json': [] } ``` 5. Repeat This means that, at most, the AJAX requests will never fire more than once every `x` seconds, where `x` defaults to `1.5`.
2016-06-11 12:02:47 +01:00
() => poll(...arguments), interval
);
Make job page poll for updates 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.
2016-03-02 17:36:20 +00:00
Stop AJAX updates queuing requests The `updateContent` module updates a section of the page based on an AJAX request. The current implementation will poll every `x` seconds. If the server takes a long time to respond, this results in a the browser queuing up requests. If a particular endpoint is slow, this can result in one client making enough requests to slow down the whole server, to the point where it gets removed from the loadbalancer, eventually bringing the whole site down. This commit rewrites the module so that it queues up the render operations, not the requests. There is one queue per endpoint, so for `http://example.com/endpoint.json`: 1. Queue is empty ```javascript { 'http://example.com/endpoint.json': [] } ``` 2. Inital re-render is put on the queue… ```javascript { 'http://example.com/endpoint.json': [ function render(){…} ] } ``` …AJAX request fires ``` GET http://example.com/endpoint.json ``` 3. Every `x` seconds, another render operation is put on the queue ```javascript { 'http://example.com/endpoint.json': [ function render(){…}, function render(){…}, function render(){…} ] } ``` 4. AJAX request returns queue is flushed by executing each queued render function in sequence ```javascript render(response); render(response); render(response); ``` ```javascript { 'http://example.com/endpoint.json': [] } ``` 5. Repeat This means that, at most, the AJAX requests will never fire more than once every `x` seconds, where `x` defaults to `1.5`.
2016-06-11 12:02:47 +01:00
};
Make job page poll for updates 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.
2016-03-02 17:36:20 +00:00
Stop AJAX updates queuing requests The `updateContent` module updates a section of the page based on an AJAX request. The current implementation will poll every `x` seconds. If the server takes a long time to respond, this results in a the browser queuing up requests. If a particular endpoint is slow, this can result in one client making enough requests to slow down the whole server, to the point where it gets removed from the loadbalancer, eventually bringing the whole site down. This commit rewrites the module so that it queues up the render operations, not the requests. There is one queue per endpoint, so for `http://example.com/endpoint.json`: 1. Queue is empty ```javascript { 'http://example.com/endpoint.json': [] } ``` 2. Inital re-render is put on the queue… ```javascript { 'http://example.com/endpoint.json': [ function render(){…} ] } ``` …AJAX request fires ``` GET http://example.com/endpoint.json ``` 3. Every `x` seconds, another render operation is put on the queue ```javascript { 'http://example.com/endpoint.json': [ function render(){…}, function render(){…}, function render(){…} ] } ``` 4. AJAX request returns queue is flushed by executing each queued render function in sequence ```javascript render(response); render(response); render(response); ``` ```javascript { 'http://example.com/endpoint.json': [] } ``` 5. Repeat This means that, at most, the AJAX requests will never fire more than once every `x` seconds, where `x` defaults to `1.5`.
2016-06-11 12:02:47 +01:00
Modules.UpdateContent = function() {
Make job page poll for updates 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.
2016-03-02 17:36:20 +00:00
Stop AJAX updates queuing requests The `updateContent` module updates a section of the page based on an AJAX request. The current implementation will poll every `x` seconds. If the server takes a long time to respond, this results in a the browser queuing up requests. If a particular endpoint is slow, this can result in one client making enough requests to slow down the whole server, to the point where it gets removed from the loadbalancer, eventually bringing the whole site down. This commit rewrites the module so that it queues up the render operations, not the requests. There is one queue per endpoint, so for `http://example.com/endpoint.json`: 1. Queue is empty ```javascript { 'http://example.com/endpoint.json': [] } ``` 2. Inital re-render is put on the queue… ```javascript { 'http://example.com/endpoint.json': [ function render(){…} ] } ``` …AJAX request fires ``` GET http://example.com/endpoint.json ``` 3. Every `x` seconds, another render operation is put on the queue ```javascript { 'http://example.com/endpoint.json': [ function render(){…}, function render(){…}, function render(){…} ] } ``` 4. AJAX request returns queue is flushed by executing each queued render function in sequence ```javascript render(response); render(response); render(response); ``` ```javascript { 'http://example.com/endpoint.json': [] } ``` 5. Repeat This means that, at most, the AJAX requests will never fire more than once every `x` seconds, where `x` defaults to `1.5`.
2016-06-11 12:02:47 +01:00
this.start = component => poll(
getRenderer($(component)),
$(component).data('resource'),
getQueue($(component).data('resource')),
($(component).data('interval-seconds') || 1.5) * 1000
);
Make job page poll for updates 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.
2016-03-02 17:36:20 +00:00
};
Stop AJAX updates queuing requests The `updateContent` module updates a section of the page based on an AJAX request. The current implementation will poll every `x` seconds. If the server takes a long time to respond, this results in a the browser queuing up requests. If a particular endpoint is slow, this can result in one client making enough requests to slow down the whole server, to the point where it gets removed from the loadbalancer, eventually bringing the whole site down. This commit rewrites the module so that it queues up the render operations, not the requests. There is one queue per endpoint, so for `http://example.com/endpoint.json`: 1. Queue is empty ```javascript { 'http://example.com/endpoint.json': [] } ``` 2. Inital re-render is put on the queue… ```javascript { 'http://example.com/endpoint.json': [ function render(){…} ] } ``` …AJAX request fires ``` GET http://example.com/endpoint.json ``` 3. Every `x` seconds, another render operation is put on the queue ```javascript { 'http://example.com/endpoint.json': [ function render(){…}, function render(){…}, function render(){…} ] } ``` 4. AJAX request returns queue is flushed by executing each queued render function in sequence ```javascript render(response); render(response); render(response); ``` ```javascript { 'http://example.com/endpoint.json': [] } ``` 5. Repeat This means that, at most, the AJAX requests will never fire more than once every `x` seconds, where `x` defaults to `1.5`.
2016-06-11 12:02:47 +01:00
})(window.GOVUK.Modules);
Reference in New Issue Copy Permalink