Last time we discussed the Fetch API in general, taking a look at how it differed from the XMLHttpRequest API, and some of its advantages. Today, we’re going to take a look at a little library that you can include in your projects today that offers you localStorage caching for the Fetch API.
Long ago, we briefly brushed upon the topic of what has made jQuery such a valuable part of the web developer’s toolset for such a long time – namely, a cleaner interface for interacting with the DOM, and the $.ajax abstraction over XMLHttpRequest.
These days, I would go a step farther and discuss how it has positively influenced browser APIs. jQuery offered a way to find elements using their css selectors, and this eventually gave us
document.querySelectorAll. More recently, browser developers have taken another page from jQuery’s playbook and introduced a new, Promise-based API for making asynchronous requests, and so much more – Fetch.
Why go Fetch? Let’s take a look.
This is the first of a series of tutorials on using Bootstrap radio buttons in the wild to filter real datasets in concert with other commonly-used UI components like DataTables and jQuery UI.
Part 1: Converting a classic input radio to the Bootstrap label
Filtering tables of data is the central task of many a business web-app. DataTables are searchable by default, but records often beg to be batch-filtered into several status modes like: current | archived | all.
Bootstrap Radio Buttons provide a nice, clean look, but many developers shy away from them due to unfamiliarity with their CSS label-based class manipulation and/or compatibility issues with other component libraries like jQuery UI.
Bootstrap checkbox and radio btn-groups work ‘out of the box’, but the simple activation of a default button decouples active button highlighting from the input tag checked state. In this case, the active label class must be handled manually, but the docs don’t explain how, so a stack-overflow of posts for dev-help ensues. (more…)
You’ve built the web application of the century, and the users have rightly flooded to it. Cat pictures for everyone!
But alas, while your users indulge in cat-induced bliss, the cold hard reality of server costs cannot help but harsh your mellow. What is to be done?
Maybe, you could get the users to… pay for access to your incredible web application in all its multivarious splendour?
Braintree is a payment processor (now a subsidiary of PayPal), which boasts of a “simple, robust way to accept payments”, and with features like a drop-in payment ui and libraries for various programming languages enabling fairly easy integration, is a solid choice for accepting payments via credit card or PayPal.
While Braintree’s developer documentation is blessedly detailed, it’s possessed of a potentially confusing bevy of options, and its various implementation examples are spread out amongst a number of pages and platforms. So today, rather than reiterate any particular section of the docs, we’re going to take a look at an end-to-end example of a specific, straightforward scenario – accepting and processing a one-time, immediately settled payment in a web application.
After long, grueling months (years? or does it only feel like years?), your web application nears completion. It is tightly coded, well documented, works across all modern browsers, and is well received by your beta testers. It’s nearly time to go live, and a smile of pure relief plays upon your lips… and freezes into a rictus grin when your client turns to you, and asks, “so, hey, can we speed up the dynamic cat pic loading? Especially when I close the browser and come back to it later. I think that’s really key to the whole application.”
Long, long ago we discussed our jQuery plugin that will allow you to cache responses of ajax queries in Local Storage, so long as they’re strings, or something that can be coerced to a string (objects as JSON, numbers). We also previously discussed adding an ajax transport to allow us to handle sending and receiving binary blobs and array buffers via jQuery ajax.
But what if we need to cache binary blobs or arraybuffers? Say, we need those cat pics on the double – we could convert them to and from base64, but not only is that slow, but we’re certain to run up against the 5MB limit of local storage in short order. No, what we need is some way to cache binary data in some sort of client-side database…