We Keep Coding

Trying to build nest functions within nested functions

working on a script and I thought dot notation would be a good way of building methods to use later on in the grander scheme of the script.
the original system would declare functions written as
memRead();
memReadGlobal();
memWrite();
memEtc();.......
but I wanted to change this to
mem.Read();
mem.Read.Global();
Here is an example
var mem = {
Read: {
function() {
console.log('Hello World')
},
Global:
function(key) {
console.log('Goodbye World')
},
},
}
I can call mem.Global just fine, but I can't call mem.Read
I can declare mem.Read if I add another object like Local(mem.Read.Local), but I feel like writing local is redundant and would like to avoid that.
Is there a way to create a nested function like I describe above?

You can do that, but not with an object initializer expression.
var mem = {
Read() {
console.log("Hello from Read");
}
};
mem.Read.Global = function() {
console.log("Hello from Global");
};
mem.Read();
mem.Read.Global();

What is the best way to convert OOP classes to FP functions?

I have found a GitHub repository full of JavaScript algorithms and data types. The thing is, everything is written in OOP. I myself, prefer a more FP approach using small, reusable functions. What are some best practices to convert classes to smaller consumable functions?
For now, I can come up with the following working example. Is this the way to go?
OOP:
class LinkedListNode {
constructor(value, next = null) {
this.value = value;
this.next = next;
}
toString(callback) {
return callback ? callback(this.value) : `${this.value}`;
}
}
FP:
function toString(value, callback) {
return callback ? callback(value) : `${value}`;
}
function Node(value, next = null) {
return {
value,
next,
toString(callback) {
return toString(value, callback);
}
};
}

In your second example you still have a method attached to each instance, which is not ideal as soon as you want to reuse this method on a compatible interface. Also it does not play well with many FP js libraries.
To make it clear from the outside that it is not a constructor function, make it start lower case and add a prefix like create for example.
Make functions as pure as possible and do not mix code composition logic (compose, curry) with the business logic. (I talk about callback having nothing to do inside toString)
I am adding export to clearly show that at least 2 functions need to be exported.
export { nodeToString, createNode };
function nodeToString(node) {
return `${node.value}`;
}
function createNode(value, next = null) {
return {
value,
next
};
}
It would be used like this
import { nodeToString, createNode } from "./x.js";
const node = createNode(`myvalue`);
const string = nodeToString(node);

How should I use JSDoc to document DOM events in my design pattern?

I have a custom-built JavaScript framework that I inherited from the person that worked here before me. What I can say is that it's a web app of sorts that leverages jQuery.
There are a lot of events being fired by various objects that I'd like to document, but I'm unsure of how to do this. I've seen JSDoc 3's examples on the #listens page, but they seem to be oriented more towards a module development pattern, so I'm unsure of how to apply them to the pattern here:
ClassA.js:
var ClassA = function (args) {
//constructor stuff goes here... usually punctuated with:
this.listenForEvents();
};
ClassA.prototype.listenForEvents = function () {
$(document).on("someEvent", function (e, args) {
//Event handlers are almost always anonymous and call class methods,
//usually to determine if the event needs to be handled by a specific
//instance of the class, or meeting a criteria. e.g.:
if (this.identifier === args.identifier) {
this.someClassMethod(args);
}
}.bind(this));
};
ClassA.prototype.someClassMethod = function (args) {
//handle the event
};
ClassB.js:
var ClassB = function (args) {
//constructor stuff goes here...
};
ClassB.prototype.doAThing = function () {
//code goes here
$(document).trigger('someEvent', { identifier: 'someIdentifier', aValue: 1, anotherValue: 'two' });
};
How/where do I use the #event, #listens, and #fires doclets with this design pattern?

Real abstract method in javascript

I would like to create an abstract class in javascript, which implements certain methods, calls abstract ones and let the 'inherited' classes to implement these abstract ones. I've read a lot about js prototyping. Every single suggested implementation of abstract classes and methods in javascript seems to be a simple inheritance, but not real abstraction.
Here is a really simple example to show what i want to achieve:
var abstractClass = {
abstractMethod: function() { /* i don't know yet what i'm going to do */ },
concreteMethod: function() {
abstractClass.abstractMethod();
}
}
specializedClass = Object.create(abstractClass);
specializedClass.abstractMethod = function() {
alert('Now i know what to do');
}
specializedClass.concreteMethod();
My question: is there a non-hacky, non-workaround way to make abstract classes in javascript?

inside the methods, use this instead of the named class/variable, which is duplicated/broken by your Object.create() call.
var abstractClass = {
abstractMethod: function() { /* i don't know yet what i'm going to do */ },
concreteMethod: function() {
this.abstractMethod(); // < made generic with this
}
}
specializedClass = Object.create(abstractClass);
specializedClass.abstractMethod = function() {
alert('Now i know what to do');
}
specializedClass.concreteMethod();

attache function to other function in javascript

I have a simple requirement, I need add the same code to hundreds of other JavaScript functions, the code can be executed at the end of the function, is there a handy way of doing it, like attach an function to another function dynamically, I think yes, because JavaScript is so powerful and too powerful, any ideas?
Note, I need dynamically assign new code or function to existing functions without change existing function's code, please give a solid solution, I can do it in hacky way, but no hacky way please!

The first method that comes to mind is simply create another function:
function primaryFunction() {
// ...
utilityMethod();
}
function otherPrimaryFunction() {
// ...
utilityMethod();
}
function utilityMethod() { ... }
Now utilityMethod() gets called from the end of each other primary function.
There's also a method which requires more code refactoring but is better in the long term: classes/prototypes.
Essentially, you have one "constructor" function which takes a number of parameters for the "class" and returns an class-like object:
function constructor(someClassField, anotherField) {
this.aField = someClassField;
this.fieldTwo = anotherField;
return this;
}
Now if you call this and pass some parameters, you get a class out:
var myClass = new constructor("1", "2");
myClass.aField == "1";
myClass.fieldTwo == "2";
So: If you define your utility method as above, then you can use this: for every primary function you instantiate a new instance of the constructor, with the final code looking like this:
function constructor(primaryFunction) {
this.function = primaryFunction;
this.call = function() {
this.function();
utilityMethod();
}
this.call();
return this;
}
function utilityMethod() { ... }
var primaryMethod = new constructor(function() { ... });
The creation of primaryMethod now automatically calls the primary function followed by the utility method, before returning the object so you can re-call both if you want to.