Handling onpage hash links about page.js HOT 5 OPEN

Any input on this?

from page.js.

Still nothing?

from page.js.

The project is dead.

For those with the same issue, you can:

• Either not use regular links for things like API calls, so that you don't need to use the {click: false} option (but it would not be ideal semantically speaking)

<span class="api-link" data-href="{url}">{label}</span>

• Or, in your click handler, stop the router before returning true, and then call setTimeout to start it again an instant later:

// We need to override the click handler that would otherwise have been defined by page.js,
// so that we can fine-tune the behavior
$(document.body).on('click', 'a', function(e) {
	// "api-link" links don't need to be handled here, it's just to show the reason for using {click: false}
	if ($(this).attr('href').charAt(0) === '#' || $(this).hasClass('api-link')) {
		// same-page anchors DO need to be handled here though, because they would pushstate,
		// and then page.js would execute yet again the route callback of the page we're on...
		// we need to prevent that: disable page.js just for a tiny moment
		page.stop();
		setTimeout(page.start.bind(page, {click: false, dispatch: false}), 100);
	}
	return true;
});

It works for me as it is, but there might of course be room for improvement.

Feel free to improve this! 😉👍

from page.js.

Another issue I encountered right after:

There is a bug in page.js that does not reset _running to true, which in turn causes the stop() method to return too early, and not unbind listeners.

Just be sure to modify page.js lines 551 and 552 so that this._running = true; is executed before the function returning (because we gave the option {dispatch: false}):

this._running = true;

// Execute this AFTER setting _running back to true, otherwise the stop() method won't work properly
if (false === opts.dispatch) return;

from page.js.

I don't think your original issue is caused by page.js intercepting click events on links. Looking at the page.js source, there's no reason to believe that the click handlers were installed if you specified {click: false}. However, specifying {hashbang: true} would cause page.js to install hashchange event handlers, and since the links in question would change the URL's fragment identifier, page.js would detect those changes and respond. Now, while you haven't provided details on your initial page.js configuration object, I suspect that this might be the case.
If you need to handle multiple levels of fragment identifiers (e.g. example.com/#!/route1#header1), you can simply install a middleware handler in front of your routes, to break the dispatch sequence when you detect these kinds of URLs. For example:

page((ctx, next) => {
    // find the index of the hashbang defined by page.js
    let hashIdx = ctx.pathname.indexOf("#!");

    // check for additional hash marks
    if (ctx.pathname.includes("#", hashIdx + 2)) {
        doSomethingElse(ctx.pathname); // dispatch the link to a custom handler
        return; // early return prevents page.js from continuing the dispatch operation
    }

    next();
});

Now, with that being said, URLs containing multiple levels of fragment identifiers are not compliant with the current web standards. You have to remember that specifying {hashbang: true} is already causing page.js to occupy the fragment component of the URL. Attempting to define sub-fragments is not advised and rightly results in undefined behavior.

from page.js.