jwillinghalpern / fm-mock Goto Github PK

        // // https://webpack.js.org/configuration/output/#outputlibraryumdnameddefine
        // umdNamedDefine: true,

I haven't researched this but it has to do with how amd behaves.

EDIT 2022-09-06: my new tentative plan is to switch to vite and output just an es module js file and a UMD cjs file. (see fm-gofer for vite.config.js settings). I'd also like to switch to vitest and rewrite the tests to be less coupled to the implementation by only directly testing module exports and any modified globals. #10

Whatever the method is called... Perhaps it should not be run automatically in the FMMock constructor.

It's a pretty big side-effect, so maybe calling it explicitly is warranted

mockScript should be typed more like:

export declare function mockScript(scriptName: string, functionToCall: (param: string) => void): void;

This could be useful if you want to detect if the code is running in a webviewer or not and dynamically mock window.FileMaker if not.

When you call a script via FileMaker.PerformScript[WithOption], JS does not wait for the response by default. It's a void function.

So all mocked scripts should simulate this by wrapping any code in a setTimeout() with a very low timeoutInMs setting, perhaps like 5ms or even 0ms. The point isn't to simulate slow performance, but just to move the mock function response to the end of the event loop.

This would be a convenience function to combine with the fm-gofer library.

The usage should look something like this:

Example interface describing API:

Example usage:

// mock data example
// (use similar call signature to return a string or number,
//    they should all be stringified automatically to simulate
//    how FM passes only strings to JS functions)
mockGoferScript(
    'Fetch Data',
    {
        "name": "Josh",
        "animal": "Humanish",
    },
   { delay: 1500 } // simulate slow FM script
)

// custom callback example 
mockGoferScript(
    'Fetch Data',
    // if possible, these three params should be automatically destructured and passed to this fn (via currying?)
    (callbackName, promiseID, parameter) => {
        // do some custom logic, perhaps simulating intermittent record lock errors
        window[callbackName](promiseID, JSON.stringify({name: 'Josh', animal: 'Humanish'});
    },
    { delay: 123 }
)

It should be able to accept any of the following as the second param

1. a void fn with args callbackName, promiseID, and parameter
2. an object or array, which will be stringified and returned via callback automatically
3. a string, which will be returned verbatim automatically
4. a number whiwh will be stringified and returned automatically.

Currently, the tests call the underlying functions, but they should probably call window.FileMaker.PerformScript[WithOption] directly to better simulate real-world usage.

see if vite library mode works. and consider using vitest instead of jest.

https://vitejs.dev/guide/build.html#library-mode

I'm now craving the ability to throw errors within the resultFromFM function and have them automatically converted to fmgofer errors.

Example:

mockGoferScript(context.scriptName, {
	resultFromFM: (param) => {
		controller.returnError = false;
		if (param.route === "obj") {
			return import("./mocks/obj.json");
		} else if (param.route === "arr") {
			return import("./mocks/arr.json");
		} else {
			// this should behave as if filemaker specified true as the third param in the gofer callback (true for error)
			throw new Error(`Invalid route: ${param.route}`)
		}
	},
	logParams: true,
	delay: 100,
	returnError: false, // this will be ignored/overridden if an error is thrown in resultFromFM.
});

That way all you need is:

const { registerScript } = require('fm-mock');
registerScript('Script 1', ()=>{});
registerScript('Script 2', ()=>{});

SIDE NOTE: if we do this, then maybe change registerScript to just mockScript. Basically, the library will export only one function. I think maybe we keep it as a named export in case we want to export other stuff in the future.