Trying to use lit element/Polymer Web components AND an Audioworklet/AudioWorklet processor, I got this error:
boot-c9e09360.js:20 Uncaught ReferenceError: window is not defined
at boot-c9e09360.js:20:1
at this line in my code:
await aw.audioContext.audioWorklet.addModule("micSpkrAwp.js") //micSpkrAwp is the audio-worklet-processor running in different process.
The boot-c9e09360.js is a polymer file that contains:
/**
#license
Copyright (c) 2017 The Polymer Project Authors. All rights reserved.
...
*/
/* eslint-disable no-unused-vars /
/*
When using Closure Compiler, JSCompiler_renameProperty(property, object) is replaced by the munged name for object[property]
We cannot alias this function, so we have to use a small shim that has the same behavior when not compiling.
#param {?} prop Property name
#param {*} obj Reference object
#return {string} Potentially renamed property name
*/
window.JSCompiler_renameProperty = function(prop, obj) {
return prop;
};
I have been using lit element/Polymer web components and it works well. I removed the polymer components and the AudioWorkletProcessor works well.
I think that the problem is that Polymer assumes that window is defined (since polymer works with DOM), but when encountering a javascript file - the AudioWorkletProcessor which has no reference to DOM (just a file that provides the audio process interface) this error occurs.
Any suggestions?
Code of micSpkrAwp.js:
import { frameBufferQBRes } from "./queue.js"
import {config} from "./config.js"
class MicSpkrProcessor extends AudioWorkletProcessor {
constructor() {
super()
/** ..**/
process (inputs, outputs, parameters){
console.log(`micSpkrAws - this.stopImmediateFlag ${this.stopImmediateFlag}`)
if (this.stopImmediateFlag) return false
const retVal=this.processFromQueue(inputs,outputs,parameters)
return retVal
}
}
registerProcessor('mic-spkr-processor', MicSpkrProcessor)
Thanks to Kaiido for the solution!
Answer: Polymer scripts got injected into the AudioWorkletProcessor code due to importing :
import { calculateSplices } from '#polymer/polymer/lib/utils/array-splice';
This was not immediately visible since it was a nested import (imported file contained this import statement). This import was removed, and the problem solved!
Related
I am creating a dynamic component in Angular 9. I have a <ul> tag in the html template, the sub-elements of which are dynamically loaded from the server (The server will return values like <li>One</li><li>Two</li><li (click)="onLinkClicked(3)">Three</li> using handlebar templates).
private createComponentFromRaw(template: string, containerRef: ElementRef) {
class DynamicComponent {
onLinkClicked(resource: any) {
console.log(resource);
}
}
ɵcompileComponent(DynamicComponent, { template, changeDetection: ChangeDetectionStrategy.OnPush });
ɵrenderComponent(DynamicComponent, {
host: containerRef.nativeElement,
injector: this.injector,
hostFeatures: [ɵLifecycleHooksFeature],
});
}
On calling this.createComponentFromRaw('<li>One</li>', this.ref.element); the component is rendered as expected when run as ng serve but throws the following error at runtime in production mode (ng build --prod):
ERROR Error: Angular JIT compilation failed: '#angular/compiler' not loaded!
- JIT compilation is discouraged for production use-cases! Consider AOT mode instead.
- Did you bootstrap using '#angular/platform-browser-dynamic' or '#angular/platform-server'?
- Alternatively provide the compiler with 'import "#angular/compiler";' before bootstrapping.
Looks like the only option currently available is to set buildOptimizer: false in the angular.json
This happens because the buildOptimizer incorrectly considers #angular/compiler as having no side-effects and removes it as part of the tree shaking
Let's say I have a traditional javascript library such as google-charts and I wanted to incorporate that into my Polymer 3.0 project. How would I actually do the import?
This is how I would traditionally do it: https://developers.google.com/chart/interactive/docs/quick_start
ES Modules on NPM
Normally, one would prefer an ES module version of such a library if available (e.g., on NPM), since ES modules allow tree shaking (by Polymer CLI in this case) to reduce the size of the production build output.
Modules are loaded in JavaScript with the import keyword. If available on NPM, the library could be installed in your Polymer project with the npm-install command. For instance, you'd install google-charts like this:
npm install --save google-charts
Then, import that package in your element code:
import { GoogleCharts } from 'google-charts';
Example:
import { PolymerElement } from '#polymer/polymer';
import { GoogleCharts } from 'google-charts';
class MyElement extends PolymerElement {
// ...
ready() {
super.ready();
GoogleCharts.load(/* ... */);
}
}
demo
Non-ES Modules (not on NPM)
On the other hand if ESM is unavailable, the script is likely an AMD/UMD module, which adds symbols to the global scope. In that case, you'd still import the file, and access the global as you normally would had you used the <script> tag.
If the script is not on NPM, you'd have to copy the file locally into your project (and include the library file in your release), and then import the file by path. For example, if you copied the library to <root>/src/libs/google-charts.js, the element code at <root>/src/components/Chart.html would import it like this:
import '../libs/google-charts'
Example:
import { PolymerElement } from '#polymer/polymer';
import '../libs/google-charts' // adds GoogleCharts to global
class MyElement extends PolymerElement {
// ...
ready() {
super.ready();
GoogleCharts.load(/* ... */);
}
}
I'm trying to throw a custom error with my "CustomError" class name printed in the console instead of "Error", with no success:
class CustomError extends Error {
constructor(message: string) {
super(`Lorem "${message}" ipsum dolor.`);
this.name = 'CustomError';
}
}
throw new CustomError('foo');
The output is Uncaught Error: Lorem "foo" ipsum dolor.
What I expect: Uncaught CustomError: Lorem "foo" ipsum dolor.
I wonder if that can be done using TS only (without messing with JS prototypes)?
Are you using typescript version 2.1, and transpiling to ES5? Check this section of the breaking changes page for possible issues and workaround: https://github.com/Microsoft/TypeScript-wiki/blob/master/Breaking-Changes.md#extending-built-ins-like-error-array-and-map-may-no-longer-work
The relevant bit:
As a recommendation, you can manually adjust the prototype immediately after any super(...) calls.
class FooError extends Error {
constructor(m: string) {
super(m);
// Set the prototype explicitly.
Object.setPrototypeOf(this, FooError.prototype);
}
sayHello() {
return "hello " + this.message;
}
}
However, any subclass of FooError will have to manually set the prototype as well. For runtimes that don't support Object.setPrototypeOf, you may instead be able to use __proto__.
Unfortunately, these workarounds will not work on Internet Explorer 10 and prior. One can manually copy methods from the prototype onto the instance itself (i.e. FooError.prototype onto this), but the prototype chain itself cannot be fixed.
The problem is that Javascript's built-in class Error breaks the prototype chain by switching the object to be constructed (i.e. this) to a new, different object, when you call super and that new object doesn't have the expected prototype chain, i.e. it's an instance of Error not of CustomError.
This problem can be elegantly solved using 'new.target', which is supported since Typescript 2.2, see here: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-2.html
class CustomError extends Error {
constructor(message?: string) {
// 'Error' breaks prototype chain here
super(message);
// restore prototype chain
const actualProto = new.target.prototype;
if (Object.setPrototypeOf) { Object.setPrototypeOf(this, actualProto); }
else { this.__proto__ = actualProto; }
}
}
Using new.target has the advantage that you don't have to hardcode the prototype, like some other answers here proposed. That again has the advantage that classes inheriting from CustomError will automatically also get the correct prototype chain.
If you were to hardcode the prototype (e.g. Object.setPrototype(this, CustomError.prototype)), CustomError itself would have a working prototype chain, but any classes inheriting from CustomError would be broken, e.g. instances of a class VeryCustomError < CustomError would not be instanceof VeryCustomError as expected, but only instanceof CustomError.
See also: https://github.com/Microsoft/TypeScript/issues/13965#issuecomment-278570200
As of TypeScript 2.2 it can be done via new.target.prototype.
https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-2.html#example
class CustomError extends Error {
constructor(message?: string) {
super(message); // 'Error' breaks prototype chain here
this.name = 'CustomError';
Object.setPrototypeOf(this, new.target.prototype); // restore prototype chain
}
}
It works correctly in ES2015 (https://jsfiddle.net/x40n2gyr/). Most likely, the problem is that the TypeScript compiler is transpiling to ES5, and Error cannot be correctly subclassed using only ES5 features; it can only be correctly subclassed using ES2015 and above features (class or, more obscurely, Reflect.construct). This is because when you call Error as a function (rather than via new or, in ES2015, super or Reflect.construct), it ignores this and creates a new Error.
You'll probably have to live with the imperfect output until you can target ES2015 or higher...
I literally never post on SO, but my team is working on a TypeScript project, and we needed to create many custom error classes, while also targeting es5. It would have been incredibly tedious to do the suggested fix in every single error class. But we found that we were able to have a downstream effect on all subsequent error classes by creating a main custom error class, and having the rest of our errors extend that class. Inside of that main error class we did the following to have that downstream effect of updating the prototype:
class MainErrorClass extends Error {
constructor() {
super()
Object.setPrototypeOf(this, new.target.prototype)
}
}
class SomeNewError extends MainErrorClass {}
...
Using new.target.prototype was the key to getting all of the inheriting error classes to be updated without needing to update the constructor of each one.
Just hoping this saves someone else a headache in the future!
I ran into the same problem in my typescript project a few days ago. To make it work, I use the implementation from MDN using only vanilla js. So your error would look something like the following:
function CustomError(message) {
this.name = 'CustomError';
this.message = message || 'Default Message';
this.stack = (new Error()).stack;
}
CustomError.prototype = Object.create(Error.prototype);
CustomError.prototype.constructor = CustomError;
throw new CustomError('foo');
It doesn't seem to work in SO code snippet, but it does in the chrome console and in my typescript project:
I was having this problem in a nodejs server. what worked for me was to transpile down to es2017 in which these issues seems to be fixed.
Edit tsconfig to
"target": "es2017"
Try this...
class CustomError extends Error {
constructor(message: string) {
super(`Lorem "${message}" ipsum dolor.`)
}
get name() { return this.constructor.name }
}
throw new CustomError('foo')
There is no detalied explanation of what exactly es6 import and export do under the hood. Someone describe import as an read only view. Check the code below:
// lib/counter.js
export let counter = 1;
export function increment() {
counter++;
}
export function decrement() {
counter--;
}
// src/main.js
import * as counter from '../../counter';
console.log(counter.counter); // 1
counter.increment();
console..log(counter.counter); // 2
My question is if two modules import the same counter module and the first module increment the counter, will the second module also see the the counter as incremented? What under hood do the "import" and "export" do? Under what context is the increment function executing on? What is variable object of the increment function?
// lib/counter.js
export let counter = 1;
export function increment() {
counter++;
}
export function decrement() {
counter--;
}
// src/main1.js
import * as counter from '../../counter';
console.log(counter.counter); // 1
counter.increment();
console..log(counter.counter); // 2
// src/main2.js
import * as counter from '../../counter';
console.log(counter.counter); // what is the result of this, 1 or 2?
It seems to me that the "export" is creating a global object that can be accessed by different modules and it is setting the context of the exported function to that object. If this is the case, the design is wired for me, because modules is not aware of what other modules do. If two modules are importing the same module(counter), one module calls the increment function(example above) which cause the value(counter) changed, the other module does not know that.
See section 16.3.5 here
As mentioned:
The imports of an ES6 module are read-only views on the exported entities. That means that the connections to variables declared inside module bodies remain live, as demonstrated in the following code.
//------ lib.js ------
export let counter = 3;
export function incCounter() {
counter++;
}
//------ main.js ------
import { counter, incCounter } from './lib';
// The imported value `counter` is live
console.log(counter); // 3
incCounter();
console.log(counter); // 4
How that works under the hood is explained in a later section.
Imports as views have the following advantages:
They enable cyclic dependencies, even for unqualified imports.
Qualified and unqualified imports work the same way (they are both
indirections).
You can split code into multiple modules and it will
continue to work (as long as you don’t try to change the values of
imports).
The answer depends on what is your entry module. For example, if you define an entry module as:
// index.js
import "./main1";
import "./main2";
Then the output is:
1 // from main1
2 // from main1
2 // from main2
ES6 modules are allowed hold state, but are not allowed to manipulate others modules state directly. The module itself can expose a modifier function (like your increment method).
If you want to experiment a bit, rollupjs has a nice online demo that shows how the standard imports and exports should work.
I'm trying to include a Facebook app in a section of a Flash website developed in GAIA Framework. I've followed many examples and tutorials and I've tried to do a simple login on the Nav Page.
My imported classes (ALL of the facebook api?):
import com.adobe.serialization.json.JSON;
import com.facebook.graph.Facebook;
import com.facebook.graph.controls.*;
import com.facebook.graph.core.*;
import com.facebook.graph.data.*;
import com.facebook.graph.net.*;
import com.facebook.graph.utils.*;
My var with facebook id:
private var FB_app_id:String = 'my app id goes here :)';
My constructor:
public function NavPage()
{
super();
alpha = 0;
init();
Facebook.init(FB_app_id);
}
So, every time I try to publish, the following error appears:
C:\PROJECT ZERO\1 - Proyectos\2p -
WEB\src\com\facebook\graph\data\FQLMultiQuery.as, Line 80 1061: Call
to a possibly undefined method encode through a reference with static
type Class.
Line 80 of FQLMultiQuery.as refers to the following code:
public function toString():String {
return JSON.encode(queries);
}
What could be wrong? What am I doing wrong? I'm starting to think it might be an incompatibility issue between GAIA and the Facebook API.
It seems like you have a conflict with native JSON (since flash player 11) and the JSON from com.adobe.serialization.json package.
My solution for this is to rename the second one. Or start using the new JSON instead and exclude com.adobe.serialization.* from project.
reference:
http://www.pippoflash.com/index.php/2012/06/20/flash-player-10-and-flash-player-11-json-json-conflict-solved/