#Import of abstract class used to extend sometimes not completing on time causing reference error?

6 messages · Page 1 of 1 (latest)

paper coyote
#

Hello! This has been driving me slightly insane since yesterday.

I have an abstract class that a lot of data classes implement. When one of these data classes is used, it sometimes throws a reference error as the import of the abstract class does not finish in time. I think this is caused by it being used for extensions, which is in the definition of the implemented class, so even if the imports are deferred and execution will not being until the page has finished parsing, the fact the abstract class is referenced and used when defining the implemented classes it seemingly will cause this issue with some regularity.

So far I've tried to put a pre-loader in the <head> of the page which I also made awaiting the import of this specific abstract class before importing other stuff. This has made the issue show up less often, but it still happens, more often on low performance systems, which is why I noticed it at all as I was working on my project on my cheap laptop over the weekend.

Is this an issue with JavaScript itself, that it doesn't handle abstract imports properly, does anyone recognize this?

zinc shellBOT
#
BOLL#0572
Playground Link

Preview:```ts
// In MyAbstractClass.ts
export default abstract class MyAbstractClass {
hello() {
console.log("Hi there!")
}
}

// In MyImplementedClass.ts
import MyAbstractClass from 'MyAbstractClass.js' // Transpiled file
class MyImplementedClass extends MyAbstractClass {
...```

You can choose specific lines to embed by selecting them before copying the link.
torn thorn
#

Is this an issue with JavaScript itself, that it doesn't handle abstract imports properly, does anyone recognize this?
js doesn't have abstract imports, js doesn't have abstract stuff

#

maybe check what your transpiled files say?

paper coyote
#

Good point, I'll check now... from what it looks like it has an import for the class it extends, my abstract TS class, which is then used to extend the class in the file a few lines down.

What I father from this is that it doesn't actually let the imports it has defined definitely run to completion before reading the file itself, I guess, so when using one of the imports to extend (which is in the transpiled code) it is not actually guaranteed to exist at that point.

I'm still theorizing that the JS engine reads the files and gets all class definitions, even if deferring all execution, which causes this issue.

Something I have done now is split code up to segregate dependencies a bit, so the issue has been lessened, but I still see some imports still failing to complete before the code on the page executes, which means the deferring is failing.

At least I read that imports are implicitly deferred, not sure if that is true when inside a module or if that is just for script tags... I shall read up on this some more.

paper coyote
#

Right, so I split some files with imports in them that were cross-referenced and probably causing some early execution... it'll have to do for now. I also realize I have caching turned off as much as possible as I am working on a project that gets frequent changes, and modules are difficult to refresh as they seem to ignore a forced refresh, at least that is what it seems like. In the future when the codebase is stable I might just flip on caching and that might alleviate most of these issues, maybe.