Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Check Whether in Window or Webworker #14

Open
danidre14 opened this issue Sep 23, 2021 · 2 comments
Open

Check Whether in Window or Webworker #14

danidre14 opened this issue Sep 23, 2021 · 2 comments

Comments

@danidre14
Copy link

This is a feature request.

Currently, when importing Neu as a script into webworkers, it uses the window.NL_PORT to make requests. window is underfined in webworkers, so all requests will silently fail. You'd have to fix that with by typing var window = self; in the worker right before importing the neu js file.

Suggestion:
A fix would be to determine if in a webworker first, and populate the worker NL_PORT, else the window port. Tat way, requests such as Neu.storage will work even in the worker.

@shalithasuranga shalithasuranga transferred this issue from neutralinojs/neutralinojs Oct 12, 2021
@shalithasuranga
Copy link
Member

Hey, @danidre14 Could you please let us know why you trying to use the client lib inside a web worker? The client lib is typically used as a normal browser script due to the following reasons:

  • Client library doesn't do anything heavy to migrate to a web worker.
  • Client lib uses DOM so often (native events, dev client, draggable region, etc), so those API will fail inside a web worker.

Perhaps, you have a special case - so, we can discuss ;)

@danidre14
Copy link
Author

Hi @shalithasuranga yes I have a special case.

TLDR: For autosave backup files that aren't affected by the single-threaded JS.

I am working on a game engine editor software for my own game engine; it is similar to Adobe Flash Professional or Wick Editor. It involves adding flevaclips (prefabs/textfields), graphics, audio, as well as applying scripts for the flevaclips. The main necessity is the "Test" function. It opens a new window with the "compiled/transpiled" JS code of the game.

However, with this, since the test file was opened on the same thread as the editor, any blocking code (an infinite while loop the user uses, which is only detected at test/run-time) will freeze and crash even the editor, so users may lose data.

Thus, I have implemented an autosave function that uses webworkers to autosave progress every 30 seconds. Therefore, even if the user runs an infinite while loop and crashes the editor, when the kill the application and reopen it, they have the option of retrieving the last autosaved file (since the web worker works on a different thread)

For saving, I have created my own storage API that either uses the localstorage or indexeddb driver behind the scenes.
When adapting the application to use Neutralino, I added the Neutralino storage APIs as an existing driver, so that the files are stored in the neu storage files instead. My custom storage API is also sent to the web worker (because in teh browser version indexeddb works in webworkers so I can still autosave). However, in the Neu application I was unable to use autosave without a hacked version of the Neu file which I outlined above.

That is why I proposed allowing the client lib inside a web worker...or at least, the storage part of it.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants