Develop Reference

converting a dot.delimited object reference to a string (javascript)

I've looked everywhere, and it seems like the kind of thing that should be simple, so forgive me if this IS simple or violates best practices or I just missed it.
I want to be able to convert an object reference into a string. Not the object being referred to, but the reference itself.
Let's say I have a method nested in an object, for example:
a.b.c.d()
where a is the object and d is the method, how do I retrieve the string:
"a.b.c.d" ?
To be a little more specific, I want to pass the object reference as an argument to a function and be able to convert it to a string representing the key path:
function convertPath ( a.b.c.d ) {
...
}
could return the string "a.b.c.d". (I'd perform some other operations with it instead of just returning it, but I'm keeping this simple.)
Methods like "toString", etc. return the actual function being referenced as a string.
I've seen plenty of references to do the opposite (pass a string and convert it to an object reference), which would create other complications for me, but not this.
Any help would be appreciated. Thanks!

Understanding the JS code while setting up redis with Mongoose

I was trying to understand caching in NodeJS using redis.
In the lecture, the instructor told that best place to setup caching would be just before exec function in mongoose.
So in order to do that he did
const mongoose = require('mongoose')
const exec = mongoose.Query.prototype.exec;
//Redis logic
mongoose.Query.prototype.exec = function () {
console.log("i am here")
return exec.apply(this, argument);
}
1st: What will classify mongoose.Query.prototype.exec; as? value type or reference type? Because if it is a reference type then when we change mongoose.Query.prototype.exec = function then shouldn't its value change as well?
2nd I am unable to comprehend this line here return exec.apply(this, argument); Can someone explain this in stretch i.e this in apply points to where? and he is passing argument (this, argument); where does that Argument come from?
Can someone please help me out by answering both the above question?

What will classify mongoose.Query.prototype.exec; as? value type or
reference type? Because if it is a reference type then when we change
mongoose.Query.prototype.exec = function
exec is of reference type, but it is assigned the value of another reference variable mongoose.Query.prototype.exec. You can think of it like this : mongoose.Query.prototype.exec is itself pointing to an object (a Function object) in memory, and now after the assignment, exec is also pointing to the same object - in other words, the memory address of the object is copied (by value) from mongoose.Query.prototype.exec to exec during assignment. So the value of the variable mongoose.Query.prototype.exec itself i.e. the memory address stored in it, can be changed without affecting the other variable exec. They both will just end up pointing to two different objects.
Can someone explain this in stretch i.e this in apply points to where?
In this case, it'll be the object on which this function will be invoked i.e. the Query instance.
and he is passing argument (this, argument); where does that Argument come from?
Unless there is some code you missed to copy paste in the question, argument appears to be a typo. He was probably referring to the built-in object arguments which is accessible inside every function and consists of the arguments passed to the function. Here is a reference.
At a high level, what the instructor is trying to do is to override the built-in behavior of the function Query.exec() to add some of his own custom processing. He first creates a "backup" of the original function, then points Query.exec to his custom function which adds the custom processing (the log statement) and then hands over control to the backup i.e. proceed with built-in behavior. Whoever invokes exec() on a Query instance after this point will see the overridden functionality - first a log statement, then built-in behavior of exec()

Why is arrow function sent as a parameter when it simply returns the value it takes as is?

I am new to JavaScript and I am learning React using the following tutorial.
It also teaches to use Alt as a state management library and my question is related to the connect method syntax. I am not explaining the problem in detail as I believe my question is only related to understanding the syntax.
I understand that here connect passes comma separated parameters as props to the component App. I however do not understand the first parameter.
The arrow functions I have come across all use {} after => such as () => {}, where parameters will be in () and body of the function will be in {}
My understanding of ({lanes}) => ({lanes}) is that this is a function that takes an array of objects named lanes and returns the same array .The code snippet is as below:
export default connect(({lanes}) => ({lanes}), {
LaneActions
})(App)
My questions are:
Am I right that the first parameter is indeed a function?
is lanes enclosed in {} to specify it's an array? If no, what does it represent?
If 1. is right, why pass a function that passes the parameter as is. Why not write connect as connect(lanes,LaneActions)(App) or connect({lanes},LaneActions)(App)
Would enclosing lanes in {} make a difference and what is it?
If 1. is wrong please explain what the first parameter means.

