Really awesome package, however doesn't seem to be any support for those who are using hooks as part of their frontend architecture.
Would be really cool if we could have a useJoyride hook that we could then call from another hook rather than being forced to add a component to the render part of the JSX.
Many others and I use hooks for extracting logic away from the presentation, and so this would enable this pattern of usage with this package also
This is one possibility I thought of, although its better this is a collaborative effort to refine how it will be used
const joyride = useReactJoyride({
steps,
scrollToFirstStep,
continuous,
...
})
React.useEffect(()=> {
joyride.start()
}, [startJoyride])
hey @max-carroll
How would you render the component?
I haven't looked too much into how joyride works so I'll take a look and comeback with a better answer, But other npm components work using hooks, sometimes they are using a Context Consumer and Provider for these type of scenarios, so that the provider may have some state and methods and that these can be consumed from,
So I'm assuming that when you define your steps with a target, under the hood the package is getting the element by the class name and then manipulating the dom based on that, so why is it necessary that a component is rendered? If we just need to execute a javascript function then the logic for this can be inside a hook which returns a handler such as startJoyRide() or setStartJoyRide(start : boolean) and this can then be called from the component using the hook or the start value changed,
Inside the hook there could be something watching the start state using a useEffect hook and then when it changes, it manipulates the dom, if it has access to the steps in its props, then it can still obtain and manipulate them.
Some other npm components I can think of which offer use of hooks and still have display elements are
This pattern is becoming more common now as it allows better separation between logic and presentation
I could do a proof of concept to show how it potentially could work.
My main reason for opening this issue is because I'm a big fan of hooks and my app is using hook patterns a lot, so when I use an npm package where I think hooks might be beneficial for it, I will start the discussion 馃榾
Hey @max-carroll
I've been using hooks since the beginning and I love some of them but I don't expect that UI components should be hooks just for the sake of being cool.
If you are not using the reconciliation and virtual DOM capabilities of React, what's the point?
Anyway, I'm not willing to embrace an imperative way to render this component.
Thanks for your time but in the current form this isn't something I'll consider right now.
What about an HOC instead?
I too didn't want to add the <JoyRide/> Component in all the pages so created an HOC and wrapped my components instead.
Been using it since and absolutely love it. I could submit an initial PR so we could have a discussion if it would be useful to others.
Hey @rahulpsd18
I think this approach works for your case but I really don't see the need to complicate the setup for most users.
HOCs are messy.
@rahulpsd18 I may end up creating a Wrapper around react-joyride so that I can use it from a hook, perhaps when I do it, I can do it mindfully so that it may also be exposed via either a HOC or Hook. I'll let you know when I start working on it
Most helpful comment
Hey @max-carroll
I've been using hooks since the beginning and I love some of them but I don't expect that UI components should be hooks just for the sake of being cool.
If you are not using the reconciliation and virtual DOM capabilities of React, what's the point?
Anyway, I'm not willing to embrace an imperative way to render this component.