FFI bindings/API for DOMTokenList interface

[mstksg]

Thanks for the great library! Just adding FFI bindings for the DOM's set-of-strings object, mostly used for dealing with classes of an element -- https://dom.spec.whatwg.org/#interface-domtokenlist

Added some documentation, but I was unsure about some design decisions, because I'm not really too familiar with purescript. Most of the functions throw a runtime error if invalid strings are passed. Should I be adding an Error row to the returned Eff, or catch the error in the FFI and return it as a Bool indicating whether or not things were successful? What is the normal protocol here?

[garyb]

Thanks for this, I got lazy and didn't get around to implementing this interface in my last batch of changes 😄

Yeah, perhaps we could add err :: EXCEPTION (https://github.com/purescript/purescript-exceptions) to the effect rows where needed... I think there are probably other functions in the library already that can throw and don't have the exception effect, so DOM kinda implies it might throw, but having it explicit is definitely preferrable.

[mstksg]

ah, it looks like something like that would be a full-library sort of edit, right? is the commit as it is already conforming with how the library chooses to handle errors?

[garyb]

Ah sorry, I was just suggesting we add them here, not throughout the library. I'd like to make the change at some point, but we may as well start somewhere!

[mstksg]

Ah, okay. In that case, there are three types of exceptions from the DOM's TokenList interface:

1. SyntaxError, thrown if someone tries to pass in an empty string token
2. InvalidCharacterError, thrown if someone tries to pass in a token with any whitespace
3. TypeError, which is thrown when supports is called on a DOMTokenList does not have a list of supported names.

I'm having some trouble thinking about which ones should be handled through normal channels (result value) and which ones should be handled by the runtime exception system. Do you have any opinions on the matter?

I actually also don't even understand when supports wouldn't throw TypeError, because I am not sure how to acquire a DOMTokenList that has a supported names list defined...but, maybe TypeError could be something that would make sense to absorb into a Nothing result, to make supports return Maybe Bool ?

[garyb]

Sorry I let this languish. I'd squash them all into the runtime exception effect - that is probably most in line with the goal of this library being as unonpinionated as is practical and still useful. The error can still be caught and then handled in PS code if someone wanted to make an abstraction on top of these low level bindings.

It's definitely tempting to do something about supports though, as its behaviour seems to be pretty weird... but if it is working as per the spec, then I guess it's fine that it probably always excepts too.