Text-based editing

Feature Suggestions
1

While Inventor is amazing, I sometimes feel limited by the block system. I don’t want to jump away from Inventor to something like Discord.js, but I also would like to be able to use text based editing. Solution? Add text-based editing to Inventor :grin:

The entirety of the platform would stay the same, but instead of the flow editor being blocks, it would be text based code. (The trigger would still have a gui for editing stuff though) This would allow easy copying of code into the support chat, other bots, or other flows. It would also pair nicely with my suggestion to Add Git features. This would, as with Add Git features, require a lot of work to create a programming language basically from scratch, but I think it could attract more people who are either “embarrassed” by using block based programming or are limited by it like I am. This would also probably be locked away in the settings.

2

This is already planned and a prototype exists.

The end-goal is for flows to be able to seamlessly be changed from “block mode” to “text mode” and back, without any loss in data (except formatting). This would have all the benefits you described, with the primary one being the ability to move code between flows.

There’s a some problems with this sort of conversion but it’s definitely possible. For example, variables are currently referenced by block ID, so we need to either procedurally generate variable names for blocks without tags or force all blocks to have tags/names. Block tags also currently allow spaces which can be difficult for parsers.

The language/syntax will be custom (probably JS-like) but since you’ll be able to see what blocks generate, it shouldn’t be too tricky to learn. Before release, we’ll have proper autocomplete hints for filling in block names, etc.

1 Like
3

What if it worked kind of like object destructuring:

[null, theMessage] inventor.string.split_string_list(string=hey/hello world!,delimiter=/)
[newChannelID, channelMakingError] discord.channels.createChannel(name=greeting,serverID=123)
[mostRecentMessageID, messageSendingError] discord.messages.createMessages(message=theMessage, channelId=newChannelID)
// hello world!

You could choose arbitrary names for each input you need. To skip over an input, just put null. To convert this to blocks just figure out what input each used variable is from and replace it with the block version. Actually, this could work nicely with a new feature for “Output Nicknames”, which would be given to an output and would transfer to the text. In order to convert a non-nicknamed block to text, it could use this: blockID-defaultOutputName. This would make sure there’s no duplicates.

5

The current plan is to use go-style syntax so this feature can take advantage of the AST parser built into the go standard library (ast package - go/ast - Go Packages), and for syntax highlighting on the frontend without needing to fully make a new language definition.

This is the current rough version:


trigger := SlashCommand{
    CommandName: "example",
    Subcommand: "example",
    ...
}

reply := interaction.TextReplyToInteraction{
    Content: "Hello there, <@" + trigger.ExecutingUserID + ">!",
    Ephemeral: true,
}

Ideally the final version would support a form of tab autocomplete where, once you pick a block from the list, it fully populates all of the available options for that block.

The goal of the text based system is for the text to never actually be stored - saving the text representation will result in a conversion process back to blocks, and opening the text representation will cause the text version of the blocks in your flow to be generated. The text is an “interface” in the same way the block list is, but the blocks remain the source of truth.

6

That seems a bit more cumbersome to type out (since you have to type the block name and the full output name), but that makes sense. Looking forward to it!

7

This is a massive feature even with an existing parser to lean on, without it I don’t know if it would be feasible to build at all.

While forcing a autocomplete-based workflow (where you use autocomplete to fill in all the struct fields) isn’t ideal, it makes the resulting code much more readable to people who haven’t memorized the inputs and outputs (and input and output orders) of hundreds of blocks. Since we’re expecting to mostly have new programmers using this feature, prioritizing readability is worthwhile.

8

Oops, I managed to overwrite my last post :expressionless:

Any chance we get something like this for inputting parameters?

getParams := databases.GetRow{
   RowID: 123
}

reply := interaction.TextReplyToInteraction{
   ...getParams
}
9

In that example, any outputs of getParams that are also inputs of the reply block would be populated?

Probably not since there’s no way to display this in the flow UI and I could see it being confusing. I also don’t believe go supports that syntax natively in structs.

10

Yeah, essentially what the Spread operator is in JS.

That would definitely be confusing in the flow UI though, I forgot about that lol