Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×

Another Attempt At Typescript API Work...

I see there have been a few stabs at getting typescript working well with the Roll20API -- here's another one. <a href="https://github.com/jmhnilbog/Roll20Sandbox" rel="nofollow">https://github.com/jmhnilbog/Roll20Sandbox</a> Goals: Test locally. Debugging in the API console is something I want to avoid. Easy compatibility with the all the other scripts flying around. Intellisense. Never have to hunt down a rogue "rollableTable" when I meant "rollabletable", and never have to look up what the heck keys exist on which kinds of Roll20Objects. To those ends, there's code in here to create a sandbox object with the same interface as the top level scope in the Roll20Api sandbox model, tons of optional logging, and commands to build output files and run mocha/chai tests locally against your code. Now, I haven't actually DONE a crazy amount of work with the API, because the cut/paste/pray development cycle drives me bonkers and I wanted to get this in place before going all-in. I would love some feedback.
1617049591
timmaugh
Roll20 Production Team
API Scripter
Ooh... I'll have to look at this later. I had thought to mock up something in a JSFiddle that people could fork, but this could be so much better.
Thanks! My biggest issue with building stuff for Roll20 is currently my confusion about what level of escaping is required for various tasks, and just the constant string manipulation. I would like to end up with some easy-to-use 'primitives' on top of macros and such to handle all that stuff automatically. It seems like with Typescript involved, we could at least brand our strings in order to keep them distinct. It's easier to deal with type RollTemplate = Brand&lt;string, "rolltemplate"&gt; type KeyValuePairString = Brand&lt;string, "keyvaluepairstring"&gt; type WeirdThingEncodedWeirdlyAsString = Brand&lt;string, "weirdthing"&gt; and putting together a set of functions to convert/encode between those instead of having everything being a blob. The code I threw up already manages to enforce typing on the subtypes of Roll20Object, which is pretty great. ```