But keep in mind, I was asking for learning purposes of the Map() object
Well, the task you were trying to use it for is a total mismatch. Map would generally be best used for things like lookup tables of complex mathematical calculations.
Mind you, I said WOULD be best used, but there's a problem. JavaScript array-likes are painfully and agonizingly slow to the point that unless the calculations/operations performed are really, REALLY complex, it's faster to just run the calculation than to store it in an Array or Map... because neither are actual arrays, they're pointered lists. This is how when you delete a JS array entry the indexes change...
Because to access the tenth element in an array via arrayLink[100] it actually sits there counting through the first 99 elements. You'd THINK they'd just make it an array of pointer, instead of array of Object, so indexing is a simple mul, but apparently that never occurred to anyone.
I really have not seen a legitimate usage case for map() that couldn't be better handled better, simpler, cleaner, and more backwards compatible by a normal every-day object.
I'm not sure I see the need to trash "arrow" functions and "let" statements, as they seem to work.
Arrow functions will INSTANTLY make your javascript crash -- halting ALL scripts on your page -- by its mere PRESENCE in all versions of IE. Even IE11 flat out doesn't know what it is, and utterly loses its mind when it sees it.
But even legacy aside, they seem to exist for two reasons -- NEITHER of them good. One being the "wah wah, eye dunz wunna type" mental midgetry, but WORSE? They promote the use of callbacks in situations -- like the derpy "foreach" that results in fatter, slower, more memory hungry code.
EVERY time you make a callback, you're adding function call overhead to the program, and one of the fastest ways to speed things up is to stop using functions where they aren't warranted, or to just make a normal everyday plain-Jane function. In that way -- like a lot of ECMAScript of late -- it reeks of being created by people coming from other languages like Java and being unwilling or unaware of what JS is, how it works, or why it does things the way it does.
... and the result of this crap is fat, bloated, slow cryptic, hard to maintain codebases.
Same for the derpy let, 99.99% of the time serving ZERO legitimate purpose over var. Oh noes, var's not released until garbage collecttion is sure it is, and it's only scoped to function block, not every damned block. Wah wah wah. Again, crutches for the people too stupid to handle scope, and guaranteed to make you work harder, not smarter. LET -- and to a degree CONST -- serve no purpose in the majority of codebases other than to make the code consume more memory, more CPU, and take longer to run. They are stupid dumbass additions to the language it REALLY didn't need.
As evidenced by the code halfwits, morons and fools vomit up using it, since if I see one more instance of:
function test() {
let myVar = 0;
My boot is going so far up that person's backside we need to call an orthodontist to handle the extraction.
Since LITERALLY in that case LET would/should perform just like var except for garbage collection gets called more often.For "quick and dirty" scripts I don't mind using .innerHTML for .innerText for brief displays of results.
NOT a good habit to get into, since much like document.write they are archaic relics that should have gone the way of the dodo about the same time we stopped giving a flying purple fish about Netscape 4.
Really though the logic failure in your code was that you were trying to assign a function that was being RUN.
commandTable.set( 'btn1', btnAction("Hello btn 1") );
would
RUN btnAction() right then and there meaning you're getting NULL back, since btnAction has no RETURN statement. You're storing the result of RUNNING the function, what it does a RETURN of (in this case nothing, so null). That's why you have to store the values separate from the function.
Hmm... you know, another option that WOULD work with map? Make btnAction a constructor that when passed parameters assigns them to self, but when not passed parameters outputs its values.
Something like:
function BtnAction(callback) {
if (arguments) {
this.callback = callback;
this.args = arguments;
return;
}
this.callback(arguments);
}
Where you would do a:
commandTable.set( 'btn1', new BtnAction('btn1', 'Hello btn 1'));
Since that would return your object/constructor, which could then be called again. No idea how well or even if that would work, and it seems like a lot of effort for nothing.
Attaching properties to an object using defineProperty might be another option, making the values be an indexed array that's non-iterable attached to the document, whilst the methods themselves are iterable.