Javascript Fetch API compatibility with Quick Base?

  • 0
  • 1
  • Question
  • Updated 12 months ago
  • In Progress
I'm attempting to use a code page to do some calculations... My main question is the Fetch API, as referenced here:

Is this Fetch command compatible in the version of JavaScript that Quick Base uses?
Photo of Ryan Stanford

Ryan Stanford

  • 1,992 Points 1k badge 2x thumb

Posted 12 months ago

  • 0
  • 1
Photo of Joshua Tate

Joshua Tate

  • 1,016 Points 1k badge 2x thumb
javascript is not a quickbase thing, its a web standard. check out Mozilla Developer Network and W3Schools to learn about web languages. now i will give you a fast class on fetch:

fetch requires at least a url in position 1 and option init (initialise instructions)


var url = "";
var init = { 
method: "POST",
credentials: "include",
headers: {
"Content-Type": "application/xml"
body: //put you body here


fetch(url, init).then(response => response.text()).then(str => (new DOMParser()).parseFromString(str, "text/xml")).then(function(xml) {
let rid = $("rid", xml).text()
Photo of Joshua Tate

Joshua Tate

  • 1,016 Points 1k badge 2x thumb
another piece of advice, learn about ECMA 2015, 2016, 2017 and 2018. There is no need to learn about framework languages like Angular, Vue, React etc all the cool stuff these offer are 95% available in native javascript in all modern browsers. if theirs something you cant do i am certain you can get a library for it to extend the functions available to you. Dont be afraid to insert your own scripts via service workers or other hacky means (aka Image On Load, Brand On Load as populerised on quick-base by Dan). Doing anything but native javascript may shoot you in the foot 6 months down the track, web standards ensure backward compatibility i.e so you can still look at your cat memes from 1993 today like you can in 2100 ;)
Photo of Ⲇanom the ultimate (Dan Diebolt)

Ⲇanom the ultimate (Dan Diebolt), Champion

  • 30,434 Points 20k badge 2x thumb
Fetch is a JavaScript API that replaces XMLHTTPRequest and it is fully supported in all modern browsers:

Can I Use Fetch

While Fetch is clearly the future there are some reasons you may not want to use it with QuickBase:

1) Fetch is a low level API and requies you send cookies (via credentials: "include") with each request.

2) With Fetch there is no corresponding $.ajaxSetup() method to include the application token with each request as there is with jQuery's AJAX methods

3) While Fetch returns a promise it is a native promise not a jQuery promise. Luckily you can convert a jQuery promise into a native promise using code similar to this:
var nativePromise = Promise.resolve(
4) Fetch does not support passing an object for the data (you have to pass a string, blob, formdata)

The reasons to use Fetch are compelling:

1) There is a bug in the version of jQuery QuickBase uses (ver 1.7.1) which breaks chaining.

2) Service Workers only support Fetch (no XMLHTTPRequest or jQuery)

3) Just about every web related API is asynchronous today and returns a native promise. Since Fetch returns a native promise it works seamlessly with native promises.

4) Fetch support FormData which makes it trivial to clone a QuickBase form and submit it using Fetch as FormData

Photo of Joshua Tate

Joshua Tate

  • 1,016 Points 1k badge 2x thumb
With what Dan says above, i literally stopped using every other means of API calling, I live a life of promise chaining these days. With service workers you can post messages between your main thread and back handle the traffic on your site via routes, giving you the cool ability to clone your response stream, read it, modify it and serve it back in place of what quick-base was going to give you. As Dan has said many times, service workers give you full control but until you start trying to use them you just wont know the power (full power, total control) it gives you. People get scared hearing the term service workers. Check out work-box by google, its a good starting point.