Files
notifications-admin/tests/javascripts/updateContent.test.js

519 lines
17 KiB
JavaScript
Raw Normal View History

Delay AJAX calls if the server is slow to respond By default our AJAX calls were 2 seconds. Then they were 5 seconds because someone reckoned 2 seconds was putting too much load on the system. Then we made them 10 seconds while we were having an incident. Then we made them 20 seconds for the heaviest pages, but back to 5 seconds or 2 seconds for the rest of the pages. This is not a good situation because: - it slows all services down equally, no matter how much traffic they have, or which features they have switched on - it slows everything down by the same amount, no matter how much load the platform is under - the values are set based on our worst performance, until we manually remember to switch them back - we spend time during incidents deploying changes to slow down the dashboard refresh time because it’s a nothing-to-lose change that might relieve some symptoms, when we could be spending time digging into the underlying cause This pull request makes the Javascript smarter about how long it waits until it makes another AJAX call. It bases the delay on how long the server takes to respond (as a proxy for how much load the server is under). It’s based on the square root of the response time, so is more sensitive to slow downs early on, and less sensitive to slow downs later on. This helps us give a more pronounced difference in delay between an AJAX call that is fast (for example the page for a single notification) and one that is slow (for example a dashboard for a service with lots of traffic). *Some examples of what this would mean for various pages* Page | Response time | Wait until next AJAX call ---|---|--- Check a reply to address | 130ms | 1,850ms Brand new service dashboard | 229ms | 2,783ms HM Passport Office dashboard | 634ms | 5,294ms NHS Coronavirus Service dashboard | 779ms | 5,977ms _Example of the kind of slowness we’ve seen during an incident_ | 6,000ms | 18,364ms GOV.UK email dashboard | `HTTP 504` | 😬
2020-04-08 17:55:53 +01:00
const each = require('jest-each').default;
const jestDateMock = require('jest-date-mock');
2019-09-02 14:27:46 +01:00
const helpers = require('./support/helpers.js');
const serviceNumber = '6658542f-0cad-491f-bec8-ab8457700ead';
const resourceURL = `/services/${serviceNumber}/notifications/email.json?status=sending%2Cdelivered%2Cfailed`;
const updateKey = 'counts';
let responseObj = {};
let jqueryAJAXReturnObj;
beforeAll(() => {
// ensure all timers go through Jest
jest.useFakeTimers();
// mock the bits of jQuery used
jest.spyOn(window.$, 'ajax');
// set up the object returned from $.ajax so it responds with whatever responseObj is set to
jqueryAJAXReturnObj = {
done: callback => {
Delay AJAX calls if the server is slow to respond By default our AJAX calls were 2 seconds. Then they were 5 seconds because someone reckoned 2 seconds was putting too much load on the system. Then we made them 10 seconds while we were having an incident. Then we made them 20 seconds for the heaviest pages, but back to 5 seconds or 2 seconds for the rest of the pages. This is not a good situation because: - it slows all services down equally, no matter how much traffic they have, or which features they have switched on - it slows everything down by the same amount, no matter how much load the platform is under - the values are set based on our worst performance, until we manually remember to switch them back - we spend time during incidents deploying changes to slow down the dashboard refresh time because it’s a nothing-to-lose change that might relieve some symptoms, when we could be spending time digging into the underlying cause This pull request makes the Javascript smarter about how long it waits until it makes another AJAX call. It bases the delay on how long the server takes to respond (as a proxy for how much load the server is under). It’s based on the square root of the response time, so is more sensitive to slow downs early on, and less sensitive to slow downs later on. This helps us give a more pronounced difference in delay between an AJAX call that is fast (for example the page for a single notification) and one that is slow (for example a dashboard for a service with lots of traffic). *Some examples of what this would mean for various pages* Page | Response time | Wait until next AJAX call ---|---|--- Check a reply to address | 130ms | 1,850ms Brand new service dashboard | 229ms | 2,783ms HM Passport Office dashboard | 634ms | 5,294ms NHS Coronavirus Service dashboard | 779ms | 5,977ms _Example of the kind of slowness we’ve seen during an incident_ | 6,000ms | 18,364ms GOV.UK email dashboard | `HTTP 504` | 😬
2020-04-08 17:55:53 +01:00
// The server takes 1 second to respond
jestDateMock.advanceBy(1000);
2019-09-02 14:27:46 +01:00
callback(responseObj);
return jqueryAJAXReturnObj;
},
fail: () => {}
};
$.ajax.mockImplementation(() => jqueryAJAXReturnObj);
// RollupJS assigns our bundled module code, including morphdom, to window.GOVUK.
// morphdom is assigned to its vendor property so we need to copy that here for the updateContent
// code to pick it up.
window.GOVUK.vendor = {
morphdom: require('morphdom')
};
2019-09-02 14:27:46 +01:00
require('../../app/assets/javascripts/updateContent.js');
});
afterAll(() => {
require('./support/teardown.js');
});
describe('Update content', () => {
Update updateContent tests to reflect its use The way we're using the updateContent.js code is slightly different to expected and to the scenarios in our tests. This changes the tests to match that use. The expected behaviour was for updates to a module's HTML to happen to the HTML inside of the div[data-module=update-content] element. So with initial HTML of: <div data-module="update-content" data-key="one"> <div class="ajax-block-container"> Existing content </div> </div> ...should be updated to be: <div data-module="update-content" data-key="one"> <div class="ajax-block-container"> New content </div> </div> Instead the HTML returned by the AJAX requests replaced the div[data-module=update-content] element. So with initial HTML of: <div data-module="update-content" ..> <div class="ajax-block-container"> Existing content </div> </div> ...will be updated to be: <div class="ajax-block-container"> New content </div> This doesn't seem to create any noticable changes to the visual interface so, I think, went unnoticed. The assumption I am making, of this being unintended, is based on the fact that the div[data-module=update-content] element has an aria-live attribute, which authors would normally want to stay in the page when updates happen. Note: This commit doesn't try and fix the problem, as the behaviour still largely works and the lack of aria-live actually seems to be a positive thing, meaning non-visual users aren't told of every update but can discover it themselves if needed.
2021-09-14 16:57:52 +01:00
let HTMLString;
let initialHTMLString;
describe('When updating the contents of DOM nodes', () => {
beforeEach(() => {
// store HTML in string to allow use in AJAX responses
HTMLString = `
<div class="bottom-gutter ajax-block-container">
<ul role="tablist" class="pill">
<li aria-selected="true" role="tab">
<div class="pill-selected-item" tabindex="0">
<div class="big-number-smaller">
<div class="big-number-number">0</div>
</div>
<div class="pill-label">total</div>
Update updateContent tests to reflect its use The way we're using the updateContent.js code is slightly different to expected and to the scenarios in our tests. This changes the tests to match that use. The expected behaviour was for updates to a module's HTML to happen to the HTML inside of the div[data-module=update-content] element. So with initial HTML of: <div data-module="update-content" data-key="one"> <div class="ajax-block-container"> Existing content </div> </div> ...should be updated to be: <div data-module="update-content" data-key="one"> <div class="ajax-block-container"> New content </div> </div> Instead the HTML returned by the AJAX requests replaced the div[data-module=update-content] element. So with initial HTML of: <div data-module="update-content" ..> <div class="ajax-block-container"> Existing content </div> </div> ...will be updated to be: <div class="ajax-block-container"> New content </div> This doesn't seem to create any noticable changes to the visual interface so, I think, went unnoticed. The assumption I am making, of this being unintended, is based on the fact that the div[data-module=update-content] element has an aria-live attribute, which authors would normally want to stay in the page when updates happen. Note: This commit doesn't try and fix the problem, as the behaviour still largely works and the lack of aria-live actually seems to be a positive thing, meaning non-visual users aren't told of every update but can discover it themselves if needed.
2021-09-14 16:57:52 +01:00
</div>
</li>
<li aria-selected="false" role="tab">
<a class="govuk-link govuk-link--no-visited-state" href="/services/6658542f-0cad-491f-bec8-ab8457700ead/notifications/email?status=sending">
<div class="big-number-smaller">
<div class="big-number-number">0</div>
</div>
<div class="pill-label">sending</div>
</a>
</li>
<li aria-selected="false" role="tab">
<a class="govuk-link govuk-link--no-visited-state" href="/services/6658542f-0cad-491f-bec8-ab8457700ead/notifications/email?status=delivered">
<div class="big-number-smaller">
<div class="big-number-number">0</div>
</div>
<div class="pill-label">delivered</div>
</a>
</li>
<li aria-selected="false" role="tab">
<a class="govuk-link govuk-link--no-visited-state" href="/services/6658542f-0cad-491f-bec8-ab8457700ead/notifications/email?status=failed">
<div class="big-number-smaller">
<div class="big-number-number">0</div>
</div>
<div class="pill-label">failed</div>
</a>
</li>
</ul>
</div>`;
initialHTMLString = `<div data-module="update-content" data-resource="${resourceURL}" data-key="${updateKey}">
${HTMLString}
</div>`;
document.body.innerHTML = initialHTMLString;
// default the response to match the content inside div[data-module]
responseObj[updateKey] = HTMLString;
2019-09-02 14:27:46 +01:00
});
2019-09-02 14:27:46 +01:00
test("It should replace the original HTML with that of the partial, to match that returned from AJAX responses", () => {
// start the module
window.GOVUK.modules.start();
expect(document.querySelector('.ajax-block-container').parentNode.hasAttribute('data-resource')).toBe(false);
});
test("It should make requests to the URL specified in the data-resource attribute", () => {
Update updateContent tests to reflect its use The way we're using the updateContent.js code is slightly different to expected and to the scenarios in our tests. This changes the tests to match that use. The expected behaviour was for updates to a module's HTML to happen to the HTML inside of the div[data-module=update-content] element. So with initial HTML of: <div data-module="update-content" data-key="one"> <div class="ajax-block-container"> Existing content </div> </div> ...should be updated to be: <div data-module="update-content" data-key="one"> <div class="ajax-block-container"> New content </div> </div> Instead the HTML returned by the AJAX requests replaced the div[data-module=update-content] element. So with initial HTML of: <div data-module="update-content" ..> <div class="ajax-block-container"> Existing content </div> </div> ...will be updated to be: <div class="ajax-block-container"> New content </div> This doesn't seem to create any noticable changes to the visual interface so, I think, went unnoticed. The assumption I am making, of this being unintended, is based on the fact that the div[data-module=update-content] element has an aria-live attribute, which authors would normally want to stay in the page when updates happen. Note: This commit doesn't try and fix the problem, as the behaviour still largely works and the lack of aria-live actually seems to be a positive thing, meaning non-visual users aren't told of every update but can discover it themselves if needed.
2021-09-14 16:57:52 +01:00
// start the module
window.GOVUK.modules.start();
jest.advanceTimersByTime(2000);
Update updateContent tests to reflect its use The way we're using the updateContent.js code is slightly different to expected and to the scenarios in our tests. This changes the tests to match that use. The expected behaviour was for updates to a module's HTML to happen to the HTML inside of the div[data-module=update-content] element. So with initial HTML of: <div data-module="update-content" data-key="one"> <div class="ajax-block-container"> Existing content </div> </div> ...should be updated to be: <div data-module="update-content" data-key="one"> <div class="ajax-block-container"> New content </div> </div> Instead the HTML returned by the AJAX requests replaced the div[data-module=update-content] element. So with initial HTML of: <div data-module="update-content" ..> <div class="ajax-block-container"> Existing content </div> </div> ...will be updated to be: <div class="ajax-block-container"> New content </div> This doesn't seem to create any noticable changes to the visual interface so, I think, went unnoticed. The assumption I am making, of this being unintended, is based on the fact that the div[data-module=update-content] element has an aria-live attribute, which authors would normally want to stay in the page when updates happen. Note: This commit doesn't try and fix the problem, as the behaviour still largely works and the lack of aria-live actually seems to be a positive thing, meaning non-visual users aren't told of every update but can discover it themselves if needed.
2021-09-14 16:57:52 +01:00
expect($.ajax.mock.calls[0][0]).toEqual(resourceURL);
2019-09-02 14:27:46 +01:00
});
2019-09-02 14:27:46 +01:00
test("If the response contains no changes, the DOM should stay the same", () => {
2019-09-02 14:27:46 +01:00
// send the done callback a response with updates included
responseObj[updateKey] = HTMLString;
2019-09-02 14:27:46 +01:00
// start the module
window.GOVUK.modules.start();
jest.advanceTimersByTime(2000);
2019-09-02 14:27:46 +01:00
// check a sample DOM node is unchanged
expect(document.querySelectorAll('.big-number-number')[0].textContent.trim()).toEqual("0");
2019-09-02 14:27:46 +01:00
});
Delay AJAX calls if the server is slow to respond By default our AJAX calls were 2 seconds. Then they were 5 seconds because someone reckoned 2 seconds was putting too much load on the system. Then we made them 10 seconds while we were having an incident. Then we made them 20 seconds for the heaviest pages, but back to 5 seconds or 2 seconds for the rest of the pages. This is not a good situation because: - it slows all services down equally, no matter how much traffic they have, or which features they have switched on - it slows everything down by the same amount, no matter how much load the platform is under - the values are set based on our worst performance, until we manually remember to switch them back - we spend time during incidents deploying changes to slow down the dashboard refresh time because it’s a nothing-to-lose change that might relieve some symptoms, when we could be spending time digging into the underlying cause This pull request makes the Javascript smarter about how long it waits until it makes another AJAX call. It bases the delay on how long the server takes to respond (as a proxy for how much load the server is under). It’s based on the square root of the response time, so is more sensitive to slow downs early on, and less sensitive to slow downs later on. This helps us give a more pronounced difference in delay between an AJAX call that is fast (for example the page for a single notification) and one that is slow (for example a dashboard for a service with lots of traffic). *Some examples of what this would mean for various pages* Page | Response time | Wait until next AJAX call ---|---|--- Check a reply to address | 130ms | 1,850ms Brand new service dashboard | 229ms | 2,783ms HM Passport Office dashboard | 634ms | 5,294ms NHS Coronavirus Service dashboard | 779ms | 5,977ms _Example of the kind of slowness we’ve seen during an incident_ | 6,000ms | 18,364ms GOV.UK email dashboard | `HTTP 504` | 😬
2020-04-08 17:55:53 +01:00
test("If the response contains changes, it should update the DOM with them", () => {
2019-09-02 14:27:46 +01:00
// send the done callback a response with updates included
responseObj[updateKey] = HTMLString.replace(/<div class="big-number-number">0<\/div>{1}/, '<div class="big-number-number">1</div>');
2019-09-02 14:27:46 +01:00
// start the module
window.GOVUK.modules.start();
jest.advanceTimersByTime(2000);
2019-09-02 14:27:46 +01:00
// check the right DOM node is updated
expect(document.querySelectorAll('.big-number-number')[0].textContent.trim()).toEqual("1");
2019-09-02 14:27:46 +01:00
});
2019-09-02 14:27:46 +01:00
describe("By default", () => {
2019-09-02 14:27:46 +01:00
beforeEach(() => {
2019-09-02 14:27:46 +01:00
// start the module
window.GOVUK.modules.start();
2019-09-02 14:27:46 +01:00
});
2019-09-02 14:27:46 +01:00
test("It should use the GET HTTP method", () => {
2019-09-02 14:27:46 +01:00
jest.advanceTimersByTime(2000);
expect($.ajax.mock.calls[0][1].method).toEqual('get');
2019-09-02 14:27:46 +01:00
});
2019-09-02 14:27:46 +01:00
test("It shouldn't send any data as part of the requests", () => {
2019-09-02 14:27:46 +01:00
jest.advanceTimersByTime(2000);
expect($.ajax.mock.calls[0][1].data).toEqual({});
2019-09-02 14:27:46 +01:00
});
2019-09-02 14:27:46 +01:00
test("It should request updates with a dynamic interval", () => {
2019-09-02 14:27:46 +01:00
// First call doesnt happen in the first 2000ms
jest.advanceTimersByTime(1999);
expect($.ajax).toHaveBeenCalledTimes(0);
2019-09-02 14:27:46 +01:00
// But it happens after 2000ms by default
jest.advanceTimersByTime(1);
expect($.ajax).toHaveBeenCalledTimes(1);
2019-09-02 14:27:46 +01:00
// It took the server 1000ms to respond to the first call so we
// will back off the next call shouldnt happen in the next 6904ms
jest.advanceTimersByTime(6904);
expect($.ajax).toHaveBeenCalledTimes(1);
2019-09-02 14:27:46 +01:00
// But it should happen after 6905ms
jest.advanceTimersByTime(1);
expect($.ajax).toHaveBeenCalledTimes(2);
});
each([
[1000, 0],
[1500, 100],
[4590, 500],
[6905, 1000],
[24000, 10000],
]).test('It calculates a delay of %dms if the API responds in %dms', (waitTime, responseTime) => {
expect(
window.GOVUK.Modules.UpdateContent.calculateBackoff(responseTime)
).toBe(
waitTime
);
});
2019-09-02 14:27:46 +01:00
});
describe("If a form is used as a source for data, referenced in the data-form attribute", () => {
2019-09-02 14:27:46 +01:00
beforeEach(() => {
2019-09-02 14:27:46 +01:00
document.body.innerHTML += `
<form method="post" id="service">
<input type="hidden" name="serviceName" value="Buckhurst surgery" />
<input type="hidden" name="serviceNumber" value="${serviceNumber}" />
</form>`;
2019-09-02 14:27:46 +01:00
document.querySelector('[data-module=update-content]').setAttribute('data-form', 'service');
2019-09-02 14:27:46 +01:00
// start the module
window.GOVUK.modules.start();
});
2019-09-02 14:27:46 +01:00
test("requests should use the same HTTP method as the form", () => {
2019-09-02 14:27:46 +01:00
jest.advanceTimersByTime(2000);
expect($.ajax.mock.calls[0][1].method).toEqual('post');
2019-09-02 14:27:46 +01:00
})
test("requests should use the data from the form", () => {
jest.advanceTimersByTime(2000);
expect($.ajax.mock.calls[0][1].data).toEqual(helpers.getFormDataFromPairs([
['serviceName', 'Buckhurst surgery'],
['serviceNumber', serviceNumber]
]));
})
2019-09-02 14:27:46 +01:00
Delay AJAX calls if the server is slow to respond By default our AJAX calls were 2 seconds. Then they were 5 seconds because someone reckoned 2 seconds was putting too much load on the system. Then we made them 10 seconds while we were having an incident. Then we made them 20 seconds for the heaviest pages, but back to 5 seconds or 2 seconds for the rest of the pages. This is not a good situation because: - it slows all services down equally, no matter how much traffic they have, or which features they have switched on - it slows everything down by the same amount, no matter how much load the platform is under - the values are set based on our worst performance, until we manually remember to switch them back - we spend time during incidents deploying changes to slow down the dashboard refresh time because it’s a nothing-to-lose change that might relieve some symptoms, when we could be spending time digging into the underlying cause This pull request makes the Javascript smarter about how long it waits until it makes another AJAX call. It bases the delay on how long the server takes to respond (as a proxy for how much load the server is under). It’s based on the square root of the response time, so is more sensitive to slow downs early on, and less sensitive to slow downs later on. This helps us give a more pronounced difference in delay between an AJAX call that is fast (for example the page for a single notification) and one that is slow (for example a dashboard for a service with lots of traffic). *Some examples of what this would mean for various pages* Page | Response time | Wait until next AJAX call ---|---|--- Check a reply to address | 130ms | 1,850ms Brand new service dashboard | 229ms | 2,783ms HM Passport Office dashboard | 634ms | 5,294ms NHS Coronavirus Service dashboard | 779ms | 5,977ms _Example of the kind of slowness we’ve seen during an incident_ | 6,000ms | 18,364ms GOV.UK email dashboard | `HTTP 504` | 😬
2020-04-08 17:55:53 +01:00
});
2019-09-02 14:27:46 +01:00
});
describe("When adding or removing DOM nodes", () => {
var getItemHTMLString = content => {
var areas = '';
content.areas.forEach(area =>
areas += "\n" + `<li class="area-list-item area-list-item--unremoveable area-list-item--smaller">${area}</li>`
);
return `
<div class="keyline-block">
<div class="file-list govuk-!-margin-bottom-2">
<h2>
<a class="file-list-filename-large govuk-link govuk-link--no-visited-state" href="/services/7597847f-ad8e-4600-8faf-c42a647d8dee/current-alerts/b9e53cda-54f9-47bc-9fb2-b78a11eda6a9">${content.title}</a>
</h2>
<div class="govuk-grid-row">
<div class="govuk-grid-column-one-half">
<span class="file-list-hint-large govuk-!-margin-bottom-2">
${content.hint}
</span>
</div>
<div class="govuk-grid-column-one-half file-list-status">
<p class="govuk-body govuk-!-margin-bottom-0 govuk-hint">
${content.status}
</p>
</div>
</div>
<ul class="area-list">
${areas}
</ul>
</div>
</div>`;
};
2019-09-02 14:27:46 +01:00
var getHTMLString = items => {
var itemsHTMLString = '';
items.forEach(item => itemsHTMLString += "\n" + getItemHTMLString(item));
return `<div class="ajax-block-container">
${itemsHTMLString};
<div class="keyline-block"></div>
</div>`;
};
2019-09-02 14:27:46 +01:00
test("If the response contains no changes, the DOM should stay the same", () => {
2019-09-02 14:27:46 +01:00
// store HTML in string to allow use in AJAX responses
HTMLString = getHTMLString([
{
title: "Gas leak",
hint: "There's a gas leak in the local area. Residents should vacate until further notice.",
status: "Waiting for approval",
areas: [
"Santa Claus Village, Rovaniemi B",
"Santa Claus Village, Rovaniemi C"
]
}
]);
initialHTMLString = `<div data-module="update-content" data-resource="${resourceURL}" data-key="${updateKey}">
${HTMLString}
</div>`;
document.body.innerHTML = initialHTMLString;
// make a response with no changes
responseObj[updateKey] = HTMLString;
2019-09-02 14:27:46 +01:00
// start the module
window.GOVUK.modules.start();
jest.advanceTimersByTime(2000);
// check it has the same number of items
expect(document.querySelectorAll('.file-list').length).toEqual(1);
expect(document.querySelectorAll('.file-list h2 a')[0].textContent.trim()).toEqual("Gas leak");
2019-09-02 14:27:46 +01:00
});
test("If the response adds a node, the DOM should contain that node", () => {
// store HTML in string to allow use in AJAX responses
HTMLString = getHTMLString([
{
title: "Gas leak",
hint: "There's a gas leak in the local area. Residents should vacate until further notice.",
status: "Waiting for approval",
areas: [
"Santa Claus Village, Rovaniemi B",
"Santa Claus Village, Rovaniemi C"
]
}
]);
initialHTMLString = `<div data-module="update-content" data-resource="${resourceURL}" data-key="${updateKey}">
${HTMLString}
</div>`;
document.body.innerHTML = initialHTMLString;
var updatedHTMLString = getHTMLString([
{
title: "Gas leak",
hint: "There's a gas leak in the local area. Residents should vacate until further notice.",
status: "Waiting for approval",
areas: [
"Santa Claus Village, Rovaniemi B",
"Santa Claus Village, Rovaniemi C"
]
},
{
title: "Reservoir flooding template",
hint: "The local reservoir has flooded. All people within 5 miles should move to a safer location.",
status: "Waiting for approval",
areas: [
"Santa Claus Village, Rovaniemi A",
"Santa Claus Village, Rovaniemi D"
]
}
]);
// make the response have an extra item
responseObj[updateKey] = updatedHTMLString;
2019-09-02 14:27:46 +01:00
// start the module
window.GOVUK.modules.start();
jest.advanceTimersByTime(2000);
2019-09-02 14:27:46 +01:00
// check the node has been added
expect(document.querySelectorAll('.file-list').length).toEqual(2);
expect(document.querySelectorAll('.file-list h2 a')[0].textContent.trim()).toEqual("Gas leak");
expect(document.querySelectorAll('.file-list h2 a')[1].textContent.trim()).toEqual("Reservoir flooding template");
});
2019-09-02 14:27:46 +01:00
test("If the response removes a node, the DOM should not contain that node", () => {
// store HTML in string to allow use in AJAX responses
HTMLString = getHTMLString([
{
title: "Gas leak",
hint: "There's a gas leak in the local area. Residents should vacate until further notice.",
status: "Waiting for approval",
areas: [
"Santa Claus Village, Rovaniemi B",
"Santa Claus Village, Rovaniemi C"
]
},
{
title: "Reservoir flooding template",
hint: "The local reservoir has flooded. All people within 5 miles should move to a safer location.",
status: "Waiting for approval",
areas: [
"Santa Claus Village, Rovaniemi A",
"Santa Claus Village, Rovaniemi D"
]
}
]);
initialHTMLString = `<div data-module="update-content" data-resource="${resourceURL}" data-key="${updateKey}">
${HTMLString}
</div>`;
document.body.innerHTML = initialHTMLString;
var updatedHTMLString = getHTMLString([
{
title: "Gas leak",
hint: "There's a gas leak in the local area. Residents should vacate until further notice.",
status: "Waiting for approval",
areas: [
"Santa Claus Village, Rovaniemi B",
"Santa Claus Village, Rovaniemi C"
]
}
]);
// default the response to match the content inside div[data-module]
responseObj[updateKey] = updatedHTMLString;
2019-09-02 14:27:46 +01:00
// start the module
window.GOVUK.modules.start();
jest.advanceTimersByTime(2000);
2019-09-02 14:27:46 +01:00
// check the node has been removed
expect(document.querySelectorAll('.file-list').length).toEqual(1);
expect(document.querySelectorAll('.file-list h2 a')[0].textContent.trim()).toEqual("Gas leak");
});
test("If other scripts have added classes to the DOM, they should persist through updates", () => {
// store HTML in string to allow use in AJAX responses
HTMLString = getHTMLString([
{
title: "Gas leak",
hint: "There's a gas leak in the local area. Residents should vacate until further notice.",
status: "Waiting for approval",
areas: [
"Santa Claus Village, Rovaniemi B",
"Santa Claus Village, Rovaniemi C"
]
}
]);
initialHTMLString = `<div data-module="update-content" data-resource="${resourceURL}" data-key="${updateKey}">
${HTMLString}
</div>`;
document.body.innerHTML = initialHTMLString;
// mark classes to persist on the partial
document.querySelector('.ajax-block-container').setAttribute('data-classes-to-persist', 'js-child-has-focus');
// Add class to indicate focus state of link on parent heading
document.querySelectorAll('.file-list h2')[0].classList.add('js-child-has-focus');
var updatedHTMLString = getHTMLString([
{
title: "Gas leak",
hint: "There's a gas leak in the local area. Residents should vacate until further notice.",
status: "Waiting for approval",
areas: [
"Santa Claus Village, Rovaniemi B",
"Santa Claus Village, Rovaniemi C"
]
},
{
title: "Reservoir flooding template",
hint: "The local reservoir has flooded. All people within 5 miles should move to a safer location.",
status: "Waiting for approval",
areas: [
"Santa Claus Village, Rovaniemi A",
"Santa Claus Village, Rovaniemi D"
]
}
]);
// make the response have an extra item
responseObj[updateKey] = updatedHTMLString;
// start the module
window.GOVUK.modules.start();
jest.advanceTimersByTime(2000);
// check the class is still there
expect(document.querySelectorAll('.file-list h2')[0].classList.contains('js-child-has-focus')).toBe(true);
});
});
afterEach(() => {
document.body.innerHTML = '';
// tidy up record of mocked AJAX calls
$.ajax.mockClear();
// ensure any timers set by continually starting the module are cleared
jest.clearAllTimers();
2019-09-02 14:27:46 +01:00
});
});