Namespaces: Novice Seeks Help Exploring the Revealing Module Pattern

Hi Everyone:

My Goal and Proposed Process

The Goal is to Understand and Implement the Revaling Module Pattern Template used by The Aaron (see code below). I hope to do this by thoroughly documenting in this thread my attempt to implement it and rigorously asking the community the questions that I have. Hopefully, this will be helpful to others that come along afterwards.

A Brief Note about My Programming Experience

I have a tiny bit of programming experience. Highlights include developing a couple of desktop applications some time ago in Foxpro. Some years later I took a look at Delphi/Pascal but I got busy with other things and never finished that project. Since that time I have done a little bit of macro and scripting here and there (mostly in LibreOffice Basic). A few years ago I took some Treehouse courses on html, css, php, ruby, git, etc. I've forgotten most everything except for some general concepts (i.e.) scope, variables, loops, conditional logic, etc. 

I put together a custom character sheet for my homemade RPG a couple of weeks ago. You can take at Screenshot 1  and Screenshot 2 if interested. Then I took a JavaScript tutorial from sololearn.com and have been playing around with JavaScript and the Roll20 API for about a week relying on mentoring from the Roll20 community here where the community helped my get my feet wet accessing the API character object and creating lookups and much much more.

Source Material

The Aaron's template as of today's date:

// Github:   <WHERE YOU STORE IT>
// By:       <YOU>
// Contact:  https://app.roll20.net/users/<YOUR ID>
const NAME = (() => { // eslint-disable-line no-unused-vars
    const version = '0.1.0';
    const lastUpdate = 1531675536;
    const schemaVersion = 0.1;
    const checkInstall = () =>  {
        log('-=> NAME v'+version+' <=-  ['+(new Date(lastUpdate*1000))+']');
        if( ! state.hasOwnProperty('NAME') || state.NAME.version !== schemaVersion) {
            log(`  > Updating Schema to v${schemaVersion} <`);
            state.NAME = {
                version: schemaVersion
            };
        }
    };
    const handleInput = (msg) => {
        if (msg.type !== "api") {
            return;
        }
        let args = msg.content.split(/\s+/);
        switch(args[0]) {
            case '!NAME':
                break;
        }
    };
    const registerEventHandlers = () => {
        on('chat:message', handleInput);
    };
    on('ready', () => {
        checkInstall();
        registerEventHandlers();
    });
    return {
        // Public interface here
    };
})();

My Beginning Steps

Based upon the work G G and The Aaron have done here and here I begin implementation by taking the following steps:

1. From the Roll20.net landing page navigate to [Campaign] > Settings > API Script > New Script where [Campaign] is the name of your campaign.

2. Paste the code above into the 'untitled.js' file. 

3. Rename 'untitled.js' to 'rmptutorial.js'. [Note: One could develop the script in his or her favorite editor and copy and paste it into into the javascript file and use a different filename. I am describing the steps I took.]

4. Search for "NAME" and replace that with my chosen namespace of "rmptutor".

RMP stands for Revaling Module Pattern and there is an entry for it in the Roll20 API Cookbook here.

And that's as far as I want to go on my own and now it's question time. =)

Current State of Tutorial Code

const rmptutor = (() => { // eslint-disable-line no-unused-vars
    const version = '0.1.0';
    const lastUpdate = 1531675536;
    const schemaVersion = 0.1;
    const checkInstall = () =>  {
        log('-=> rmptutor v'+version+' <=-  ['+(new Date(lastUpdate*1000))+']');
        if( ! state.hasOwnProperty('rmptutor') || state.rmptutor.version !== schemaVersion) {
            log(`  > Updating Schema to v${schemaVersion} <`);
            state.rmptutor = {
                version: schemaVersion
            };
        }
    };
    const handleInput = (msg) => {
        if (msg.type !== "api") {
            return;
        }
        let args = msg.content.split(/\s+/);
        switch(args[0]) {
            case '!rmptutor':
                break;
        }
    };
    const registerEventHandlers = () => {
        on('chat:message', handleInput);
    };
    on('ready', () => {
        checkInstall();
        registerEventHandlers();
    });
    return {
        // Public interface here
    };
})();

