Mind blown. If you haven’t had a look at the ThoughtAsylum action group, I’d suggest you check it out. Ridiculous number of really quite useful actions.
Between this, @mattgemmell’s MGCheckListPrompt and the recent updates for cross-linking, my excitement for what Drafts is capable of continues to grow.
Hats off to @sylumer for some outstanding, detailed work on this one. Deep gratitude.
+42 for that
Really great library!
For what it’s worth, there was another update published earlier today and I’ve been working this evening on porting in yet more functions and actions I have lurking in various personal action groups.
While the action group is certainly intended to be useful in its own right, I’m hoping that it will be the tip of the iceberg for a good many Drafts users. I think including the underlying script library in your own actions and building your own personalised actions offers up real potential in terms of accelerating how quickly you can build them, and perhaps giving some inspiration as to what could be done with them.
If you have the ThoughtAsylum action group, you can use an “Include Action” as your first step and set the action to be “TAD”. If you look at the actions in the ThoughtAsylum action group, you’ll see a large proportion of them do exactly this.
All of the classes, functions, etc. are all fully documented on their own web site in the same sort of style as Drafts’ own scripting documentation, and include simple examples.
Wow @sylumer how on earth did you create that massive amount of functions?
I would be really interested in your workflow of creating the library.
Did you use Drafts as Editor for JavaScript?
I did a tag sweep - rename and delete yesterday and the faster processing time is thanks to your work.
I still have to dig much deeper…
So many nuggets to find
Well I joined the Drafts 5 iOS beta in Q1 2018, so they didn’t just spring up overnight. Effectively what I did was start creating stuff right at the beginning, and at a much slower rate, I started bringing stuff together to share with people. And it took me years to get to the point where I was happy to share it. I have a family, a day job, and many other voluntary commitments besides, so finding the time to do what is arguably the least interesting aspect of this has taken me quite a while 
But hopefully I’ll just be able to keep trickling additions (new stuff, fixes and updates for the docs and the code) out for it every so often and it’ll just keep getting easier to do as I automate more of the process. Which I guess brings me to your next point.
Okay. I’m not sure how many others might be interested in that sort of thing, but here’s peak behind the curtain.
The code that I work with for the library is held in a number of separate JavaScript files. It allows me to work on multiple files in parallel with ease. There’s one file for each class. These files can be referenced separately for run purposes, but I have a shell script that builds a single library file (the one that is distributed) that takes less than a second to run on my Mac, and I have it tied to one of my Elgato Stream Deck profiles so it is a button away.
Details:
There is an option for a mode in the TAD action of the ThoughtAsylum action group that you’ll see explained in the initial script comment. The default is FILE where the library is included by loading in a single library file. ACTION will load it from the TAD-Library action which is an inbuilt version of the library and may produce slightly faster execution in my experiments, but on a well-specified device you’ll likely see no practical difference to FILE. The last option is DEV, and this is where the action will try and load in the class JavaScript from separate development files. Chances are that no one but me will ever use that option as no one else will be working with those separate files, just the full one.
In terms of generating the documentation, alongside the JavaScript files I have created TypeScript definition files. I then use TypeDoc with a custom theme and some shell scripted extras to generate the library site itself. Again this is tied to a button on a profile on my Stream Deck and takes probably 5-8 seconds to run.
In addition there is another shell script that combines the separate definition files into a single one for distribution; you can use definition files to support code intelligence features in several editors. It’s just the same approach as the one offered for Drafts. Again, I can generate the file at a touch of a button and it takes less than second.
Of course I also have a ‘master button’ that will run all three shell scripts (via a fourth shell script) in succession.
Additional automated aspects of the entire library/action group combined workflow (they tend to go hand-in-hand) are included in the action group for the action group. One of the actions can generate a set of Markdown-based documentation of an action group based on the content of a share URL (that’s the other one to the Action Directory URL). I use that to populate the browsable list of actions. Another action when run can dynamically recreate and offer to install the TAD-Library action from the local copy of the library file. No one apart from me should every need to run that, but due to the size of the library, it takes what was previously a job that could take several minutes and has been known to freeze and crash Drafts, and condenses it to just a few seconds.
Action group updates are pushed out via Drafts’ own inbuilt update mechanism. It really couldn’t be simpler. the library web site, including source files, etc. is managed via GitHub, so I from my local repository I just commit and push the relevant files to get that update out. The browsable actions list page is on my main web site, but follows the same process.
Yes as you would expect. But also yes as you might not expect and no.
I create script steps whenever I find the need. Sometimes this is on my iPhone. Sometimes it is on my iPad. Sometimes it is on my Mac. I’ve also been working on this for years, so I’ve focused on different methods at different times. All but the editing code in the script step, I utilise the actions in the ‘Scripting’ section of the ThoughtAsylum action group for. So the chances are if you’ve tried these out, you’ve already been working on scripts in a very similar way.
My push this year in getting things pulled together and the documentation tested alongside has found me more often than not at my Mac. When I’m on my Mac, I use VS Code (which supports Typescript definition files) to edit my Drafts JavaScript (though Sublime Text remains my daily driver in terms of text editing). I save my test code to a tad-test.js file. If you read the test libraries section of this post, you’ll get the idea why 
When on my iPhone/iPad, if I’m just working with script then I tend to develop the script in a draft (see the executing from drafts section in that same post), though occasionally I might work in Textastic on the tad-test.js files if I’ve been splitting my work across platforms.
If the work involves other action steps, then I switch to working on script editing within the script editor, though I’ll often flesh out a proof-of-concept using one of the other methods first.
Occasionally I will have multiple test library files the go at once if I’m creating an additional class. But these are easily added in, and this is once again explained in the Drafts: Script development post.
Glad you found some use in it. 
Hi,
I see two years of continues work could build this great action group. Still I love your work.
Most importantly:
Did you consider the require( tad.js ) option?
If by “did you consider” you mean “did you use”, then yes. That’s exactly what the FILE option does.
You’ll also see various uses elsewhere. For example in the DEV option right after it.
Shame on me.
I really have to look deeper in to your code.
