HTML DOM Representation

[DavePearce]

(@altmattr --- this may also be of interest to you)

My initial efforts to represent the DOM in Whiley have provided some interesting observations. Firstly, we need some way to interact natively with the DOM (see #41). Secondly, the DOM has an inbuilt concept of a union type. For example, here is an abridged version of the Node interface:

public type Node is &{
    int nodeType,
    js_string nodeName,
    (null | Element) parent,
    Node[] childNodes,
    ...
}

From this, we can see two interesting things: js_string and null | Element.

Both of these pose interesting questions. At this stage, I've just modelled a js_string using an int because this give me a sensible (if not slightly broken) translation. Likewise, at this stage, the union type null | Element is modelled correctly because we are not using tagged unions. However, as soon as we employ tagged unions (which is my current plan) this will break.

Perhaps one other interesting thing is that there is a clear notion of inheritance between the Node interface and the Element interface. Currently, Whiley provides no support for capturing this.

[DavePearce]

One possible solution here is to support a concept of an untagged or raw union. This is something I've thought about before. The syntax would be: (null || Element). In principle, this should only happen between record types which have a common initial sequence. But, that doesn't work for (null || Element) anyways. Hmmmmmmmmmm

[DavePearce]

The other option, of course, is just to accept that we have to have a shim around the DOM to enable interaction from Whiley. That could work, but would add some overhead. Potentially in many cases this could be circumvented.

[altmattr]

Yep, I would suggest that approach. If you are taking the elm approach then you are in whiley-land the whole time until you inspect the dom to update it - so the cost won't be too bad. matt

…

________________________________ From: David Pearce <[email protected]> Sent: Friday, 23 August 2019 1:18 PM To: Whiley/Whiley2JavaScript <[email protected]> Cc: Matthew Roberts <[email protected]>; Mention <[email protected]> Subject: Re: [Whiley/Whiley2JavaScript] HTML DOM Representation (#42) The other option, of course, is just to accept that we have to have a shim around the DOM to enable interaction from Whiley. That could work, but would add some overhead. Potentially in many cases this could be circumvented. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#42?email_source=notifications&email_token=AAMQFYLGHBLMUGMVDZ2ISR3QF5JIXA5CNFSM4IOZUWCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD47AACY#issuecomment-524156939>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAMQFYISWQ5M4LTHEFPRH3DQF5JIXANCNFSM4IOZUWCA>.

[DavePearce]

Well, yes, but then in Elm land you are stuck to a specific model. Whereas if we can represent the actual DOM somehow, then we can interact with it and choose our own models.

Still, even having a shim around the DOM ... I'm not sure how that would work. I can do it using the virtual DOM approach of Elm, but I don't know how to enable more direct access.

[altmattr]

I'll continue my experiments and keep bugging you when I find problems then 🙂 matt

…

________________________________ From: David Pearce <[email protected]> Sent: Friday, 23 August 2019 1:37 PM To: Whiley/Whiley2JavaScript <[email protected]> Cc: Matthew Roberts <[email protected]>; Mention <[email protected]> Subject: Re: [Whiley/Whiley2JavaScript] HTML DOM Representation (#42) Well, yes, but then in Elm land you are stuck to a specific model. Whereas if we can represent the actual DOM somehow, then we can interact with it and choose our own models. Still, even having a shim around the DOM ... I'm not sure how that would work. I can do it using the virtual DOM approach of Elm, but I don't know how to enable more direct access. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#42?email_source=notifications&email_token=AAMQFYN5KXPRGNHTMASKS3DQF5LRFA5CNFSM4IOZUWCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD47AZHI#issuecomment-524160157>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAMQFYNP7MADCOBXUUOAJ6DQF5LRFANCNFSM4IOZUWCA>.

[DavePearce]

Ok, maybe I could figure this out using a native type. Maybe I should have a go and see if I can do that. Currently fighting with various minor problems in the compiler in an effort to get an actual single-page app working :(

[DavePearce]

Also, I thought you were against the Elm approach??

[altmattr]

My attitude is that models like this are wonderful, and far too restrictive for real web developers. If you want to build an impressive system, then the elm approach will serve you well. If you are pitching to real web developers then you will find them building more and more elaborate ways to get around the fact that you have not given them direct access to the DOM. I don't mean the _real_ DOM though, the whiley-land equivalent of the DOM is fine. So, it is my dual-personality that is showing. Functional programmer by day (who loves an elegant model), writer of real-world applications by night (who owns more spaghetti-code than he cares to admit)🙂

…

________________________________ From: David Pearce <[email protected]> Sent: Friday, 23 August 2019 1:49 PM To: Whiley/Whiley2JavaScript <[email protected]> Cc: Matthew Roberts <[email protected]>; Mention <[email protected]> Subject: Re: [Whiley/Whiley2JavaScript] HTML DOM Representation (#42) Also, I thought you were against the Elm approach?? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#42?email_source=notifications&email_token=AAMQFYNEVEIDFBCUT3WFSQ3QF5M4FA5CNFSM4IOZUWCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD47BHRY#issuecomment-524161991>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAMQFYKMEB7ZDEHISQCXVZLQF5M4FANCNFSM4IOZUWCA>.