value is undefined for some users, empty string for others - javascript

I have a form that on submission packages the data into an ajax format and sends to a coldfusion script via ajax. A bug crept up that affected from two computers but not mine and another. I tracked it down to a struct key not existing. When I do a console log of the packaged json data, we all see the struct key before it's passed. For me, its value is an empty string. For others, it says undefined. And because of that, coldfusion appears to drop the key from the struct after receiving it, which is what caused the initial issue we had. Once that was determined it was a simple fix.
The struct key is assigned a value from a jquery object, which is a SELECT element (no multiple). My structure would look something like this:
var fields = {
myVar: $('#import_me').val()
};
What I'm trying to figure out is why, when nothing is selected, does it assign an empty string for me but will be undefined for my colleagues? We're on the same browser and version.
Would this give me more consistent results instead?
$('#import_me option:selected').val()

Does this work for you?
A fallback:
var fields = {
myVar: $('#import_me').val() || ''
};
It should set an empty string as fallback if there is no val()
But possibly this is better:
Check the variable and set it to empty string if it is undefined.
var fields = {
myVar: $('#import_me').val()
};
if (fields[myVar] === undefined) {
fields[myVar] = "";
}

Related

How do you get the value of localstorage, without setting it as a Variable

I know that's probably very confusing, but what I want is to get the value of a localstorage, without setting it like:
var cookies = localStorage.totalCookies
I'd want it to be like this:
var cookies = value of localstorage.totalCookies
I want this so that the var cookies doesn't equal localstorage as I want a one time change to the var cookies, not a constant localstorage updating.
The data type of what is stored in localStorage is always string, even if you wrote a numerical value to it.
To get back the numerical value, you just need to coerce it back to a number, for instance with the unitary +. You should also provide a default value for when the entry is not present in localStorage. If that default value is 0, then you can write it like this:
var cookies = +localStorage.totalCookies || 0;
Or, if you want to test for the presence of that entry, and do another test on whether it is numerical:
if (localStorage.totalCookies === undefined) {
console.log('The totalCookies entry was not found');
// etc..
} else {
var cookies = +localStorage.totalCookies;
if (isNaN(cookies)) {
console.log('The totalCookies entry is not numerical');
// etc...
}
}
This is happening because when you declare a variable to be an object, you're creating a reference to the object, not a duplicate of it. You can use the get & set methods of localStorage, as mentioned by War10ck in the comments above:
Get: localStorage.getItem('totalCookies')
Set: localStorage.setItem('totalCookies', 'some value')
Remove: localStorage.removeItem('totalCookies')
But in general, you need to find a way to clone an object to prevent subsequent tampering with the original. Here's a quick way:
var cloneOfA = JSON.parse(JSON.stringify(a));
You can see a larger discussion about this here:
How do I correctly clone a JavaScript object?

JSON.stringify and Object.keys produce different results on same object

