Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Lionel
    @elrumordelaluz
    sure
    in case you have a peace of time creating the repro of your App (without all the content) I'll take as test case if you use Mobx
    Jov Stern
    @jovstern
    it will be easy to get to Italy instead :)
    you from Italy right?
    it's a huge app and we need all the content to get it right.
    Lionel
    @elrumordelaluz
    I am an argentinean living in Italy, but don't understant what you mean
    I said it would be awesome to have a codesandbox (as a test case) with mobx or redux or similar
    Jov Stern
    @jovstern
    Yeh, we should to that but right now i need to figure this out, i'm starting from the beginning to understand what causing this behavior, i let you know soon if i find something, i really back to square one i don't know if it's CSS problem or functionality issue..
    Jov Stern
    @jovstern
    5.gif
    Ok, so i written the Tour from scratch without stores or EventsLister, the simples way of the tour and you can see the problem, it's to small Divs but way far from each other. now i want to check my app cause i have a lot of fixed elements and components that have there own scrolling events..
    Jov Stern
    @jovstern
    Yo @elrumordelaluz i just realize in Safari it's works PERFECT!
    i can't believe i didn't check it until now, i only test the app in Chrome and Firefox.
    maybe in the Tour scroller event something is not quite fit to Chrome or Firefox
    Jov Stern
    @jovstern
    I think i got the solution, it's seems like my overflow-x: hidden causing this problem. i don't understand way but, if remove it it's helping.
    Lionel
    @elrumordelaluz
    lol
    was the first question I wanted to ask you, if you are resetting this https://github.com/elrumordelaluz/reactour/blob/master/src/TourPortal.js#L64-L69
    haha
    ok, so in Safari works as expected and not Chrome, right?
    nice catch @jovstern I'll have to check some dependencies that handle the scroll behaviour
    Lionel
    @elrumordelaluz
    also look at elrumordelaluz/reactour#10
    where describe that in fact Safari doesn't handle the overflow-y as expected, like the default in reactour
    si, I think in Safari you could scroll also when the Tour is open
    are one of the stepswe are studying, positioned other than relative?
    or in its own scrollable parent node?
    Jov Stern
    @jovstern
    Its own scrollable node, the position of the components doesn't effect on the Tour. let me know if you change something in the widget and off course i let you know when it's on prod. thank you for now..
    Lionel
    @elrumordelaluz
    sure!
    praveenkutty
    @praveenkutty
    hello there,
    could you please tell me how can i store the current step in state(reactour)
    thanks in advance
    Dovy Paukstys
    @dovy
    Yay, Glitter.
    Dovy Paukstys
    @dovy
    Thanks for the awesome work @elrumordelaluz
    Peter Kottas
    @PeterKottas
    Hi there, happy to discuss the state of dev for the @next phase of reactour. Feel free to hit me with some details about the actions. I can clone it and take a look then. Generally speaking, I am mostly looking for understanding why the actions are even required. What is the main reason for it be implemented as I think it could be done by controlling the state directly.
    But like I've said before, I might be missing something.
    Dovy Paukstys
    @dovy
    @PeterKottas I think the main issue is the same issue I experienced. In the current implementation I set an action, but the action occurs too late and the component I render in that action isn't displayed. I believe there's the desire (and rightfully so) to do a before animation as well as cleanup function so that steps can clean themselves up without affecting other steps. Right now, the "cleanup" for a step must occur in the action of another step. Not the easiest to manage.
    MidasCKR
    @ckrukp
    hey @elrumordelaluz
    Thanks so much your awesome library and your work.
    I use your reactour in my project. Btw i have some problems to use that.
    Should i be able to receive the status of the checkbox on the step content when tour is closed?
    Peter Kottas
    @PeterKottas
    Notifications were not working ... I can see your messages now. Would it maybe make sense to look at what mui is doing with their modals? If this is all about transitions, I think they have it covered over there at https://material-ui.com/api/modal/. Coming back to the message, I am not sure if the cleanup is the wat to go in react. Generally speaking, since react is declarative, the cleanup should be based on this declarative nature. You can also easily achieve cleanup by using something like this.
    React.useEffect(()=>{if(step===stepThatNeedsCleanup){return ()=>performCleanUp()}});Basically just reacting to the step being changed. What you could do on the other side of things (with initialization). You can add prop transitionDuration. Use internal state to keep the step that is provided externally. Now every time the internal step is not equal to the external step, you would run a timer (keep the instance to be able to clear it if it changes again). When this timer fires, the internal step is set to the external step. This way you can easily fire a callback (beforeStep, afterStep, stepShown) and you can also add special className used for the transition when the timer is running. Hope ti makes sense :)
    Lionel
    @elrumordelaluz

    Notifications were not working…

    Same for me, I'm reading all the new messages right now.

    Lionel
    @elrumordelaluz
    Over the time and from different implementations explained through issues I understand that for some steps it's important to fire an effect related to the highlighted Component. Since the beginning I thought the Tour with some kind of interactivity; for that reason, the highlighted Component is shown as it is and so on. From that interaction, could happen situations where when interacting, we want some reactivity in response, and there were the observe behaviour. But in some cases make more sense bind actions you want to show in the Tour to the specific step. For example, an inputyou want to be focused just after the step landed, or prepare some UI just before the step is selected to show some specific part, and probably users of reactor have better real-world examples.
    You are right @PeterKottas, that could be responsibility of an outside state management of the Tour, but I worry that not everyone manages state from outside, could be an over complicated setup for one that only want to fire an action in a specific step for example.
    Let me know what do you think.
    [hoping the notifications work again to response quickly]
    Lionel
    @elrumordelaluz
    On the other hand, as you @PeterKottas point in some issue, should be awesome to invert the way I configured the branches to have the v1 as master with the current versions and teh current master in another branch (maybe called) next which tracks the next version development and from where could be published @beta versions.
    @ckrukp could you please open an issue explaining a little more and ideally with an example sandbox
    Peter Kottas
    @PeterKottas

    No worries, yeah notification sorted out on my side :)
    Ok I'll be honest, without seeing the whole history of various issues that brought this to where it is, it will probably be very hard for me to understand exactly the inner reasons for some of the things you mentioned here. But I get it, this has been up a while, and various people needed various things which are usual. In the end, initially simple things got a little bit out of hand. Happens all the time in open source. I was thinking about all of this and I guess sometimes it helps to come up with a potential (even if slightly unrealistic) perfect solution, and maybe take it from there. So here's my train of thoughts.

    I think what we have here is initially 2 products, somewhat glued together. What I see is:

    Reactour: Which is a simple walkthrough that highlights various components on a static(fully loaded) page that doesn't change. This highlighting happens through a number of steps that people can navigate between via interface in the step-modals. Something very similar to the actual demo on the site. I think this is probably a fairly common use-case and likely covers >70% of users out there. Also important to note, this should be minimal setup.

    Reactutor (see what I did there? :P ): This use-case/product/(call it whatever you will) is somewhat trickier. It in my mind tries to solve an interactive tutorial kind of use case. I expect this to be used a lot in Dashboard kinds of situations (in fact that's how I am using it). That means, dynamic pages (where data is loaded via API), listening to various events (navigation, button click, typing) to continue to next steps, instead of simply navigating back and forth via arrows. In my case, I totally hide the dot navigation and arrows and fully lets the experience to be driven by the user interactions with the page. I have created quite a few hooks to deal with this interactivity. For instance, I have a hook called useOnClickTourNavigation where you specify the component to click, next step, previous step and a few other things. When you use it, it simply moves the user to next step once the highlighted button is clicked. I have similar things for sidebar navigation, typing and so on.
    I think this kind of component should be state-controlled (as we could allow for the setup to be little bit more involved than in reactour).

    Doing this, there would be clear division in the API as well as "the general idea" of all of this. Reactour would of course internally use Reactutor, taking care of the state management for the current step, maybe creating the callbacks based on changes in active steps. So in other words, Reactutor would be the barebones implementation of the low-level architecture while Reactour becomes a user-friendly simple tool for general public. This would obviously live in one repo, no big division there. Also this way, we could be relatively lenient with PR against Reactour stuff, while making sure Reactutor would be well maintained and reasoned about (becoming like the core of the lib)

    Also please note that all of the callback stuff could be easily implemented via React.useEffect based on changes in the current step, and we could also relatively easily "pre-implement" this for reactour API to make it easier for users to use this functionality.
    Lionel
    @elrumordelaluz
    awesome @PeterKottas, pretty well explained and love the reactutor naming also!
    Peter Kottas
    @PeterKottas
    Haha, np. I think it might sound a little scary at first, but I wouldn't be surprised if once/if this is done, the code would become so much easier to maintain and reason about. It would definitely be worth the effort.
    ManuelAgustinLucero
    @ManuelAgustinLucero
    Hello, guys have this problem, can you help me? https://www.loom.com/share/fe200f3322e8475ab8a7d41785822229)