React-joyride: Add option to control allowing clicking in overlay hole

[jjhale]

Clicking in the hole does not seem to trigger the "hole:click" callback.

I suspect it is related to #157

The "hole:click" callback does get triggered in this PR for IanVS's fork when the new prop allowClicksInHole is set to false.
https://github.com/nutshellcrm/react-joyride/pull/17

[IanVS]

I'd like to ask, _should_ the callback be triggered if the click is being passed "through" the hole into whatever lies beneath it? I'm not so familiar with the use-cases around this particular callback. I saw it as a workaround for not being able to actually click into the hole. Now that we _can_ click in the hole, is it still needed?

If we added an option similar to what I'm adding in https://github.com/nutshellcrm/react-joyride/pull/17, would that be sufficient to support the desired use cases?

[jjhale]

FYI In my usage I'm dismissing the walkthrough if a user clicks in the hole. I use the "hole:click" to close it to allow the user to get on with using my site.

[IanVS]

So it sounds like a setting to allow the old behavior (like in the PR in my
fork) would meet your needs, right?

On Thu, Jan 12, 2017, 14:39 jjhale [e-mail] wrote:

FYI In my usage I'm dismissing the walkthrough if a user clicks in the
hole. I use the "hole:click" to close it to allow the user to get on with
using my site.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/gilbarbara/react-joyride/issues/189#issuecomment-272260937,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEZyAX6jI1_G9XhUhqHZ9bAO870Axf-Jks5rRoFsgaJpZM4LiFxs
.

[jjhale]

yes

[IanVS]

@gilbarbara what do you think? Should we add a prop of allowClicksInHole (or some better name, open to suggestions) to control whether react-joyride:

• Allows pointer-events inside the hole, but does not send a callback _or_
• Prevents pointer-events within the hole and does send the callback (previous behavior)

[gilbarbara]

hey @IanVS
Yeah, I think it's better to have a flag to allow the hole click events to passthrough, maybe allowHoleClicks? If the flag present in the step, turn on the mouseenter handler or else keep the previous behavior.

[jjhale]

Having the previous behavior be the default sounds like a good idea.

allowHoleClicks sounds like it would be required for the "hole:click" callback (which I think you are saying it would not be).

Maybe call it passClickThruHole or allowClickThruHole?

[IanVS]

I like the name allowClickThruHole, but I worry that it would be a breaking
change. Although technically it seems that my PR to allow them by default
was also breaking. What are the semver implications here? Do we treat my
previous change as having introduced a bug, and the new change we are
proposing is a bug fix to restore the previous behavior? That seems logical
to me.

[gilbarbara]

yeah, bug fix sounds right.

[IanVS]

Hmm, another name for the setting could be captureHoleClicks, which would default to true and fire the callbacks as before. Perhaps that is more clear? Which form do you prefer, @gilbarbara?

[gilbarbara]

I prefer the first idea, allowClickThruHole or something that defaults to false.