I'm inclined to just build this in the same fashion as BodyDOMSource and DocumentDOMSource, but I want to listen to other suggestions and criticisms to this proposal, in case we are missing something.

E.g. do we want to allow domSource.select('window').events('message') or forbid it? (on the other hand it's hard to forbid bad practices in JavaScript anyway)

@TylorS @Widdershin ?

You mean that domSource.select('window') will not be affected by isolation?

It won't, just like domSource.select('document') and domSource.select('body') aren't.

👍 from me. I actually thought that was done already 😄

I'm fine with this as well 😄 can't see any glaring issues, will still be fine for testing. Just want to make sure it works with mockDOMSource.

Thanks guys. 👍
And good point about mockDOMSource.

What's the recommended way to track window dimensions before this issue resolves?

My recommendation is to make a driver:

import fromEvent from 'xstream/extra/fromEvent';

function windowSize () {
  return {
    width: window.innerWidth,
    height: window.innerHeight
  }
}

function resizeDriver () {
  return fromEvent(window, 'resize')
    .map(windowSize)
    .startWith(windowSize())
    .remember();
}

I think window is really outside of DOM (which is Document Object Model) context. There is probably a need in official window driver that will also be able to produce some actions like opening/handling child windows, etc.

Yeah window is generally considered part of the Browser Object Model, BOM, not the DOM.there is no BOM standard but all browsers support window (and history). Window is also the global context for javascript running in the Browser.

I just create my own driver but we should really have an 'official' off the shelf story.

My preference is another driver or the special selectors mentioned above.

Hmm, I think I agree with @whitecolor. It's good if we define the boundaries of each library, so we don't end up with monoliths that do many things. Some time ago we moved out the HTML driver from cycle/dom, which was a good move, and was also @whitecolor's idea. When it comes to cycle/dom, I think a good purpose/scope for it is "it read/writes DOM Nodes", where "reads" concerns both DOM Nodes and events coming from DOM Nodes, and "writes" happens by managing VNodes.

I just create my own driver but we should really have an 'official' off the shelf story.

As in many cases, it's best to first build it as non-official, then (maybe) officialize it. That has been the approach so far with cycle/history, cycle/time, (not yet, perhaps soon) cycle-onionify, etc.

I just create my own driver but we should really have an 'official' off the shelf story.

As in many cases, it's best to first build it as non-official, then (maybe) officialize it.

I've problem with that approach as the route to having one :) As long as devs can easily find the 'unoffical' one. I guess, without it seeming to be official :)

Has there been any progress on a window driver?

My use-case is keeping track of the window focus state. I'm currently going around the driver and listening directly on window (yes, impure and hairy :( )

const isFocused$ = O.merge(O.fromEvent(window, 'focus').mapTo(true)
                         , O.fromEvent(window, 'blur' ).mapTo(false)))

FWIW, I personally think that special-casing window in the same manner as document and body is a reasonable approach, even if its not technically part of the DOM. We already have to deal with non-isolation anyway, so this doesn't radically change anything.

@shesek no, I havent gotten to that yet. But you can just put those two window events in a driver of your own for the time being

Yeah it seems like a small driver can take care of this. Moreover, I think we should limit the DOM driver to only the DOM elements and DOM events. There are many more browser related APIs but those can have their own drivers. Even HTML rendering was moved out of the DOM driver, into HTML driver.

@issuehuntfest has funded $40.00 to this issue. See it on IssueHunt