Allow users to filter by DOM selector about cycle-mouse-driver

[artfuldev]

@raquelxmoss nice going, taking up that issue! 👍

[artfuldev]

@raquelxmoss We would be using a DOM driver internally for this? Isolation etc. will be a problem that we need to tackle. Why not delegate this to the DOM driver instead?

[raquelxmoss]

I'm thinking of the case where a user has put their Cycle app inside another application, or perhaps they have static content that exists outside of their Cycle app, and they need to listen for mouse events on these elements. For example, a user has a static footer in their index.html. They want something to happen in their Cycle app when a user clicks on the footer.

const footerClick$ = Mouse.click('.footer'); will handle that.

Of course, elements within the app should use the DOM driver.

I haven't prioritised it as it's a bit of an edge case, but as @FeliciousX noted, there is a viable use case there.

[artfuldev]

need to listen for mouse events on these elements

I feel, as long as it is on elements we're referring to the DOM, and it is outside of the concerns of the mouse driver. This driver exists for mouse events, not mouse events on DOM elements, is how I see it. We may take it as a sign of progress, but I find it to be deviating from what it stands for, in a way. Just my view of it. Whenever we need events on DOM elements we use the DOM driver.

[raquelxmoss]

In that case, how would you handle the situation I've described? Someone needs to listen for events on elements outside their cycle app. What should they do? (imagine due to business constraints, they can't just put the element inside their cycle app)

[FeliciousX]

Well they can still handle it manually in the app by filtering

const somethingUp$ = Mouse.up().filter( e => e.target.id === 'something' );

I am neutral with this implementation with filtering on the Mouse driver aswell..

I don't know how much value it will add to the mouse driver if we add a filter.

I've personally worked with a few hybrid cyclejs apps before and it's just to me a nice to have feature.. but not super necessary

[artfuldev]

@raquelxmoss from what I have understood of cycle.js, we don't need to listen to mouse events on something outside our current app (or component).

Say we have component A outside component B and we want to listen to click events on component A inside component B. Basically what we have is a dependency on component A for component B. If that is the case, and it is not nested in terms of the dom, wherein the component B will have no access to events on its children (or child components). Which is the problem described here, if I've got it right.

In this case, I would expect component A to expose its mouseclick events translated into an intent$ or action$, and the common parent of both component A and component B pipes this as a source of component B and component B works on this source stream instead of trying to listen to events over which it has no ownership.

The advantage of this also that in case component A doesn't exist, the source stream provided to B can be empty, and the app wouldn't break. We no longer refer to the DOM events, but rather to a property stream exposed by component A.

I think we're always better off thinking in terms of components rather than the DOM elements, it usually helps me in solving problems like this - we just have to change the way we think, and everything suddenly makes sense.

@FeliciousX @raquelxmoss Am I making any sense? Please share your thoughts on this approach.

[artfuldev]

@FeliciousX the case I am trying to make is, instead of filtering based on an element's id in the dom (over which I have no ownership/control/dependency), I would rather have the stream given to me to which I must react to, as a source. I don't want to query the dom for the footer div or whatever, I want to react to an intent$ or an action$ instead.

[FeliciousX]

I think you misunderstood us @artfuldev . When we say something that is outside the Cycle App it means it's a hybrid app where it's not a Cycle component at all. It's not using the DOM Driver at all.

Imagine having a html page with a static footer that's written in HTML and not a footer component in Cycle App.

<body>
<div id="root"></div> <!-- this is where your cycle app lies -->
<div id="footer">FOOT ERRRR </div>
</body>

From your Cycle code, there's no way of accessing the static HTML footer.

So having a selector filter ('#footer') would make it easier to get the mouse event on that footer

[artfuldev]

@FeliciousX Thanks a lot for clarifying.

In that case, I would still argue that whenever we want to access an element or events on a particular element we are better off using the DOM driver, because that's the reason it exists. Just my two cents.

[artfuldev]

@FeliciousX meaning, I would advise against Mouse.up().filter() and rather we used DOM.select().events()

[raquelxmoss]

@artfuldev The problem though, is that you cannot access anything outside of your Cycle app when you use the DOM driver. We would not be able to select the footer in @FeliciousX's example, as the DOM driver knows nothing about it.

All of this discussion may be moot soon in any case. I've picked up issue #368 in the Cycle Core, which you might like to read: cyclejs/cyclejs#368

[FeliciousX]

Okay I think the best option now is to wait for cyclejs/cyclejs#368 progress.. and since we can still filter it in our Cycle App anyways by using the event.target then it's not a huge issue yet as of now.

Put this as low priority? Until stronger reasons for doing this arise? :D @raquelxmoss

[raquelxmoss]

Yup, totally low priority. We can discuss more once that issue in the core is done. That'll be interesting as it'll mean that we can deprecate quite a bit of this driver, if not the entire thing.