Async/await

[hakimio]

Async/await

[fergardi]

Seems promising, thank you!

[hakimio]

Hi,
For now, as a workaround, you could stop the tour before navigating to a different route and then use tourService.startAt('someStep') to start the tour at specific step once your data is loaded.

Anyway, something like you describe shouldn't be too hard to implement. Do you think a config waitBeforeShowing: Promise | Observable should be sufficient in this case?

[hakimio]

@fergardi
I have published version 5.1 which includes new waitFor config. I've also added an example to the demo app. Test it out and let me know if it works as intended.

EDIT: v5.1.1. v5.1 had a bug.

[fergardi]

Thanks for the new feature! I tested it on my project and worked just fine.

However, I've found a strange situation. Let's say I've got three steps 1, 2 and 3. The first one is on the route A, and the second and third ones on the route B. Both routes A and B need to wait for async data in order to properly show the tour steps, so I went this way:

this.tourService.initialize([
  {
    route: '/route/A',
    anchorId: 'step1',
    title: 'example',
    content: 'example',
    waitFor: Observable,
  },
  {
    route: '/route/B',
    anchorId: 'step2',
    title: 'example',
    content: 'example',
    waitFor: Observable,
  },
  {
    route: '/route/B',
    anchorId: 'step3',
    title: 'example',
    content: 'example',
    waitFor: undefined,
  }
], options);

Where the Observable is a Subject which gets uptated with .next() when the async data of each route has finished loading. Since the step3 shares routeB with step2, there is no need to waitFor becase the async data is already checked on previous step2.

But when on step3, if I want to go back to step2, it hangs on waitForing the Observable again, which was already .next()ed once we landed on this route B, and wont fire again becase the data was already loaded.

So basically, I got it working when traveling forward through different routes, but within the same route I'm stuck in backwards mode.

How would you overcome this situation? I've already tried with Promises instead of Observables, with no luck so far.

Thanks in advance.

[hakimio]

You need to use ReplaySubject instead of plain Subject.

[fergardi]

Now I see the issue with using Subject instead of ReplaySubject. Thanks for the insight.

Unfortunatelly this does not solve my specific problem, because I linked all my steps to the same ReplaySubject, hence only triggering the desired effect on the first step with a waitFor.

I guess I could make an array of ReplaySubject[], and next()ing the specific ones I need as I progress further into my app, but that seems tedious and non scalable.

Since I'm using Firebase as a backend, I am only missing my heights calculations by milliseconds. For example, a list populated with *ngFor after a table database subscription, hence the backdrop miscalculation as soon as the tour step enters on the route.

I've tried to waitFor a setTimeouted promise, but as the steps are created on initialization, I'm guessing they all resolve at the same time, instead of before next step invocation:

{
    route: '/route/B',
    anchorId: 'step2',
    title: 'example',
    content: 'example',
    waitFor: new Promise(resolve => setTimeout(resolve, 1000))
},

Normally I would solve this kind of problem using the setTimeout(fn, 0) stack hack ($nextTick() on VueJS), but I'm out of ideas. Any thoughts?

Thanks!

[hakimio]

You can use different subjects and find the subject you need to resolve in the TourService:

const myStep = this.tourService.steps.find(step => step.anchorId === 'my-step');
myStep.waitFor.next();

[hakimio]

If you want to find a really scalable way. I would suggest looking into Akita state management pattern. With Akita you should be able to just use loaders without any need to manually resolve your waitFor observables. For example, here is a simple example:

postsWaitFor = this.loader.loadersFor('posts').get$.pipe(filter(isLoading => isLoading === false));

[hakimio]

@fergardi I have introduced a new step option called isAsync. Should be easier to use. Check out the release info to find out more.