So I just want to go through here and touch on each section before even attempting to add any of my code. Regarding:

 const version = '0.1.0';
 const lastUpdate = 1531675536;
 const schemaVersion = 0.1;

Does anyone have any references to version numbering practices they follow or any suggestions?

I don't understand what last update is -- maybe days from the Big Bang or something? =) How to calculate it. ?

With respect to schemaVersion are we talking about Roll20.net schema or our own custom structures?

lastupdate is what you get if you type Date.now() in the browser console (and divide by 1,000, IIRC). It's the current time, in the format used in javascript. 

See the log line in checkInstall:

log('-=> rmptutor v'+version+' <=-  ['+(new Date(lastUpdate*1000))+']');

Using Date() with the lastupdate constant will give you the current date. it's handy for checking which script is most recently updated.

I dont divide by 1,000 in mine (and so dont have to multiple by 1000 in the log statement), and just type Date.now() in the browser console whenever i update a script to get the date value to enter in lastUpdate.

The schemaVersion i believe is used for scripts which modify the roll20 State (a special object that persists between sandbox restarts). The state is used for long term variable storage, that you need to be persisitent. But during development you may need to modify the state object's construction. being able to check the version of the state allows you to know how to update the state. This is only needed if you are running the script in multiple campaigns, or you are sharing it with others, so that you can be sure you keep the state object of each version people are using updated properly.

If you aren't using the state, you can delete that.

and version is fairly straightforward. There's no set standard for how you will use version numbering, so the format can be anything. 

G G is pretty much right. 

About Versioning

