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

54 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 = {};
Revert "Update diff-dom package to 3.1.0" This reverts commit 01b97986f6b24c956d20e1b4b6db8445b75c157f.
2019-04-16 13:09:15 +01:00
var dd = new diffDOM();
Revert "Stop AJAX updater consuming ever-increasing memory"
2016-08-04 12:06:04 +01:00
var getRenderer = $component => response => dd.apply(
$component.get(0),
dd.diff($component.get(0), $(response[$component.data('key')]).get(0))
);
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);
Make AJAX requests on activity page POST not GET See parent commit for the reason we’re doing this. Currently our AJAX requests only work as `GET` requests. So this commit does a bit of work to make them work as `POST` requests. This is optional behaviour, and will only happen when the element in the page that should be updated with AJAX has the `data-form` attribute set. It will take the form that has the corresponding `id`, serialise it, and use that data as the body of the post request. If not form is specified it will not do the serialisation, and submit as a `GET` request as before.
2017-06-13 11:20:41 +01:00
var poll = function(renderer, resource, queue, interval, form) {
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
Page stops auto-refreshing when it's not active
2018-12-11 17:28:02 +00:00
if (document.visibilityState !== "hidden" && queue.push(renderer) === 1) $.ajax(
Make AJAX requests on activity page POST not GET See parent commit for the reason we’re doing this. Currently our AJAX requests only work as `GET` requests. So this commit does a bit of work to make them work as `POST` requests. This is optional behaviour, and will only happen when the element in the page that should be updated with AJAX has the `data-form` attribute set. It will take the form that has the corresponding `id`, serialise it, and use that data as the body of the post request. If not form is specified it will not do the serialisation, and submit as a `GET` request as before.
2017-06-13 11:20:41 +01:00
resource,
{
'method': form ? 'post' : 'get',
'data': form ? $('#' + form).serialize() : {}
}
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
).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(
Fix 500s when requesting json after logged out: * Update permissions decorator to make sure user is logged in first, else 401 * Stop further ajax json calls on failure
2016-10-21 14:24:21 +01:00
() => poll = function(){}
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
);
Revert "Stop AJAX updater consuming ever-increasing memory"
2016-08-04 12:06:04 +01:00
setTimeout(
Remove use of spread operator This is a temporary fix for the fact that the babel plugin for the spread operator calls a function called `_iterableToArray` which assumes the JavaScript runtime supports Symbols. IE11 doesn't support Symbols so this causes an error when it runs our JS. This swaps out use of the spread operator for a use of [apply](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/apply) to unpack the `arguments` object. Related issue on babel: https://github.com/babel/babel/issues/7597
2019-04-17 12:40:49 +01:00
() => poll.apply(window, arguments), interval
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')),
Make AJAX requests on activity page POST not GET See parent commit for the reason we’re doing this. Currently our AJAX requests only work as `GET` requests. So this commit does a bit of work to make them work as `POST` requests. This is optional behaviour, and will only happen when the element in the page that should be updated with AJAX has the `data-form` attribute set. It will take the form that has the corresponding `id`, serialise it, and use that data as the body of the post request. If not form is specified it will not do the serialisation, and submit as a `GET` request as before.
2017-06-13 11:20:41 +01:00
($(component).data('interval-seconds') || 1.5) * 1000,
$(component).data('form')
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
})(window.GOVUK.Modules);
Reference in New Issue Copy Permalink