Bindings for IntersectionObserver

[illusionalsagacity]

ported over from reasonml-community/bs-webapi-incubator#197

Have a few questions on this one:

• should we continue doing the functions for properties? Personally I kinda like the potential for sharing the Dom phantom types for inter-library compatibility
• Using makeX named parameter constructor functions, vs the new @obj on records for next rescript release.

[TheSpyder]

This seems fine, I'm not familiar with the intersection observer API so it's hard to comment on the correctness of the bindings directly.

should we continue doing the functions for properties? Personally I kinda like the potential for sharing the Dom phantom types for inter-library compatibility

yes. I speculated about this in #2, and discussed it on the reasonml discord, for the moment consensus is that the webapi should maintain compatibility with other code that uses Dom types.

Using makeX named parameter constructor functions, vs the new @obj on records for next rescript release

I haven't heard about this, where was it announced? I just found the compiler changes, that looks cool.

Unfortunately I don't think it's appropriate for this library to use new compiler features that quickly - not everyone upgrades immediately. If we haven't released 1.0 by ~6 months after rescript 10, then I'll consider it as a breaking change.

[illusionalsagacity]

This seems fine, I'm not familiar with the intersection observer API so it's hard to comment on the correctness of the bindings directly.

If I remember correctly I was testing this via the test file in an html doc in a browser. Might be something to address elsewhere as well?

yes. I speculated about this in #2, and discussed it on the reasonml discord, for the moment consensus is that the webapi should maintain compatibility with other code that uses Dom types.

Yeah I think the only downside here is bs-webapi-incubator wasn't using the Dom phantom types comprehensively, but maybe that would be worth doing prior to 1.0 for this library?

I haven't heard about this, where was it announced? I just found the compiler changes, that looks cool.

Unfortunately I don't think it's appropriate for this library to use new compiler features that quickly - not everyone upgrades immediately. If we haven't released 1.0 by ~6 months after rescript 10, then I'll consider it as a breaking change.

Yeah it was a little buried but it was in here https://forum.rescript-lang.org/t/rfc-more-general-type-checking-for-structural-typings/1485/51

[TheSpyder]

This seems fine, I'm not familiar with the intersection observer API so it's hard to comment on the correctness of the bindings directly.

If I remember correctly I was testing this via the test file in an html doc in a browser. Might be something to address elsewhere as well?

Better testing would indeed be awesome. Even if it's just cypress or something using headless chrome, at least it will be some sort of browser verification. It's not on the roadmap at this stage.

yes. I speculated about this in #2, and discussed it on the reasonml discord, for the moment consensus is that the webapi should maintain compatibility with other code that uses Dom types.

Yeah I think the only downside here is bs-webapi-incubator wasn't using the Dom phantom types comprehensively, but maybe that would be worth doing prior to 1.0 for this library?

bs-webapi definitely did use the BuckleScript (now ReScript) Dom types, where they were available. We haven't changed that (and I don't think we're really likely to).

I haven't heard about this, where was it announced? I just found the compiler changes, that looks cool.
Unfortunately I don't think it's appropriate for this library to use new compiler features that quickly - not everyone upgrades immediately. If we haven't released 1.0 by ~6 months after rescript 10, then I'll consider it as a breaking change.

Yeah it was a little buried but it was in here https://forum.rescript-lang.org/t/rfc-more-general-type-checking-for-structural-typings/1485/51

thanks for the link!

[TheSpyder]

Published 0.1.2

[TheSpyder]

I've just remembered a good reason to keep the files separate - tree shaking. Tree shaking can remove top-level functions but not nested module definitions (because there's no good system to mark them as pure).

Having said that, with intersection observer (and resize observer) it's not really possible to use the parent module without the sub module - so it shouldn't make much difference.