The standard I try to follow is Semantic Versioning ( https://semver.org/ ).  The basic idea is:

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. PATCH version when you make backwards-compatible bug fixes.

I'm not very good at applying that the "right" way.  What I generally do is bump the PATCH number whenever I fix things, or when I make tweaks to existing thing. If I add big new things, I'll bump the MINOR number (and reset the PATCH to 0).  If I rewrite from scratch, possibly fundamentally changing the script, I'll bump the MAJOR number and reset the other to 0.

I think it's obvious why Versioning is useful, but it's especially useful when you've released scripts for other people to use.  You might join someone's game to help them and find they've got a version from 3 years ago, and that's why the latest features in your script aren't working for them. =D

About Time

lastUpdate is the last time I saved the script.  You mention external editors, and this is one of the reasons I use one!  I've configured my editor of choice (Vim, cuz it's the best. (Shut it, Brian! =D )) to find the lastUpdate variable in any Javascript file I save, and set the current time to it.  Most programming languages store time as an integer number of seconds since "The Epoch".  The Epoch is the "Thursday, January 1, 1970 12:00:00 AM GMT".  (This is why Y2K wasn't as big a deal as the media made it out to be... but watch out for Tuesday, January 19, 2038 3:14:07 AM GMT...)  This integer number of seconds format is usually referred to as a Unix Timestamp.

If you're curious, you can try some conversions at: https://www.epochconverter.com/

Javascript's Date class deals with time in the millisecond resolution, instead of seconds, which is why I multiple by 1000 before converting it to a human readable format.  The Date class is perfectly happy to deal with a text format, so you could just use something human readable:

const lastUpdate = '2018-07-21 9:56:20 am';

/* ... */

log('-=> rmptutor v'+version+' <=-  ['+(new Date(lastUpdate))+']');

 Make sure it's 'YYYY-MM-DD hh:mm:ss Me' so the month and day don't get swapped.

Together with version, lastUpdate provides useful information to the humans using the script:

"-=> TokenMod v0.8.40 <=-  [Tue Jul 17 2018 01:03:56 GMT+0000 (UTC)]"
"-=> TurnMarker v1.3.8 <=-  [Tue Jul 18 2017 20:10:57 GMT+0000 (UTC)]"
"-=> AaronDebug v0.1.0 <=-  [Sun Apr 22 2018 13:54:54 GMT+0000 (UTC)]"
"-=> CharEdit v0.1.1 <=-  [Wed Feb 08 2017 14:13:10 GMT+0000 (UTC)]"
"-=> MoveLog v0.1.0 <=-  [Fri Jun 29 2018 21:45:44 GMT+0000 (UTC)]"
"-=> APISelection v0.1.0 <=-  [Tue Jul 17 2018 02:15:35 GMT+0000 (UTC)]"

About schemaVersion

One of the most important things I did early on was come up with writing a schemaVersion into the state.  Where the above version is meant for humans to understand, the schemaVersion is meant for the script to understand.  As G G alluded to, it doesn't version the script at all, it versions the schema (as in layout, pattern, structure, etc) of the state object itself, more specifically the part of the state that this script deals with.  The checkInstall() function's purpose is to compare the schemaVersion in the script to the one stored in the state, and make adjustments as needed so that the script can function.

The simplest adjustment is just replacing the state with the new format, but you can do much better!  GroupInitiative is a great example of this:

   const checkInstall = function() {    
        log('-=> GroupInitiative v'+version+' <=-  ['+(new Date(lastUpdate*1000))+']');

        if( ! _.has(state,'GroupInitiative') || state.GroupInitiative.version !== schemaVersion) {
            log('  > Updating Schema to v'+schemaVersion+' <');
            switch(state.GroupInitiative && state.GroupInitiative.version) {
                case 0.5:
                    state.GroupInitiative.replaceRoll = false;
                    /* break; // intentional dropthrough */ /* falls through */

                case 0.6:
                    state.GroupInitiative.config = {
                        rollType: state.GroupInitiative.rollType,
                        replaceRoll: state.GroupInitiative.replaceRoll,
                        dieSize: 20,
                        autoOpenInit: true,
                        sortOption: 'Descending'
                    };
                    delete state.GroupInitiative.replaceRoll;
                    delete state.GroupInitiative.rollType;
                    /* break; // intentional dropthrough */ /* falls through */

                case 0.7:
                    state.GroupInitiative.config.announcer = 'Partial';
                    /* break; // intentional dropthrough */ /* falls through */

                case 0.8:
                    state.GroupInitiative.config.diceCount = 1;
                    state.GroupInitiative.config.maxDecimal = 2;
                    /* break; // intentional dropthrough */ /* falls through */
                    
                case 0.9:
                    state.GroupInitiative.config.diceCountAttribute = '';
                    /* break; // intentional dropthrough */ /* falls through */

                case 0.10:
                    if(_.has(state.GroupInitiative.config,'dieCountAttribute')){
                        delete state.GroupInitiative.config.dieCountAttribute;
                        state.GroupInitiative.config.diceCountAttribute = '';
                    }
                    if(_.has(state.GroupInitiative.config,'dieCount')){
                        delete state.GroupInitiative.config.dieCount;
                        state.GroupInitiative.config.diceCount = 1;
                    }
                    /* break; // intentional dropthrough */ /* falls through */

                case 1.0:
                    state.GroupInitiative.savedTurnOrders =[];
                    /* break; // intentional dropthrough */ /* falls through */

                case 'UpdateSchemaVersion':
                    state.GroupInitiative.version = schemaVersion;
                    break;

                default:
                    state.GroupInitiative = {
                        version: schemaVersion,
                        bonusStatGroups: [
                            [
                                {
                                    attribute: 'dexterity'
                                }
                            ]
                        ],
                        savedTurnOrders: [],
                        config: {
                            rollType: 'Individual-Roll',
                            replaceRoll: false,
                            dieSize: 20,
                            diceCount: 1,
                            maxDecimal: 2,
                            diceCountAttribute: '',
                            autoOpenInit: true,
                            sortOption: 'Descending',
                            announcer: 'Partial'
                        }
                    };
                    break;
            }
        }
    };

By using a switch statement with cases that fall through, it picks the point where the stored schema is and applies all the changes necessary to bring it up to the current version.  This is important because someone might have last used the script when the schema version was vastly different, so merely making the changes from "last time" isn't sufficient. 

And all these changes preserve the configuration and running state for the user.  Imagine how annoying it would be if updating the Bump script meant that it lost you color choices for the GM layer and Object layer tokens, and forgot all of the tokens who have been Bump'd!!

Having this schemaVersion concept also frees you up to change bad decisions you made earlier in development.  If you realize that "and array of token ids" isn't sufficient, and you really wanted "a key/value mapping from page id to an array of token ids", you can seamlessly and easily change that. 

Most of the cases in my checkInstall() switch statement correspond to schemaVersion numbers and fall through to the cases below them, but there are two special cases:

• The 'UpdateSchemaVersion' case will only come up when it gets fallen into by the above cases.  It serves 2 purposes: 1) write the current schemaVersion into the state object and 2) mark where the next schema version case should go, right above it.
• The default case is what gets hit when the script has never been installed (or the schemaVersion matches nothing). It writes the full schema to the state.  Be sure when you add a new schemaVersion that you update this object to match what the current schema should be.

