Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Read window events through some driver #568

Open
jvanbruegge opened this issue Mar 28, 2017 · 16 comments

Comments

@jvanbruegge
Copy link
Member

commented Mar 28, 2017

Certain events, like the mouse leaving the browser window, can only be captured on the window, see here

Therefore it would be convenient if you could do:

domSource.select('window').events('mouseup')

This would help to resolve cyclejs-community/cyclejs-sortable#12

@staltz

This comment has been minimized.

Copy link
Member

commented Mar 28, 2017

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 ?

@mightyiam

This comment has been minimized.

Copy link

commented Mar 28, 2017

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

@staltz

This comment has been minimized.

Copy link
Member

commented Mar 28, 2017

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

@TylorS

This comment has been minimized.

Copy link
Member

commented Mar 28, 2017

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

@Widdershin

This comment has been minimized.

Copy link
Member

commented Mar 28, 2017

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.

@staltz

This comment has been minimized.

Copy link
Member

commented Mar 29, 2017

Thanks guys. 👍
And good point about mockDOMSource.

@Hypnosphi

This comment has been minimized.

Copy link
Contributor

commented Apr 9, 2017

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

@Widdershin

This comment has been minimized.

Copy link
Member

commented Apr 9, 2017

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();
}

@staltz staltz added the help wanted label Apr 23, 2017

@jvanbruegge jvanbruegge added this to To do in the next weeks in jvanbruegge's pipeline Oct 3, 2017

@whitecolor

This comment has been minimized.

Copy link
Contributor

commented Oct 7, 2017

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.

@SteveALee

This comment has been minimized.

Copy link
Contributor

commented Oct 7, 2017

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.

@staltz

This comment has been minimized.

Copy link
Member

commented Oct 7, 2017

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.

@staltz staltz changed the title Add possibility to select window events Read window events through some driver Oct 7, 2017

@staltz staltz added scope: misc and removed scope: dom labels Oct 7, 2017

@SteveALee

This comment has been minimized.

Copy link
Contributor

commented Oct 7, 2017

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 :)

@shesek

This comment has been minimized.

Copy link

commented Jun 28, 2018

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.

@jvanbruegge

This comment has been minimized.

Copy link
Member Author

commented Jun 28, 2018

@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

@staltz

This comment has been minimized.

Copy link
Member

commented Jun 28, 2018

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.

@IssueHuntBot

This comment has been minimized.

Copy link

commented Dec 7, 2018

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

janat08 added a commit to janat08/cyclejs that referenced this issue Apr 12, 2019

window driver
###--------------------------------------------------------###
feat(dom): window driver for events

Window driver following examples set in dom driver for domsource and etc. Has no documentation as it
was metioned that this might go into repository of its own rather than official one at first.

BREAKING CHANGE:
none

ISSUES CLOSED: cyclejs#568
###--------------------------------------------------------###

janat08 added a commit to janat08/cyclejs that referenced this issue Apr 12, 2019

window driver
###--------------------------------------------------------###
feat(dom): window driver for events

Window driver following examples set in dom driver for domsource and etc. Has no documentation as it
was metioned that this might go into repository of its own rather than official one at first.

BREAKING CHANGE:
none

ISSUES CLOSED: cyclejs#568
###--------------------------------------------------------###

s

janat08 added a commit to janat08/cyclejs that referenced this issue Apr 12, 2019

window driver
###--------------------------------------------------------###
feat(dom): window driver for events

Window driver following examples set in dom driver for domsource and etc. Has no documentation as it
was metioned that this might go into repository of its own rather than official one at first.

BREAKING CHANGE:
none

ISSUES CLOSED: cyclejs#568
###--------------------------------------------------------###

@janat08 janat08 referenced a pull request that will close this issue Apr 12, 2019

Open

window driver #883

3 of 3 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.