Efficiently find duplicate data property in object literal? - ecmascript-6

After creating our new system in Vue with babel, I have started testing compatibility towards older devices. Our babel is transpiling the source down to es2015 together with webpack.
I have now tested with browserstack against both Ios & android. Newer OS works on both platforms. However on android phones that use the default browser, I get an error in sentry stating; Duplicate data property in object literal not allowed in strict mode It does not give me any hints on where this might be thus making the debugging process painfully hard.
The only light in the end of the tunnel I can se now is the ios part. Ios devices that run IOS < 9 states an error Attempted to redefine property 'value'. also in sentry
If I am not mistaking, the ios issue is a reworded error of the same issue?
As I read over here, I suppose 'value' might be defined twice in a object or element.
This all wraps up to the question, how does one go with finding duplicate data properties?

Can you share some of your code (just the area from a few components?)
One thing to check is inside of data(), ensure you are returning an object. This happened to me when I started out with Vue.
Example:
// component a
data () {
a: ''
}
// component b
data () {
a: '' // ERROR! Duplicate
}
This happens because the data is merged on the main Vue instance. So in this case it should look like:
// component a
data () {
return {
a: ''
}
}
// component b
data () {
return {
a: '' // ok now
}
}
Hard to make any other guesses without some code.

I had the same issue reported on a old android device, here's what i did :
We had components with both mapActions(["something"]) and a defined method something() { this.$store.dispatch('something') }
So i removed the methods declaration.
It still didn't work so I check the build main.xxxx.js on eslint
and found some "Attempted to redefine property 'value'" on something like domProps:{value:t.value,value:t.value}
Looked up the code and saw that we had components with both v-model and :value and also some checkbox using v-model and :checked.
I only kept the v-model and it works.
It also seems like the problems could come from repeated props like stated here : https://www.tutorialfor.com/blog-267252.htm

I managed to find out what line the error occurred on and found out that a plugin that I used with name Vue-numeric had created a duplicate value:
domProps: {
value: n.value,
value: n.amount
},
I had accidentally locked the plugin on a older version where this problem was present. The issue was fixed by simply updating.
Thank you #xenetics for taking your time on this issue.

Yes, this is a restriction that was only in effect in ES5 strict mode, which these environments you have apparently use. It absolutely makes sense but was nonetheless loosened in ES6 because of computed properties - see What's the purpose of allowing duplicate property names? for details. That's why babel doesn't complain about it when transpiling.
To find these (valid but nonsensical) duplicate property names in object literals in your code base, you can use a linter such as ESLint with a rule against these.

Related

Blazor WebAssembly JsonException: A possible object cycle was detected which is not supported

I get this error because I have circular references defined in my object model. My question is, is there any way to resolve this using one of the following two options?
Using Newtonsoft.Json and options.SerializerSettings.ReferenceLoopHandling = ReferenceLoopHandling.Ignore;
Using System.Text.Json and options.JsonSerializerOptions.ReferenceHandler = System.Text.Json.Serialization.ReferenceHandler.Preserve;
I'm not seeing a way to switch to Newtonsoft.Json in a Blazor WebAssembly application and I tried implementing option 2 in the ConfigureServices function of Startup.cs in my Server project but I still kept getting the error.
I'm just trying to find a solution that doesn't require me redefining my object model. The JsonIgnore attribute does not appear to be an option either because I assume, and it appears, that then any fields I define it on do not exist in the Json on the client which breaks my application.
Update: I found this site which looks to me like discusses exactly what I'm referring to here and how to implement the solution but I have not got it to work yet. If anyone is successfully using Blazor WebAssembly with circular references in your object model please let me know what you're doing.
https://github.com/dotnet/aspnetcore/issues/28286
Thank you for pointing out this error in Blazor. I found the answer in the issue you mentioned (this comment). You need to change json options also on the Client side. This works for me:
On server
services.AddControllersWithViews().AddJsonOptions(options =>
{
options.JsonSerializerOptions.ReferenceHandler = System.Text.Json.Serialization.ReferenceHandler.Preserve;
options.JsonSerializerOptions.PropertyNamingPolicy = null;
});
On client
var response = await Http.GetFromJsonAsync<T>("{Address}", new JsonSerializerOptions
{
ReferenceHandler = System.Text.Json.Serialization.ReferenceHandler.Preserve,
PropertyNamingPolicy = null
});
To the two options you mentioned there is a third option available if you use .NET 6 or above.
Using System.Text.Json and options.JsonSerializerOptions.ReferenceHandler = ReferenceHandler.IgnoreCycles;
Beware that ignoring cycles have issues on its own (such as data corruption) but if you were depending on it when you were using Newtonsoft.Json then you will be fine as it is basically the same behavior.
If you prefer to go with ReferenceHandler.Preserve, please share more info on what error you are getting and I can try to help you out.
One way to go about this is specify how much depth an object is allowed to have. Please see the documentation here regarding how to do this with System.Text.Json. I think this may help.