That should about cover those 3 lines. =D  What's next?

Thank you gentlemen!

G G says:

If you aren't using the state, you can delete that.

Well I'll definitely do something with it at some point -- if nothing else to explore!

Aaron says:

I've configured my editor of choice (Vim, cuz it's the best. (Shut it, Brian! =D ))... 

That should about cover those 3 lines. =D  What's next?

Heh heh I love the banter! Okay, so for once I believe have a firm grasp on the generous offerings. So no followup questions as to the 3 lines and so moving on. I do want to cover the everything in quite some detail for everyone's benefit. So I'll be asking questions that I think I know the answer to.  At some point though, I'll try to up the challenge level. =)

Let's see what I get right and wrong here starting with the initial statement:

const rmptutor = (()=> {})();

I have stylized the parenthesis so as to be able to discuss them.

It looks like the script is wrapped in the above construction? And thus, anything declared inside of the wrapper is hidden from other scripts?

If so:

What is the purpose of the plain face parenthesis? I assume it is basically evaluate()?

What is the purpose of the bold face parenthesis? I think it's a function in fat arrow syntax

e.g. ()=>{code goes here}

and it is just wrapping the vast bulk of everything into a function? Also, it appears that if you wanted to pass a parameter from another script, the code's structure is already in place, so all you have to do is declare the parameter e.g.

e.g. (par1)=>{code goes here}

What is the purpose of the italicized parenthesis?

Remember that discussion of IIFEs?  =D

The

()=>{} 

is a function in the “fat arrow” syntax  to the left of the => is the argument list, to the right is the function body. If a function takes no arguments, it’s argument list is just (). If a function does nothing, a no-op, it’s function body is just {}.

The next ( ) out allows the implicit assignment (the creation of the function object) to occur before the next set of (), which are the function being executed.

The heart of the Revealing Module Pattern is this creation of a Closure. The “Revealing” aspect is the revealing of a select interface out of that Closure by returning them from the Closure created by executing the IIFE.

The Aaron said:

Remember that discussion of IIFEs?  =D

