Question 1: If there a post such as this one. How would I represent it in JavaScript? I thought was JSO and parse. Other programming language like C++ and JAVA a main function and have map references but where does JavaScript store it's objects?
Question 2: Oh and do I add Event Handlers to each of the HTML representatives elements?
The basic data structure in JavaScript is the object, you would probably use one (or, more likely, a structured collection of them along with more specific data structures such as arrays) to describe the data structure that makes up a webpage.
The main function in Java and C++ is the entry point to the program. In JavaScript, the entry point is the top of the program.
JavaScript stores its objects in memory and references to them in variables and as properties of objects.
You would only add an event handler to an HTML Element object if you wanted to listen for an event on it.
People are saying store objects in variables but it's I was also told its better to hash them and create references to them in an array.
You use the data type most appropriate for the data you are working with.
If you have a:
simple piece of data, use a variable.
collection of ordered data, use an array (or maybe a Set if you are using ES6)
collection of unordered data, use an object (or maybe a Map if you are using ES6)
… and nest to whatever level makes sense.
You might also create a custom data type with a constructor function or (if you are using ES6) a Class.
Related
If I add custom data to my html controls, how will the performance and memory consumption be in the following scenario:
1. Adding a string or a number in customdata.
2. Adding an existing object (already created object in previous lines of code).
3. Adding a map (object) of (string, existingObject).
By existingObject, I mean an already created object, eg: map/object created in previous lines of code, or model object in angular js.
As per my understanding, storing object as custom data is like storing reference of an object which is already there, so it should not be expensive in terms of space, nor should it make html page heavy. Please correct me if I am wrong.
I understand that js' JIT compiler will deoptimize the warm or hot code in case datatype changes in a loop (like one element in array is string whereas rest were int).
But i have few scenarios where i'm not able to understand will the code be deoptimized or not
Same loop is used for two arrays where one array contains strings and other ints. Will compiler deoptimize the code here or create two copies? (I understand it should be two copies).
In case of array of object. Considering all scenarios like
Manipulated sub-property is of different type.
Same sub-properties for each object but one object has one property missing.
Missing property is not manipulated inside the loop.
Missing property is manipulated inside loop (null case is handled).
All objects have different properties (New property is added, or manipulation is done using property location).
JavaScript creates a bunch of objects in memory. Even "classes" are really just prototype objects in JavaScript.
I want to create a list of all of the objects currently instantiated on a page. I realize this might include JavaScript basic objects like String.prototype and Number.prototype. I think that's great!
Bonus points for also telling me how to query JavaScript's object space more specifically. Perhaps, say, find all objects currently in memory with a property key matching "name".
This question already has answers here:
How does JavaScript VM implements Object property access? Is it Hashtable?
(4 answers)
Closed 2 years ago.
I was wondering about how Objects are implemented under the hood in Javascript engines (V8, Spidermonkey, etc). Are they really just Hash Tables? If so, how do they handle collisions?
First of all, the answer is probably somewhat different for different JS engines. Also, I assume you're specifically asking about the property storage; obviously objects have a bunch of other state too (prototype chain link being an obvious one).
In the case of Spidermonkey, objects basically have a linked list of (propname, information about property) pairs, until they have too many properties, when I believe they still keep the linked list (because order matters for properties in JS in practice) but add an out-of-band hashtable that maps property names to entries in the linked list.
There may also be other reasons for the switch to the hashtable; the details haven't exactly been fixed over time and are likely subject to change in the future.
The linked lists and hashtables are actually shared across objects; as long as two objects have the same property names and corresponding property information (which does NOT include the value, for properties with a stored value) and the properties were set in the same order, they're able to share the property linked list.
The actual property values, when those need to be stored, are stored in an array in the object (or more precisely, two arrays; one allocated inline with the object, whose size is fixed at object-creation time, one dynamically allocated and resized as needed for properties that are added later).
Take a look at a similar question How does JavaScript VM implements Object property access? and my answer. Here I described the optimization technique used by JS engines and how it affects the key lookup performance. I hope that knowing of these details let you write more efficient JS code.
One can think of an object as an associative array (a.k.a. map, dictionary, hash, lookup table). The keys in this array are the names of the object's properties.
I found this on MDN
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Property_accessors
In JS arrays are associative arrays and objects are also the same.
In JS arrays are basically objects with properties as sequential numbers.
Sorry if this is a stupid question, this is my first JS project...
I'm trying to deserialize a custom object in JS using JSON. The problem is, JSON.parse() does not return the object as its original type. Since directly casting the returned object to the desired type doesn't seem possible, that leaves me with the 'reviver' option...
Am I missing something here? Wasn't the entire point of JSON to avoid having to write custom methods to serialize and deserialize objects? What's the point of using JSON if I have to write my own method 'revive' my object?
JSON is a format for raw data. It's very primitive. It supports dictionaries (aka. javascript objects, hashes, associative arrays), arrays, strings, numbers, booleans and null. That's it. The reason it doesn't do more is that those primitives are language agnostic, and nearly all programming language have built in tools to handle those types of data.
If you had other notation like "class" then suddenly it becomes very bound to specific languages or codeboases, and lose it's wide and generic applicability.
So think of JSON as simple raw data. JSON is not instance marshalling or complete object serialization. So yes you need to write "revivers" if you intend to serialize JS objects instantiated from constructors.
This is the approach things like backbone.js take:
new Book({
title: "One Thousand and One Nights",
author: "Scheherazade"
});
You simply pass your plain object of data (the result of your JSON.parse()) to the call to your constructor of choice. From there you can do any number of things to read it's values into your new object.
Javascript has no standard way of Marshalling whole objects like you can in ruby with Marhsal.dump(obj) for instance.
EDIT: One last major point...
Javascript objects don't have a "type" as you would think of it in other languages. A Javascript object is simply a a dictionary of key/value pairs. When you do something like new SomeClass() you get a new object, that has a special prototype property that points to the prototype property of the SomeClass function object. Wether an object is an instance of SomeClass is less of a clear cut question than you may think at first glance.
Instead you may ask "What is my constructor function object?" or "What objects are in my prototype chain?"
So if you wanted to convey "type" in JSON, which is stored as a string, then how would you store a reference to a prototype object? Maybe the prototype object is not named in the global scope at all, and only available via closure? Then when you write that out to string, you have no way of referencing that prototype object anymore at all.
The point is that javascripts prototypical approach to object instantiation, combined with it's closure based lexical scoping and the fact that objects hold their values more like C pointers than literal values, makes it very very hard to fully serialize an object out to a location external to the VM.