UNPKG

rtree-sql.js

Version:

SQLite library with support for opening and writing databases, prepared statements, and more. This SQLite library is in pure javascript (compiled with emscripten).

72 lines (59 loc) 3.99 kB
// We are modularizing this manually because the current modularize setting in Emscripten has some issues: // https://github.com/kripken/emscripten/issues/5820 // In addition, When you use emcc's modularization, it still expects to export a global object called `Module`, // which is able to be used/called before the WASM is loaded. // The modularization below exports a promise that loads and resolves to the actual sql.js module. // That way, this module can't be used before the WASM is finished loading. // We are going to define a function that a user will call to start loading initializing our Sql.js library // However, that function might be called multiple times, and on subsequent calls, we don't actually want it to instantiate a new instance of the Module // Instead, we want to return the previously loaded module // TODO: Make this not declare a global if used in the browser var initSqlJsPromise = undefined; var initSqlJs = function (moduleConfig) { if (initSqlJsPromise){ return initSqlJsPromise; } // If we're here, we've never called this function before initSqlJsPromise = new Promise((resolveModule, reject) => { // We are modularizing this manually because the current modularize setting in Emscripten has some issues: // https://github.com/kripken/emscripten/issues/5820 // The way to affect the loading of emcc compiled modules is to create a variable called `Module` and add // properties to it, like `preRun`, `postRun`, etc // We are using that to get notified when the WASM has finished loading. // Only then will we return our promise // If they passed in a moduleConfig object, use that // Otherwise, initialize Module to the empty object var Module = typeof moduleConfig !== 'undefined' ? moduleConfig : {}; // EMCC only allows for a single onAbort function (not an array of functions) // So if the user defined their own onAbort function, we remember it and call it var originalOnAbortFunction = Module['onAbort']; Module['onAbort'] = function (errorThatCausedAbort) { reject(new Error(errorThatCausedAbort)); if (originalOnAbortFunction){ originalOnAbortFunction(errorThatCausedAbort); } }; Module['postRun'] = Module['postRun'] || []; Module['postRun'].push(function () { // When Emscripted calls postRun, this promise resolves with the built Module resolveModule(Module); }); // There is a section of code in the emcc-generated code below that looks like this: // (Note that this is lowercase `module`) // if (typeof module !== 'undefined') { // module['exports'] = Module; // } // When that runs, it's going to overwrite our own modularization export efforts in shell-post.js! // The only way to tell emcc not to emit it is to pass the MODULARIZE=1 or MODULARIZE_INSTANCE=1 flags, // but that carries with it additional unnecessary baggage/bugs we don't want either. // So, we have three options: // 1) We undefine `module` // 2) We remember what `module['exports']` was at the beginning of this function and we restore it later // 3) We write a script to remove those lines of code as part of the Make process. // // Since those are the only lines of code that care about module, we will undefine it. It's the most straightforward // of the options, and has the side effect of reducing emcc's efforts to modify the module if its output were to change in the future. // That's a nice side effect since we're handling the modularization efforts ourselves module = undefined; // The emcc-generated code and shell-post.js code goes below, // meaning that all of it runs inside of this promise. If anything throws an exception, our promise will abort