I have an issue that isn't making any sense to me. I was wondering if any of you could help.
I have a data source object which I use to access REST data through. All the complex asynchronous stuff works fine, but I've come completely unstuck on what should be the very simple task of passing options into the configuration of the data sources.
At the moment, I have this function:
object.addSourceOption = function( model, optKey, optVal ){
if(!_.has(config.sources, model) ){ return this; }
else{
var options = config.sources[model]["options"];
options[optKey] = optVal;
console.log(options[optKey]);
//options = JSON.parse( JSON.stringify( ) );
console.log( "Source Option: " + optKey + ": " + optVal
+" added for model: " + model );
var debugString = JSON.stringify(options);
console.log(debugString);
console.log( Object.keys(options));
}
return this;
};
This function is being called and it's being called with good values as far as I can see. Here's an example of some debug output (in this case, the key value is "post_get" and the value is a function, which is printed):
function (element){
}
restData2.js:189 Source Option: post_get: function (element){
} added for model: Contacts
restData2.js:191 {}
restData2.js:192 ["post_get"]
I don't understand why JSON.stringify and Objects.keys produce different results. I don't understand which to trust to debug the code I'm using, or what could possibly be happening behind the scenes to make the two functions disagree about the code I've written.
Congratulations! You've found one of the subtler parts of JSON.stringify(...) :)
Here's a helpful part from MDN:
If undefined, a function, or a symbol is encountered during conversion it is either omitted (when it is found in an object) or censored to null (when it is found in an array). JSON.stringify can also just return undefined when passing in "pure" values like JSON.stringify(function(){}) or JSON.stringify(undefined).
While JSON is convenient because it looks like Javascript, JSON is really a subset of Javascript. Moreover, not all JS objects can be represented in JSON. The full details are available at http://json.org/.
But yeah, in your example, post_get is not showing up in the JSON because properties of type function are not legal in JSON.
Hope this helps!
Aside:
Also, keep in mind that sometimes a JS object can have properties that aren't returned by Object.keys(...) either, because Object.keys(...) only returns the properties that were not inherited from any prototypes (base objects) that the object extends.
the key value is "post_get" and the value is a function
JSON.stringify() won't include properties that refer to functions. Object.keys() will. It's as simple as that.

Equivalent of Python's KeyError exception in JavaScript?

