Asynchronous switch functions don't work #72

New Issue

2016-06-25T16:43:49-05:00

tremby commented

2016-06-25 16:43:49 -05:00

(Migrated from github.com)

The documents make it seem like asynchronous functions can be used as switching functions, since there's a callback this.onSwitch we're asked to call.

I presumed this meant I could do animations and such, and actually switch the content once I am ready, and then call this.onSwitch once finished. The node would then be parsed for new links etc at that point.

But that's not how it works -- all this.onSwitch does is trigger the resize and scroll events. So the DOM is parsed for new links etc before the markup has been switched, in my case, and so the handlers aren't attached to any links in the new markup.

Would it be a simple matter to add support for async switching functions? If you're expecting the user to call this.onSwitch anyway, you could just treat all switching functions as async.

The documents make it seem like asynchronous functions can be used as switching functions, since there's a callback `this.onSwitch` we're asked to call. I presumed this meant I could do animations and such, and actually switch the content once I am ready, and then call `this.onSwitch` once finished. The node would then be parsed for new links etc at that point. But that's not how it works -- all `this.onSwitch` does is trigger the `resize` and `scroll` events. So the DOM is parsed for new links etc _before_ the markup has been switched, in my case, and so the handlers aren't attached to any links in the new markup. Would it be a simple matter to add support for async switching functions? If you're expecting the user to call `this.onSwitch` anyway, you could just treat _all_ switching functions as async.

👍 1

tremby commented

2016-06-25 17:11:11 -05:00

(Migrated from github.com)

My current workaround is to call this.parseDOM(document) once all my switches are finished.

My current workaround is to call `this.parseDOM(document)` once all my switches are finished.

MoOx commented

2016-06-28 00:12:33 -05:00

(Migrated from github.com)

Can't remember how I did this since it's a long time ago, but pretty sure you can do async stuff. I was using this 259dc4b098/src/assets/_scripts/vanilla.js (L42-L95)

Can't remember how I did this since it's a long time ago, but pretty sure you can do async stuff. I was using this https://github.com/MoOx/moox.github.io/blob/259dc4b098d9a81f580f9276cc001184c3b3c6fc/src/assets/_scripts/vanilla.js#L42-L95

tremby commented

2016-06-28 00:52:48 -05:00

(Migrated from github.com)

That works around the issue by immediately inserting the new content side by side with the old. It's then successfully parsed immediately and click handlers are added. It therefore doesn't suffer from the issue. Then the async part is removing the old content later.

The execution of the pjax code isn't halted at all.

If the new content isn't added until later, the parseDOM method isn't run over it.

That works around the issue by immediately inserting the new content side by side with the old. It's then successfully parsed immediately and click handlers are added. It therefore doesn't suffer from the issue. Then the async part is removing the old content later. The execution of the pjax code isn't halted at all. If the new content isn't added until later, the `parseDOM` method isn't run over it.

BehindTheMath commented

2018-01-11 22:35:18 -05:00

(Migrated from github.com)

@tremby What type of of async operations were you doing? Pjax is basically synchronous, so even if you have an animation that takes some time, execution won't continue until it's done, and parseDOM() won't be called until then.

@tremby What type of of async operations were you doing? Pjax is basically synchronous, so even if you have an animation that takes some time, execution won't continue until it's done, and `parseDOM()` won't be called until then.

tremby commented

2018-01-12 15:47:33 -05:00

(Migrated from github.com)

@BehindTheMath, I don't remember since it was a year and a half ago, but my original post here mentions animations, so that's a good bet. What you said would only be true if the animation were entirely synchronous. I don't know how one would animate something on a web page with entirely synchronous code.

BehindTheMath commented

2018-01-14 00:09:44 -05:00

(Migrated from github.com)

@tremby Pardon my ignorance; I'm primarily a backend developer, so I don't have experience with animations.

I think the code as it stands today isn't structured sensibly. #79 fixes this issue, but that just worsens #46, since parseDOM(document) is being called after every switch finishes. That's besides parseDOM(el) being called for each switch after the switches are triggered, even if they're async.

Instead, I think it would be better to call parseDOM(el) only from onSwitch(), and require the user to pass the current element when calling onSwitch()

This might change depending on how we fix #46, but at least for now, I think this will simplify things.

@tremby Pardon my ignorance; I'm primarily a backend developer, so I don't have experience with animations. I think the code as it stands today isn't structured sensibly. #79 fixes this issue, but that just worsens #46, since [`parseDOM(document)`](https://github.com/MoOx/pjax/blob/6fa51e58f81494022abeade2ab410e8950edb25c/index.js#L86) is being called after every switch finishes. That's besides [`parseDOM(el)`](https://github.com/MoOx/pjax/blob/6fa51e58f81494022abeade2ab410e8950edb25c/index.js#L225) being called for each switch after the switches are triggered, even if they're async. Instead, I think it would be better to call `parseDOM(el)` only from `onSwitch()`, and require the user to pass the current element when calling `onSwitch()` This might change depending on how we fix #46, but at least for now, I think this will simplify things.

tremby commented

2018-01-14 00:12:53 -05:00

(Migrated from github.com)

Seems reasonable that you might detect whether the user wants to do this asynchronously or synchronously, then call parseDOM automatically if synchronous, or as part of the callback if asynchronous.

Seems reasonable that you might detect whether the user wants to do this asynchronously or synchronously, then call `parseDOM` automatically if synchronous, or as part of the callback if asynchronous.

BehindTheMath commented

2018-01-14 00:20:51 -05:00

(Migrated from github.com)

I'm not sure how we would be able to detect that.

What we might be able to do, is assume it's synchronous unless the user returns a truthy value from the switch. The WebExtensions Messaging API has something like that.

I'm not sure how we would be able to detect that. What we might be able to do, is assume it's synchronous unless the user returns a truthy value from the switch. The [WebExtensions Messaging API](https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/runtime/onMessage) has something like that.

tremby commented

2018-01-14 02:24:18 -05:00

(Migrated from github.com)

Yes, I meant by the user telling advising pjax that async is wanted. That wasn't at all clear; sorry.

But if I'm reading the docs properly, the default switching function calls the callback anyway. That means you can rely on it being called at the right moment in all cases, right? So what you suggested before, only running the post-switch logic in onSwitch, seems like the thing to do. No need to know or care if the switching fiction is sync or async.

Yes, I meant by the user telling advising pjax that async is wanted. That wasn't at all clear; sorry. But if I'm reading the docs properly, the default switching function calls the callback anyway. That means you can rely on it being called at the right moment in all cases, right? So what you suggested before, only running the post-switch logic in onSwitch, seems like the thing to do. No need to know or care if the switching fiction is sync or async.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: iLoveElysia/pjax#72