This article demonstrates using the Javascript Intersection Observer API, instead of measuring scroll position, to perform common visibility detection tasks.
The Problem
In Javascript, performing an action when an element becomes visible to a user has previously always required the following:
Detecting the current scroll position. Setting an event listener to do this is easy enough, but the performance overhead can be costly. You will almost always want to write a throttling function to limit the amount of events fired when a user is scrolling. If you don’t know how to write this yourself, then you might reach for a library like Lodash, etc. which adds another dependency to your codebase.
Getting the top offset. Select the element you want to observe in the DOM and get its top offset relative to the element (or viewport) you are detecting. This may seem straightforward until you factor in any lazy loaded or async loaded content. Once you finally have that number, don’t forget to recalculate it because that pesky banner image loaded in at the last second and skewed your original number.
Unset and cleanup. Once you run your logic, you need to remember to remove the event listener. Sometimes you may have several.
Beware of main thread work. The function you pass to the event listener will be running on the main thread, and will be running hundreds or possibly thousands of times until your condition is met, even with the throttling you hopefully put in place.
Other use cases. Last but not least, there are scenarios where you may want to detect when an element is about to become visible, or after a user has scrolled past an element by a certain threshold. This would require more changes to the logic above.
The Solution
The Intersection Observer API is an excellent solution to this problem. It’s a fairly recent browser API that lets developers hand most of these tasks off to the browser, in a way that is more optimized.
A simple and elegant solution to displaying hierarchical tree structures (i.e. a Tree View) while leveraging the best that Twitter Bootstrap has to offer.
Tables that can be used for aligning/recording data properly but sometimes it happens that the data in the table is too long so in order to read the data properly the header respective to various columns should be available all the time while traversing the table. In such cases, a sticky table head is required to make the table more informative and accurate which can be implemented using CSS attributes.
Three ways (and one legacy way) to perform detailed customization of data being exported from DataTables to targets such as Excel, PDF, etc.
The first way gives you access to the contents of each DataTable cell being exported.
The second way gives you access to the relevant object for the export target.
The third way uses orthogonal data.
(The fourth way is included for legacy information only – but may still be useful in some situations.)
Format the Source Data Cells
This is useful for formatting the raw data of each cell in your datatable, or accessing additional HTML element and attribute data which may be in each cell’s node.
See the export data options. There are three sections which can be formatted – the data is:
format.header format.body format.footer
Example: Write contents of <input> fields in a DataTable to output Excel, to capture user-provided data:
The window object for the new window. As such the document body can be accessed using window.document.body and manipulated using jQuery and DOM methods.
See here for a full list of the different export targets.
Excel example to format the output with a thin black border on each cell:
PDF example to change the font (see full details here for how to build your own vfs_fonts.js file):
$(document).ready(function() {
$('#example').DataTable({
dom: 'Bfrtip',
buttons: [{
extend: 'pdf',
customize: function ( doc ) {
processDoc(doc);
}
}]
});
});
function processDoc(doc) {
//
// https://pdfmake.github.io/docs/fonts/custom-fonts-client-side/
//
// Update pdfmake's global font list, using the fonts available in
// the customized vfs_fonts.js file (do NOT remove the Roboto default):
pdfMake.fonts = {
Roboto: {
normal: 'Roboto-Regular.ttf',
bold: 'Roboto-Medium.ttf',
italics: 'Roboto-Italic.ttf',
bolditalics: 'Roboto-MediumItalic.ttf'
},
arial: {
normal: 'arial.ttf',
bold: 'arial.ttf',
italics: 'arial.ttf',
bolditalics: 'arial.ttf'
}
};
// modify the PDF to use a different default font:
doc.defaultStyle.font = "arial";
var i = 1;
}
Use Orthogonal Data
DataTables can use the orthogonal option when expoting data:
Another export data option, similar to the above example, but this one provides the data after all of it has been gathered and pre-processed by all other formatting options:
The customizeData option is a bit of a legacy hack. It was put in place before the Excel export buttons had a customize callback and it was the only way to modify the output data.
Data is provided in arrays:
header (array) body (2-dimensional array) footer (array)
No example given, as this is probably less useful compared to the other approaches shown above.