Yes, in fact, I was hoping I had everything straight from that quite helpful discussion (which I've linked to here). Thank you. When I said, "Let's see what I get right and wrong here starting with the initial statement" I was attempting to pay homage to how far the community has brought me and sort of let folks know that I was reviewing something that I had been taught. I was reviewing information in the form of a question because I am not experienced  enough to speak with any sort of authority. So even when I am pretty sure I have something right, I am reluctant to say 'this' means 'that'.

For example, take my question "What is the purpose of the plain face parenthesis? I assume it is basically evaluate()?" wasn't meant to disregard our earlier discussion but to review it and just double-check I have this conceptualized correctly. Basically, my take away from the other discussion was that the plain-faced parenthetical set -- or the first '(' and it's closing ')' -- was that it was evaluate() within the ordinary rules of precedence with no further purpose. (If you put a variable and the assignment operator in front of that, it returns whatever is being evaluated to said variable.) I believe I understood and fully accepted what you said. My shorthand for that concept is '()' basically means 'evaluate()'. That's probably too simple though because if I understand your response (see below) there is this added nuance in that an object is being created in this particular instance.

Anyway, I apologize if I come across as unappreciative. Nothing could be further from the case.

I just wanted to explain myself here, so please don't feel obliged to respond to what I've said above. On the other hand, if you think there is a better way for me to review and double-check with you and the community that I am following along, please let me know. Thanks.

()=>{} is a function in the “fat arrow” syntax to the left of the => is the argument list, to the right is the function body. If a function takes no arguments, it’s argument list is just (). If a function does nothing, a no-op, it’s function body is just {}.

The next ( ) out allows the implicit assignment (the creation of the function object) to occur before the next set of (), which are the function being executed.

const rmptutor = (()=> {})();

Overall, I would say I do believe I understand this structure, except for the italicized ().

Anyway, thanks Aaron and all. 

No worries at all!  Repetition builds muscle memory. =D

Rewriting that line less tersely yields:

const rmptutorBuilderFunction = () => {};
const rmptutor /* public interface */ = rmptutorBuilderFunction();

When that first line is evaluated, the operations are applied in order of precedence, highest first.  The Fat Arrow functions aren't technically operators, but they do participate in operator precedence (detailed on this page: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions ):

const rmptutorBuilderFunction 
  /* Assignment is precedence 3 */ =
  /* Fat Arrow precedence is >4 and <19 */ () => {}
  ;

So, the function object is created first (precedence >4), and then assignment to the variable (precedence 3). 

In the second line, where it gets executed:

const rmptutor /* public interface */ 
  /* Assignment is precedence 3 */ =
  /* Function Call is precedence 19 */ rmptutorBuilderFunction()
  ;

The function call happens first (precedence 19), and then assignment to the variable (precedence 3).

With the original line, there would be an issue of precedence without clarifying it with grouping.  Here's how that would play out:

const rmptutor /* public interface */
  /* Assignment is precedence 3 */ =
  /* Fat Arrow precedence is >4 and <19 */ ()=> {}
  /* Function Call is precedence 19 */ ()
  ;

In this case, there would be a problem.  The Javascript interpreter would first try to execute the function (precedence 19)... but it hasn't been created yet!  You fix this by grouping:

const rmptutor /* public interface */
  /* Assignment is precedence 3 */ =
  /* Grouping is precedence 20 */ (
    /* Fat Arrow precedence is now effectively >24 and <39 */ ()=> {}
  )
  /* Function Call is precedence 19 */ ()
  ;

Now, because of the grouping, the Function Object is created (precedence >24), then executed (precedence 19), then the result is assigned (precedence 3) to rmptutor.

Speaking of Objects...

In Javascript, everything is an object.  Part of the reason I write functions as:

const foo = function() {};

Is that it's a reminder that it is an object.

Even literal values are objects:

'Foo'.length; /* 3 */
23.5.toFixed(2); /* "23.50" */
1..toExponential(); /* "1e+0" */
(function qux(a){return `qux: ${a}`;}).name; /* "qux" */

(The 1.. Is necessary as the first . will be considered the radix point.  You could write it as (1).toExponential() to avoid that. =D)

I am pretty sure I follow you 98% but I need to bone up on literals.

Also, I accept that I need () for proper precedence and that it is a "Function Call" but that's not how I am used to seeing a function call. e.g.

function myFunction() {}; // what I would call a creating/defining/declaring a function
myFunction(); // what I would call -- the function call

Hmmm... as I understand it -- the rmp template is basically wrapped in a function that calls itself? So is that you only need the () when a function calls itself?

To my recollection I haven't see anything like that in any other language and I didn't see that explained in the link to Mozilla.  

You're almost there. =D  This syntax is a bit peculiar, and you're unlikely to have seen it outside of this instance.  The necessity for the grouping parentheses is just because of the operator precedence issue with Fat Arrow functions ( It only touches on it briefly in that link under the heading "Parsing Order", about 80% down the)

What's being executed is the function that is being defined right there.  Maybe this will help.  Fat Arrow functions are mostly just syntactic sugar for anonymous functions.  These two are basically the same:

const foo = function(){ return 'bar'; };
const foo = () => 'bar';

However, there's no ambiguity with the parsing order with an anonymous function, so this is perfectly valid:

const rmptutor = function(){}();

Traditionally, you'd write that like this:

const rmptutor = (function(){}()); 

or

const rmptutor = (function(){})();

The grouping parentheses are unnecessary in those two, but it was common courtesy to put them in so that a programmer seeing them would recognize "Oh, this is going to be Immediately Invoked at the end. (There was some argument as to whether the function call () belonged inside or outside the Grouping ( ). )

Because of the ambiguity with the Fat Arrow syntax though, you need the Grouping parentheses to allow the function to be constructed before it gets called.

Okay I see why now. Thanks. That was confusing as hell. =D

FWIW I wish the interpreter/language would have used different sytax e.g. 'invoke' or something. LOL.

So the next chunk I'd like to review/cover  is:

const registerEventHandlers = () => {
    on('chat:message', handleInput);
};

I interpret the above code as follows:

const registerEventHandlers = () =>

Indicates to me that this is a function/object. It's assigned name 'registerEventHandlers' indicates to me that within this block you are going to listen for events and then send the event to a specific function based on the type of 'event' that is triggered/heard.

Since we have a fat arrow function here without it ending with the IIFE (), this is an ordinary function being called from elsewhere? That is to say, it's your run-of-the-mill function.

on('chat:message',)

Indicates to me that the event we are looking for is the Roll20 API chat:message event.

on(, handleInput)

Indicates to me that when the chat:message occurs that the handleInput function is called? I don't see anything else being passed to the handleInput function so I'm guessing we got closure and-or the fact that 'all functions are objects in JavaScript' at play here? Also, I am quite fuzzy as to what creates the handleInput object. I would think it would be in the

const handleInput = (msg) => {};

block. But I am not following how the msg parameter is being passed? I think I got something backwards in my head here. =)

No problem, you're mostly right.

registerEventHandlers() is a function who's "one thing" is connecting events to the functions that want to know about them using the Roll20 on() function.  The variable registerEventHandlers gets assigned the function bolded below. 

    const registerEventHandlers = () => {
        on('chat:message', handleInput);
    };

registerEventHandlers is "assigned the function," but if an IIFE was involved it would be "assigned the result of calling the function".  No IIFE in this case.

Generally, you don't want to respond to any events until after the 'ready' event has fired.  If you look below where registerEventHandlers() is declared, you will see an on('ready',()=> ... ) event registration which actually invokes it:

    on('ready', () => {
        checkInstall();
        registerEventHandlers();
    });

This could just as easily be written as:

    on('ready', () => {
        checkInstall();
        on('chat:message', handleInput);
    });

However, functional decomposition allows for easily adding event registration later without cluttering "where we make the decision" with "how we perform the action".

On on()

The syntax for the on() function is:

on( <EVENT IDENTIFIER STRING>, <EVENT HANDLER FUNCTION> );

In the case of the 'ready' EVENT IDENTIFIER STRING above, the EVENT HANDLER FUNCTION is provided inline using a Fat Arrow function.  With the 'chat:message' EVENT IDENTIFIER STRING  we instead pass the variable that represents the function for the EVENT HANDLER FUNCTION. 

In both cases, the value of the second parameter from the function on()'s point of view is a Function Object.  You can imagine on() as looking something like:

const eventMap = {};
const on = (event, func) =>{
  eventMap[event]=eventMap[event]||[];
  eventMap[event].push(func);
};

At some later point, there might be some internal notify(event,data,prev) like this:

const notify = (event, data, prev) => {
  (eventMap[event]||[]).forEach( f => f(data,prev) );
};

You can actually try that out in a REPL, or the API sandbox.

Hopefully that clears up how msg object gets to handleInput().  Separating the event handler function code makes it easy to use the same event handler function with multiple events.

 if an IIFE was involved it would be "assigned the result of calling the function"

Oh, that clear quite a bit up there! Woot!

The syntax for the on() function is:

on( <EVENT IDENTIFIER STRING>, <EVENT HANDLER FUNCTION> );

In the case of the 'ready' EVENT IDENTIFIER STRING above, the EVENT HANDLER FUNCTION is provided inline using a Fat Arrow function.  With the 'chat:message' EVENT IDENTIFIER STRING  we instead pass the variable that represents the function for the EVENT HANDLER FUNCTION. 

The rest of your (Aaron's) explanation is going above my head at the moment, but I think see the purpose of (msg) in 

const handleInput = (msg) => {};

It seems backwards to me, but essentially this enables msg. dot syntax within the handleInput function/object. As for the interrelationship of the functions, I think I should be okay (at least as a starting point) that I can follow the structure provided and this will link an event to an "event-object" (as a laymen's term if nothing else) and then hand that event-object over to a function for processing. I think that will get me started and as I start toying with stuff, hitting other references and other examples, that this will eventually sink in. Or at least I'll have a deeper understanding when I inquire further.

With regard to:

        if (msg.type !== "api") {
            return;
        }

If the object is not equal to "api" do nothing.

With regard to:

        }
        let args = msg.content.split(/\s+/);
        switch(args[0]) {
            case '!rmptutor':
                break;
        }
    };

Seems like you are using a split method here and creating an array -- delimited by /whitespace/ -- then looking at the first element of that array and if that element is not 'rmptutor' then break?

So from there, basically, if you are going to do something with the message, you are probably going to have to familiarize with what args.array looks like (what is in each element) and then do further switch and-or case statements depending upon what you want to do with the chat message?

On handleInput()

So, this might make handleInput clearer.  This is equivalent:

const handleInput = function(msg){
  if('api' !== msg.type) {
    return;
  }
  /* ... */
};

So is this:

const handleInput = function( myFirstParamForMessageObject ){
  if('api' !== myFirstParamForMessageObject.type) {
    return;
  }
  /* ... */
};

let msgCount = 0;
on('chat:message', ()=>{
  log(`Message Events: ${++msgCount}`);
});

'!rmptutor arg1 arg2  arg3         arg4'

['!rmptutor','arg1','arg2','arg3','arg4']

'!rmptutor arg1/ /arg2'

['!rmptutor','arg1/','/arg2']

if(/^!rmptutor$/.test(args[0])){
  /* do a thing */
}

if(/^!rmptutor\b/.test(msg.content)){
  /* do a thing */
}

        switch(args[0]) {
            case '!rmptutor':
                /* do stuff for command */
                break;
            case '!rmptutor-config':
                /* do stuff for config version of command */
                break;
        }

if('!rmptutor' === args[0]) {
   /* do stuff for command */
} else if('!rmptutor-config' === args[0]){
  /* do stuff for config version of command */
}

        switch( args.shift() ) {
            case '!rmptutor':
                /* args is now only the parameters to the command */
                break;
        }

        let whisper = false;
        switch( args.shift() ) {
            case '!wrmptutor': whisper = true;
            case '!rmptutor':
                /* args is now only the parameters to the command */
                sendChat('rmtutor', `${whisper ? '/w gm' : ''} Some output!`);
                break;
        }

Thanks Aaron:

At this point I think I have the template figured out well enough to trace code through it (very roughly but I can now get a general sense of how the rpm structure works), catch events, and drop in or tweek code a bit (especially if I go back here for help on iterating through an object).

For my first test I wanted to checkout the args array in the console. So I updated the tutorial:

const rmptutor = (() => { // eslint-disable-line no-unused-vars
    const version = '0.1.0';
    const lastUpdate = 1531675536;
    const schemaVersion = 0.1;
    const checkInstall = () =>  {
        log('-=> rmptutor v'+version+' <=-  ['+(new Date(lastUpdate*1000))+']');
        if( ! state.hasOwnProperty('rmptutor') || state.rmptutor.version !== schemaVersion) {
            log(`  > Updating Schema to v${schemaVersion} <`);
            state.rmptutor = {
                version: schemaVersion
            };
        }
    };
    const handleInput = (msg) => {
        if (msg.type !== "api") {
            return;
        }
        let args = msg.content.split(/\s+/);
        switch(args[0]) {
            case '!rmptutor':
                log(args); /* <= HERE IS THE ONLY CHANGE */
                break;
        }
    };
    const registerEventHandlers = () => {
        on('chat:message', handleInput);
    };
    on('ready', () => {
        checkInstall();
        registerEventHandlers();
    });
    return {
        // Public interface here
    };
})();

And I went into the game and just typed in chat "!rmptutor teach me something" and you'll never guess what happened?

["!rmptutor","taught","me","something!"]

LOL. Thanks a ton Aaron and Others! I think I am ready to start breaking my campaign now... err I mean add some scripts to it. I'll try to find a script to work from and-or a thread dealing with what I want for my campaign rather than continuing the discussion here. 

Ha!  Change that line to :

log(args.map(w=>/^t/.test(w)?'taught':(/g$/.test(w)?`${w}!`:w)));

and

!rmptutor teach me something

really will

["!rmptutor","taught","me","something!"]

=D

LOL I don't know how that is going to work but I bet I know what it is going to do...

YEP!

=D