2547techno/feature/json format arg (initial commands)

[2547techno]

For a start, the JSON output format param has been added to the 3 commands $ping, $slots, and $randommeme.

The reason for only 3 is because the other popular commands need either API keys set up or new tables in the DB which are not documented (ie. the init-database does not setup tables for randomline)

The general format for JSON formatted output is:

{
    "raw": "raw output that would be returned without format:json",
    "parsed": {
        "foo": "bar"
    }
}

Until I'm able to set up all the proper tables and API tokens locally, I won't be able to test the JSON format param for most of the other popular commands. Maybe a revision of the init-database script is needed.

Any feedback is welcome :)

Examples

$slots

$slots format:json a b c

{
    "raw": "[ a c b ] ",
    "parsed": {
        "rolledItems": ["a","c","b"],
        "win":false 
    }
}

$slots format:json a a a

{
    "raw": "[ a a a ] FeelsDankMan You won and beat the odds of 100%.",
    "parsed": {
        "rolledItems": ["a","a","a"],
        "chance": 100 
        "win": true
    }
}

$slots format:json a a a a a a a a a a a a ab (cannot test locally because it requires an undocumented table to store winners)

{
    "raw": "[ a a a ] PagChomp A flush! Congratulations, you beat the odds of 78.653% (that is 1 in 1.271)",
    "parsed": {
        "rolledItems": ["a","a","a"],
        "chance": 78.653 
        "win": true
    }
}

$ping

$ping format:json

{
  "raw": "Pong! Uptime: 8m, 36s; Temperature: N/A; Free memory: 1 GB/2 GB; CPU usage: No stats available; Commands used: 3; Redis: 7 keys; Banphrase API: Not connected; Latency to TMI: 56ms",
  "parsed": {
    "Uptime": "8m, 36s",
    "Temperature": "N/A",
    "Free memory": "1 GB/2 GB",
    "CPU usage": "No stats available",
    "Commands used": 3,
    "Redis": "7 keys",
    "Banphrase API": "Not connected",
    "Latency to TMI": "56ms"
  }
}

$randommeme

$randommeme format:json twitch

{
    "raw": " r/Twitch: Why are my classic twitch emotes monkeys? https://www.reddit.com/gallery/xazmcm (Score: 1, posted 7h, 57m ago) ",
    "parsed": {
        "quarantine": false,
        "fourmName": "Twitch",
        "post": {
            "author": "TheOnlyCanadianEver",
            "created": "2022-09-10T20:47:17.000Z",
            "id": "xazmcm",
            "title": "Why are my classic twitch emotes monkeys?",
            "url": "https://www.reddit.com/gallery/xazmcm",
            "commentsUrl": "r/Twitch/comments/xazmcm",
            "flairs": [
                "Question"
            ],
            "crosspostOrigin": null,
            "isTextPost": false,
            "nsfw": false,
            "stickied": false,
            "score": 1
        }
    }
}

[Supinic]

Two major things to consider:

• If we would go with the parameters route, then every single command would end up having a format parameter, which is not ideal. Also, this would conflict with commands that already have a parameter with the same name. Therefore, a different solution needs to be found.
• The reply object should just contain all the raw data along with the reply, ideally wrapped in some sort of property (raw could work, maybe some other name as well). Then, the command module in supi-core would be in charge of relaying this data further

[2547techno]

Then, the command module in supi-core would be in charge of relaying this data further

How would one indicate which format to return as then? Maybe if a command is able to return a parsed output and is piped into $js, it will choose to use the parsed reply rather than the text reply as the piped value.

For example:
$pipe ping | js function:"args[0]"

{ "Uptime": "8m, 36s", "Temperature": "N/A", "Free memory": "1 GB/2 GB", "CPU usage": "No stats available", "Commands used": 3, "Redis": "7 keys", "Banphrase API": "Not connected", "Latency to TMI": "56ms" }

and then

$pipe ping | abb say / $ping

Pong! Uptime: 8m, 36s; Temperature: N/A; Free memory: 1 GB/2 GB; CPU usage: No stats available; Commands used: 3; Redis: 7 keys; Banphrase API: Not connected; Latency to TMI: 56ms

Is this something that is possible?

[2547techno]

The returned object now has the original reply field which is the raw return text as well as parsed for the parsed data.

Maybe an option is to have a new abb command, maybe abb json, that will try and return the parsed field in the piped input if available (could error out if field is not present)

ie.
normal:
$pipe ping | abb tee | js function:"tee[0]" -> "Pong ... "
parsed:
$pipe ping | abb json | abb tee | js function:"tee[0]" -> "{'foo':'bar'}"

[2547techno]

Or instead of adding to the abb command, a new command can be made so the pipe flag can be applied, making sure the command is only used in a pipe.

Seems the pipe flag does not work, the $% command has the pipe flag but can be run outside a pipe

[2547techno]

Solution added:

Added _parsed param in $pipe command that indicates whether or not to use an available parsed field as the input to the next piped command. If the _parsed param is true and a command does not return a parsed field, the normal reply field is used.

Example:

No parsed value available:
$pipe _parsed:true rkwq | abb say ->

Ma$e is one of my favorite rappers and I based a lot of my flows off of him

Parsed value available:
$pipe _parsed:true ping | abb say ->

{"Uptime":"49.83s","Temperature":"N/A","Free memory":"607 MB/2 GB","CPU usage":"rising sharply","Commands used":8,"Redis":"4 keys","Banphrase API":"Not connected","Latency to TMI":"56ms"}

[2547techno]

Just need feedback on if this is a direction we can go

[Supinic]

I like the direction - where each command that supports this kind of functionality has another property returned along with the string response (currently named .reply) in the result object.

I don't think running JSON.stringify is necessary at all in the command context. The command module can manage this just fine. The Command.checkAndExecute could be adjusted so it returns this as part of the result object. Then, the meta commands (I'm mostly thinking of $js, maybe $abb if users request it) can be updated so they can publish this data to the user.

If a command does not support this, it would just be handled via some sort of command flag, so that the meta command doesn't need to run the command and then figure it can't work with the pure data result.

[2547techno]

I don't think running JSON.stringify is necessary at all in the command context. The command module can manage this just fine. The Command.checkAndExecute could be adjusted so it returns this as part of the result object. Then, the meta commands (I'm mostly thinking of $js, maybe $abb if users request it) can be updated so they can publish this data to the user.

See comment above above about the changes to the pipe command for the reason for using JSON.stringify. Since JSONifying the command output is only ever going to be used meaningfully in a pipe, there is no need to make changes to supi-core. If in the future this is something we want to change, we can, but I feel like for the current use case modifying the pipe command to have the option of using JSON output if available when executing each command in the pipe is a good solution without needing to touch core parts of the codebase.

[Supinic]

Discussed on stream with @2547techno
TL;DR - keep object-based data, sb.Command lets it pass anyway; find a good name for the object property, and maybe design preliminary support for meta-commands