Compatibility with NativeScript 6

[edselg]

Using the JSDO with NativeScript 6 fails with an error like the following:

CONSOLE LOG file:///app/tns_modules/@angular/core/bundles/core.umd.js:25776:18: Angular is running in the development mode. Call enableProdMode() to enable the production mode.
LOG from device E’s iPad: CONSOLE ERROR file:///app/tns_modules/@angular/core/bundles/core.umd.js:4160:24: ERROR Error: Uncaught (in promise): TypeError: null is not an object (evaluating 'object.result')
sessionRejectHandler(file:///app/vendor.js:13477:39)
at getSession(file:///app/vendor.js:13645:33)
at createSession(file:///app/0.819c957f9e93e0b2b6d0.hot-update.js:32:85)
at HomeComponent(file:///app/0.819c957f9e93e0b2b6d0.hot-update.js:21:27)

Steps to reproduce

1. Create project using the following command:
   tns create testapp --template tns-template-master-detail-progress-ng
2. Run the project using Preview:
   tns preview

Related links:

• https://github.com/progress/JSDO/wiki/Using-the-JSDO-and-DataSource-with-an-existing-NativeScript-app

Research shows that this issue is caused by deprecation of the nativescript-localstorage plugin which is a dependency.
A solution for this issue is use the LocalStorageEmulation implemented a while back to work Node.js. Once the localStorage and sessionStorage references in progress-util.js point to the LocalStorageEmulation component, the project runs successfully.

[mikefechner]

@edselg hope you're doing fine! Is there any estimate when this issue will be solved?

[steinerj]

For a sample implementation of the in-memory-emulation check out: https://github.com/steinerj/jsdo-kinvey-flex

This is a project targeting nodejs. It's using the core JSDO and globally overwrites "sessionStorage" with the in-memory emulation. This might not work in TypeScript projects w/o overriding some TS settings. It might also not be the most sound approach in general :)
An alternative to this is forking the jsdo core and place the emulation directly in there.

Nice effect: no file or sqlite I/O is performed and it's thus marginally faster than the original implementation :)

NB: I believe for NativeScript the XHR emulation used in the project is not necessary, since NativeScript provides it's own XHR emulation.

[mikefechner]

Thanks, @steinerj

[edselg]

@mikefechner

I am well. I hope you are doing well too.

We currently do not have an estimate on when a fix for this issue would be publicly available.

How is this issue impacting you?

If you are interested, I can provide the fix via a Git branch.

Please let me know.

Thanks.

[mikefechner]

All is well on this end too!

We are currently implementing a fix in our JSDO fork. So looking at your fix might be great to confirm what we are doing.

Cheers,

Mike