Debugging experimental WebAssembly externref bug in Google Chrome

Warning: as the reference types proposal isn't complete yet, this code will not run without toggling flags or setting in order to enable executing experimental code.
If you are on Google Chrome or a Chromium browser, you will need to enable the following flag:
chrome://flags/#enable-experimental-webassembly-features
I had set up a simple handwritten Wasm module for personal use. I could've easily written it in JavaScript, but it was easier and made more sense to use Wasm, and since it was a simple, personal script, I wouldn't care if other people couldn't run it.
I had compiled it using wabt's wat2wasm.
The Wasm module was intended to be fed the entire globalThis object to import from.
From there, it took four TypedArray constructors: Uint8Array, Uint16Array, Uint32Array, and BigUint64Array.
Take note: no code was executed prior to the Wasm, thus there cannot be any interference.
Later, I had realized that that the Wasm wasn't working as intended at all, my math was correct, but the variables were wrong.
I had narrowed my problem down to just this:
;; global -> global variable
(import "globalThis" "Uint8Array" (global $Uint8Array externref))
(import "globalThis" "Uint16Array" (global $Uint16Array externref))
(import "globalThis" "Uint32Array" (global $Uint32Array externref))
(import "globalThis" "BigUint64Array" (global $BigUint64Array externref))
;; func -> function
(import "console" "log" (func $console::log (param externref)))
(start $_start)
(func $_start
global.get $Uint8Array
call $console::log
global.get $Uint16Array
call $console::log
global.get $Uint32Array
call $console::log
global.get $BigUint64Array
call $console::log
)
This Wasm was instantiated like so:
WebAssembly.instantiateStreaming(
fetch(
"test.wasm", {
mode : "same-origin",
credentials : "omit",
cache : "no-store",
redirect : "error",
referrer : "no-referrer"
}
), globalThis
).catch( console.error );
The interesting problem is that the logs all say the same thing: Uint8Array.
I was dumbfounded. This has to be literally impossible. The JavaScript file itself was not cached, the WebAssembly was being fetched with "no-cache," the web page itself wasn't cached.
Then I thought, because I was using XHTML, maybe it didn't happen in HTML files. It did there too.
I tried converting the Wasm file to a TypedArray and just using WebAssembly.instantiate, suddenly, it worked flawlessly.
At this point the server must be serving the wrong file, because the further I go, the more this seems like nonsense.
I almost want to say that this is a Chromium browser or V8 runtime error, but I need to narrow it down a bit more before I blindly attempt to present this as a bug.
I have set up two different versions of the same code, on Repl.it, and on CodeSandBox.io, so that hopefully someone can try running it themself, to confirm the bug, and maybe attempt to debug where I went wrong.
(Could this be a problem with Repl.it's server?)
This was a compiler bug fixed by Chromium in
https://chromium-review.googlesource.com/c/v8/v8/+/2551100.
This was the response that I had gotten from one of the developers:
This is indeed a timing issue that has been fixed in https://chromium-review.googlesource.com/c/v8/v8/+/2551100. The problem happens when there are only imported globals, and compilation of the WebAssembly functions finishes before the stream actually finishes. In this case, the offset calculation happens after the compiler uses the offsets, and therefore produces incorrect code.
A workaround is to define one global that is not imported, as this causes the offset calculation to happen earlier.
Seems like sending a small module that only imports globals instead of functions was breaking the code.
Their code had a threading race condition between the stream and the compiler.

Uncaught DOMException: Failed to execute 'define' on 'CustomElementRegistry': this name has already been used with this registry

Uncaught DOMException: Failed to execute 'define' on 'CustomElementRegistry': this name has already been used with this registry
at http://127.0.0.1:8000/components/#polymer/polymer/lib/elements/dom-module.js:175:16
Tried deleting node-modules and package-lock and reinstalling did not work.
this error is due to a custom element tag-name being registered which is already registered; to fix simply check that an element by this name hasn't already been registered. This example solution checks to see if something is already registered using the existing API and if not, registers the given Class (inheriting from/extending HTMLElement--at some point):
customElements.get('the-element') || customElements.define('the-element', HTMLTheElement);
For more on the API see https://developer.mozilla.org/docs/Web/API/CustomElementRegistry
most/mature libraries address this problem and those that don't, or are mangled by package and build process complexities can have it pop up; in most cases either updating to a current version, migrating to Lit (https://lit.dev) or patching the problem somehow provides a path to a solution; note the simpler solutions are far easier to maintain--as can be seen in the conflation of npm, polymer over the actual error in the original question; the Polymer project became lit-html and LitElement, and recently rebranded as "Lit" (and still includes these lit-things). Professionally I'm migrating away from npm and Nodejs to Deno with the aim of generally resolve the many problems related to npm and tooling insecurity and complexity, however this answer provides a more direct solution (understand the problem and fix directly, or update to the relevant latest solution which includes this somehow).
Well, this worked for me, with no Typescript warnings,
if (!customElements.get('the-element')) { customElements.define('the-element', HTMLTheElement); }
Hope someone will find this useful.
Cheers.
It is unwise to use the answers above. You want it to fail! The reason being is that your NPM should be deduping duplicate packages, so the fact that you see a certain component being defined on the custom elements registry more than once is a crucial error that you need to debug why the same component is registered more than once.
How to debug, in short, go to your browser, inspect element, network tab, refresh, figure out which files are both registering the same element. Then check in the initiator to see which files are loading those files. Then you get a way better idea of why your app is not resolving the same import to a single place (your deduped dependency).
One reason why you might face this problem is due to semver. If you have multiple different major versions of the same dependency, NPM cannot just dedupe all of the installations to your root node_modules. How you solve this is up to you. Some people use npm-aliases for their different majors of a dependency, some people implement a plugin in their build-tool to resolve paths to a single installation, etc.
For people that can't use #jimmonts answer because the issue is in one of their dependencies you can use the following snippet:
This happens for us, because a package we are using defines an element. But this package is used by multiple apps. And these apps, wouldn't you know it, interact. So customElements.define('x-tag', className) gets called multiple times. And the second time it does, it crashes the app.
function safeDecorator(fn) {
// eslint-disable-next-line func-names
return function(...args) {
try {
return fn.apply(this, args);
} catch (error) {
if (
error instanceof DOMException &&
error.message.includes('has already been used with this registry')
) {
return false;
}
throw error;
}
};
}
customElements.define = safeDecorator(customElements.define);
I was getting the same error. You may not have the same issue as me but I thought I would drop my solution here just incase someone runs into the same issue in the future.
I had two modules that both imported the same custom element module, one of the was importing Module.js and the other module.js. Now the browser saw this as two separate files because URLs can be case sensitive, except my server saw this as one file because it is not case sensitive (express.js) or at least it was able to resolve the path to the correct file even with the incorrect case. And so the browser saw two "different" modules both defining the same custom element, but when I searched my source code only one file was defining the custom element.
I had this problem and found out that I was calling on my boundle.js file twice. Since I was using Webpack and HtmlWebpackPlugin, HtmlWebpackPlugin added the reference to my boundled file to my index.html file where I had already referenced it by hand.
I developed a solution, thats overrite the define with a precheck before define. It works fine for me, just ad the 2 lines into your index.js
customElements.defineclone = Object.assign(Object.create(Object.getPrototypeOf(customElements)).define, customElements);
customElements.define = (name, element) => customElements.get(name) || customElements.defineclone(name, element);

Windsor WcfFacility: Setting ServiceBehavior properties

I'm hosting a service using Windsor's WCF Facility, but I can't get UseSynchronisationContext and ConcurrencyMode set that one would normally do using the ServiceBehaviorAttribute. I've seen two options that apparently should work (but tried both to no avail):
Registering ServiceBehaviorAttribute as a Component for IServiceBehavior
Modifying the Description collection of Behaviors in the OnCreated configuration callback in the WCF registration.
A third method that I've tried is using AddExtensions, but that results in an exception because there's already a ServiceBehaviorAttribute (by default?) in the list of Behaviors. This is also the case with method 2, but in that case I can remove it and add a new one, or modify the existing entry.
It's really frustrating that there doesn't seem any documentation on this except a line stating 'Remove the ServiceBehaviorAttribute' from your services, apparently because it can conflict with the WcfFacility.
Can someone point me on how to properly do this? Any hint is appreciated!
Unfortunately I didn't properly test. Modifying the properties of the ServiceBehaviorAttribute in the list of Behaviors of the Description property in the OnCreated action actually works as intended.
Sample registration:
container.Register(Component.For<IWCFWarehouseServiceAsyncCallback>()
.ImplementedBy<WarehouseService>()
.AsWcfService(new DefaultServiceModel()
.AddBaseAddresses(baseAddress)
.OnCreated(host =>
{
var sb = host.Description.Behaviors.Find<ServiceBehaviorAttribute>();
sb.UseSynchronizationContext = false;
sb.ConcurrencyMode = ConcurrencyMode.Reentrant;
})
.AddEndpoints(WcfEndpoint.BoundTo(binding).At("WarehouseService"))));

.get mootools method not working in joomla 1.5

i have a problem in joomla 1.5.18. i'm trying to get text from an element using for instance
var divContent = $$('#myDiv').get('text');
but each time i get the error, in chrome: Uncaught TypeError: Object #<HTMLDivElement> has no method 'get'; in firefox: divContent.get is not a function. why i'm getting this error?
even following samples in mootools i get the same.
i know how to do it for each object in the collection. i got doing $$('.') and using the "each" method:
$$('p.classname').each(function (el){
el.addEvent('click', function() {
var txt = el.get('text');
...
});
});
and obviously i add the function onto domready. i don't use jquery 'cause mootools & jquery stops the events each one... -i tried once & what i needed didn't work- and i wish to use all joomla resources including mootools.
checking the version in mootools.js it says 1.13 (?)
not sure which version of mootools comes in joomla 1.5.18, it may be 1.2.5. if so, .get should work but not as you expect it to.
You are probably a jquery user, used to $("#myid") and find that the only way to get similar results with the # in there in mootools is via document.getElements, aka, $$.
the problem is, to get a single item by id in mootools, you actually do document.id("mydiv") or even $("mydiv"). $$("#mydiv") will actually return a COLLECTION of elements with a single member, so [obj], so the real element is $$("#mydiv")[0].
if you apply a .get method to a COLLECTION, the getter normally iterates via a .each through all members and performs the get individually. it will return a new array member for each member of the collection - i.e. ["innertext"]; - though there should be a method for the collection, make sure that the element is there, it's in domready / onload and it's a unique id.
Still, I'd swap to using the $("mydiv").get("text"), it ought to be fine. This is all all too common assumption of jquery users that don't read the manual, in my experience. It results in bad and un-performant code due to all the .each iterations mootools has to silently do to work with the collection for you. Just saying.
You can also (and should) upgrade your Joomla to the latest version (security fixes, etc) and I believe it was about version 1.5.20 they included a newer version of mootools right out of the box (also there is a plugin for mootools upgrade you can enable). I believe the version included out of 1.5.20 is like 1.2.5 or something...
That may help!