search

progress / JSDO

Client side TypeScript library to access Progress® Data Object Services
Other
23 stars 27 forks source link

Compatibility with NativeScript 6 #268

Open edselg opened 4 years ago

edselg commented 4 years ago

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)

image

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:

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 commented 4 years ago

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

steinerj commented 4 years ago

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 commented 4 years ago

Thanks, @steinerj

edselg commented 4 years ago

@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 commented 4 years ago

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