Yes, that is indeed an arrow function.
No, that is not an "array" in JS (although if you've used PHP, you might mistakenly call it that, since the PHP community often uses "(associative) array" for this concept). That's an "object" in JS jargon, i.e., a key-value data structure (whereas in JS, arrays are numerically indexed). Specifically, the left-hand side is a new feature called "destructuring arguments", which takes an object and pulls out specific keys into local variables. On the right-hand side, there's an object literal, creating a new object based on local data (note that the value is omitted, a trick possible in recent JS).
Presumably because connect expects a callback as the first argument, and would break if you passed a non-function. Also, note that this isn't plain passthrough; it strips every key except lanes from the first argument, before returning it.
Since (1) is right, no answer needed here.
5 & 6: These are a bit broad. I'd recommend asking a new question or checking MDN's page on arrow functions if you want to find out all there is to know. To answer for this specific case: the () on the argument is needed because the arguments are more complex than a single identifier, the {} in the arguments are for destructuring, the () on the body is to distinguish between an object literal and a block consisting only of the single statement lanes, and the {} in the body creates an object literal.
If you're wondering exactly what the (somewhat densely-coded) arrow function does, by the way, it does roughly the same thing as the following (give or take a few currently-irrelevant quirks of arrow functions):
function(obj) {
return { lanes: obj.lanes };
}

[].slice.call(this) vs array.prototype.call(this)

Just wondering what's the different with the following js script.
[].slice.call(this) vs Array.prototype.slice.call(this);
They seems to be doing this same, can someone explain the different and which one i should stick with?
Cheers

They are almost identical. Let's examine each of them:
[].slice.call(data)
What it does?
[] - this creates new Array, same to new Array()
slice - it retrieves method slice from array
call(data) - it calls slice() method replacing its current context with data variable, i.e. uses data as its internal array, not []. This returns our data converted into Array.
Now, the second one:
Array.prototype.slice.call(data)
This one:
Array.prototype.slice - retrieves method slice from Array.prototype; in a nutshell - it returns you slice method without any context (internal data).
call(data) - as in previous variant, calls this method with data as its context.
Conclusion
Both [].slice and Array.prototype.slice return you a slice function which you can call on some array, however this array is passed not as argument, but as context (using call method of function object). In JavaScript, these calls will be absolutely the same:
// Calling as a method of 'Hello' string
'Hello'.indexOf('e') // returns 1
// Calling as unbound method
String.prototype.indexOf.call('Hello', 'e') // returns 1
String.prototype.indexOf.apply('Hello', ['e']) // returns 1
Those methods are almost the same. First one is more readable, but second one uses a bit less memory because it isn't creating a temporary initial Array.

I believe that Array doesn't actually create an object, where as [] is an instance of Array.

Definitely stick with the latter one as the first one is an implicit array construction and the same as:
new Array().slice.call(this)
Its constructing a new array that needs to be garbage collected afterwards since you dont use it. While both statements "work", the above mentioned does a lot of extra work, first you construct a new instance, then you look up if the instance itself has a slice property, as this is false the prototype chain is traversed and the slice is found on the Array.prototype and then called. Then you call it with your other array as scope, so essentially render the instance you created useless by using your other one.
Thats why Array.prototype.slice.call(myarr) is the proper way of accessing the slice method.

Array.prototype.slice.call() seems slightly more performant, though that makes sense because it would be quicker at runtime to "look up" this method. I posit that [].slice.call() is the best choice. Here's the jsperf of reference
Let's be real, in what case would the negligible difference between the two be a major contributor to poor website performance? sounds like heaven, actually. The shorter syntax of the literal method is awesome. I'd rather save myself the half-second it'd take to type the prototype variant than be shakily more efficient.
The coffin nail of Array.prototype... some people say is that it's irresponsible because you risk altering it. But... that's stupid. Figure 1: Array.prototype = function() { console.log('foo') }; Whoopsie... That probably happens all of the time. Seriously, even granting its legitimacy is still intact, it takes me longer to type and is imo hideous compared to its sexier literal sister.
The real answer to your real question is that the functionality is exactly the same. Use whichever you will still appreciate on your deathbed.

Using the Javascript slice() method with no arguments

I'm currently reading through this jquery masking plugin to try and understand how it works, and in numerous places the author calls the slice() function passing no arguments to it. For instance here the _buffer variable is slice()d, and _buffer.slice() and _buffer seem to hold the same values.
Is there any reason for doing this, or is the author just making the code more complicated than it should be?
//functionality fn
function unmaskedvalue($input, skipDatepickerCheck) {
var input = $input[0];
if (tests && (skipDatepickerCheck === true || !$input.hasClass('hasDatepicker'))) {
var buffer = _buffer.slice();
checkVal(input, buffer);
return $.map(buffer, function(element, index) {
return isMask(index) && element != getBufferElement(_buffer.slice(), index) ? element : null; }).join('');
}
else {
return input._valueGet();
}
}

The .slice() method makes a (shallow) copy of an array, and takes parameters to indicate which subset of the source array to copy. Calling it with no arguments just copies the entire array. That is:
_buffer.slice();
// is equivalent to
_buffer.slice(0);
// also equivalent to
_buffer.slice(0, _buffer.length);
EDIT: Isn't the start index mandatory? Yes. And no. Sort of. JavaScript references (like MDN) usually say that .slice() requires at least one argument, the start index. Calling .slice() with no arguments is like saying .slice(undefined). In the ECMAScript Language Spec, step 5 in the .slice() algorithm says "Let relativeStart be ToInteger(start)". If you look at the algorithm for the abstract operation ToInteger(), which in turn uses ToNumber(), you'll see that it ends up converting undefined to 0.
Still, in my own code I would always say .slice(0), not .slice() - to me it seems neater.

array.slice() = array shallow copy and is a shorter form of array.slice()
Is there any reason for doing this, or is the author just making the code more complicated than it should be?
Yes there may be a reason in the following cases (for which we do not have a clue, on whether they apply, in the provided code):
checkVal() or getBufferElement() modify the content of the arrays passed to them (as second and first argument respectively). In this case the code author wants to prevent the global variable _buffer's content from being modified when calling unmaskedvalue().
The function passed to $.map runs asynchronously. In this case the code author wants to make sure that the passed callback will access the array content as it was during unmaskedvalue() execution (e.g. Another event handler could modify _buffer content after unmaskedvalue() execution and before $.map's callback execution).
If none of the above is the case then, yes, the code would equally work without using .slice(). In this case maybe the code author wants to play safe and avoid bugs from future code changes that would result in unforeseen _buffer content modifications.
Note:
When saying: "prevent the global variable _buffer's content from being modified" it means to achieve the following:
_buffer[0].someProp = "new value" would reflect in the copied array.
_buffer[0] = "new value" would not reflect in the copied array.
(For preventing changes also in the first bullet above, array deep clone can be used, but this is out of the discussed context)
Note 2:
In ES6
var buffer = _buffer.slice();
can also be written as
var buffer = [..._buffer];