I am trying to access a certain member in a JavaScript object. In order to do this, I need to try out a couple of key values.
For example, Object['text/html'] which will give me an export link for a HTML document. However, not every object of this type will have a text/html key pair value.
In Python I would solve this problem using a Try-Catch block, with the KeyError exception. If I can do something similar in javascript, as in use an exception in a Try-Catch block, that would be great.
However, if alternatives exists instead of try catch blocks, that do achieve the same end goal, I would like to know about them as well.
EDIT:
I would prefer to use an exception over using functions. I do this because the text/html key might not be there, but it should be there. An exception seems more appropriate for this scenario
Javascript doesn't generate an exception when reading or writing a property that doesn't exist. When reading it, it just returns undefined. When writing it, it just creates the property.
You could create your own function that tests to see if the property exists and throws an exception if it does not (but you'd have to call that function whenever), but JS doesn't make an exception out of that on it's own like you are asking for.
If you want to test if a key exists on an object in javascript, you can use this construct with the in operator:
var obj = {};
var key = "test";
if (key in obj) {
// key exists
} else {
// key doesn't exist
}
If you try to read a key that doesn't exist, you will get undefined as the value.
var obj = {};
var value = obj.test;
alert(value === undefined);
The in operator does a better job of telling you whether the key exists that testing for undefined because undefined is a legal value for a key that exists.
In many cases, where you control the values that the keys have and a key that is present will never have a falsey value, you can also just check if the key has a truthy value:
var obj = {};
var obj.test = "hello";
if (obj.test) {
// key exists and has a truthy value
}
If you want to make sure that the object itself has the property and not any prototype that it is inheriting from, then you can do this:
var obj = {};
var obj.test = "hello";
if (obj.hasOwnProperty(test)) {
// key exists on the object itself (not only on the prototype)
}
Read this!
The accepted answer is correct however omits some points.
1) Accessing nested object
Like someone pointed out in the comment, Javascript returns undefined when the key doesn't exists in the object.
However, if you need to access an object inside an object (or an Array, or a function), well this break.
let a = {};
let userName = 'js'
let data = a.response[userName];
Cuz you will received actually a TypeError, basically because we are trying to read a property of undefined, which doesn't have any.
VM187:2 Uncaught TypeError: Cannot read properties of undefined (reading 'js')
at <anonymous>:2:22
2 Answering the question
The Python principle "Ask forgiveness not permission" - explain is actually for the most part working well in Javascript (and PHP, you didn't ask but well..). There are for sure some difference, or some situation where the difference is important, but for most use cases is the same
So this is how you would do it:
try {
let data = a.key1.key2['whatever'].nested.damn.object;
console.log(data)
} catch (error) {
let data = "noope";
console.log(data);
}
As you can see, in Javascript you don't really care about the error type, (for the most part, sure other situation you should case). Is almost like anything is in a Python's
try:
a = "hello" + 1 + {} + [] # crazy stuff here
except BaseException as bleh:
print(str(bleh))
Documentatin
MDN Working with objects
How do I check if an object has a key in JavaScript? [duplicate]

Javascript arrays and Meteor session

I have made an interesting observation. When trying to update an array that is stored in the Meteor session storage, the following code will not propagate the changes:
var tags = Session.get("Tags");
tags.push("a");
Session.set("Tags", tags);
But if I change the first line to use Session.get("Tags").slice(), everything depending on the session will update accordingly. I guess this is due to the fact that Meteor tests some references for equality and therefore does not update anything.
Is there a better way to manage lists stored in the meteor session store?
If I now try to remove an element from the collection (using array.remove() from here), the behavior turns out to be a bit ... of ... I am doing this inside a Meteor template event, the code looks like this:
"click .taglist li" : function(e) {
var tags = Session.get("Tags").slice();
var index = cardTags.indexOf(this);
Meteor._debug(Session.get("Tags").slice().indexOf("a"));
Meteor._debug("Removing tag \"" + this + "\", index: " + index, ", typeof(this) = " + typeof(this).toString());
tags.remove(index);
Session.set("Tags", tags);
}
This outputs:
1
Removing tag "a", index: -1, typeof(this) = string
So somehow, the cardTags.indexOf(this); statement seems to return -1 for almost any case. I guess I am doing something fundamentally wrong, as I am quite now to javascript, but somehow I can not figure out whats going on here.
Why will those two calls to indexOf() behave different?
I believe this is the same as this situation in Backbone.js. In order for the change event to be triggered, Meteor needs to have a new reference for the array, not just an updated copy of the old one.
In brief, in order to have the 'correct' behaviour, you'll need to clone the array, make the changes you want, and then do Session.set('foo', myCopiedArray).
In short: Use var index = cardTags.indexOf(this.toString()); instead.
Long version:
When using strings in JavaScript, those are strings, whereas typeof 'test' returns string.
Let's take a look at the following code in order to get find out another way to represent strings in JavaScript:
var func = function () {
return this;
};
console.log(func.call('test'));
The console (at least FireBug) won't show us "test", but instead it shows String {0="t", 1="e", 2="s", 3="t" }. typeof would return "object".
The content of the this statement seems to need to be an object. In order to convert a string into a "String" object we can do console.log(new String('test'));, which is the same as the previously logged value.
To convert a string object into a string (data type), just use its prototype toString.

Backbone.js source read-through

I'm reading through the Backbone.js source and am somewhat confused by these lines (L230-238, v0.5.3)
unset : function(attr, options) {
if (!(attr in this.attributes)) return this;
options || (options = {});
var value = this.attributes[attr]; // ?: value appears to be unused (?)
// Run validation.
var validObj = {};
validObj[attr] = void 0; //void 0 is equivalent to undefined
if (!options.silent && this.validate && !this._performValidation(validObj, options)) return false;
Am I crazy or does the last line run a validation against a hash object with a single undefined attribute?
It seems like the validation is intended to run on an instance of the Model object with the attribute-to-be-unset removed.
Current source on github with lines highlighted
you're correct in your assessment of what it does, but that's the intended functionality.
when you call unset, you can only tell it to unset one attribute at a time: model.unset("myAttr")
when unsetting, validation is called to make sure the model will be put into a valid state. if the attribute being set to undefined will cause the model to be invalid, the unset fails. if it is valid for the attribute to be undefined, the attribute is removed from the model.
the reason it passes a "hash object with a single undefined attribute" is that all objects in javascript as "hash objects" - key value pairs, or associative arrays. it doesn't matter how you get an object, it is an associative array.
an object with one empty attribute named after the model's attribute that is being unset, is created in lines 236-237. this is so that monkeying with the object passed into the validate method won't change the state of the model itself.
hope that helps explain things.

Categories