Trigger javascript on clicking any page link, but before the page content loads?

Dev
1

Hi.
When we change page in Discourse, these are the apparent steps:

  1. We click on the link
  2. The current content disappears and the loader appears
  3. The URL is updated and the new content appears

This is slightly different when we go from a page to the home, as the URL is changed to the home URL when the current content disappears, and not when the new content appears.

My goal is to have a script that is executed as soon as we click any page link on Discourse.
api.onPageChange won’t fit in this case since the code is executed quite at the same time the new page content is loaded.

Is there a Discourse method for that? I look at the event triggers but didn’t find any one corresponding to what I need.

1 Like
2

Hey :wave:

There’s currently no method in the Plugin-API that will allow you to fire a script before a page transition because this has not come up before as far as I recall.

That said, you can leverage on the willTransition() action in the application route

You would use something that like this in your theme / component

// this fires after the transition
api.onPageChange((url, title) => {
  console.log("after transition");
});

// this fires right before the transition
api.modifyClass("route:application", {
  pluginId: "some-name",
  actions: {
    willTransition() {
      // run core code first
      this._super(...arguments);
      // then do some work
      console.log("before transition");
      // you can also do something like this to see what data you have
      // to work with like _router
      console.log(this)
    }
  }
});
6 Likes
3

Exactly what I needed. Thanks!

2 Likes
4

This doesn’t seem to fire on entering a Topic from a Topic List?

I’ve also tried adding one:

      api.modifyClass("route:topic", {
        pluginId: PLUGIN_ID,
        actions: {
          willTransition() {

but that doesn’t fire either.

5

Couple of reasons that might not be working:

  1. putting actions in a hash is an old syntax which we no longer use in Discourse. Theoretically it should work, but the interop with the new syntax might not be perfect. The modern way would be

    api.modifyClass("route:application", (Superclass) => class extends Superclass {
  @action
  willTransition(){
    console.log("do something");
    super.willTransition(...arguments);
  }
});

    standard modifyClass disclaimer applies: this is risky and could break at any time

  2. I don’t think willTransition is guaranteed to fire on the application route in all situations. (e.g. if a child route has a willTransition action, it won’t necessarily bubble up)

I’d recommend using the events on the Ember router service instead: RouterService - 5.12 - Ember API Documentation

e.g. something like

const router = api.container.lookup("service:router");
router.on("routeWillChange", () => {
  console.log("route will change fired");
});
2 Likes
6

Nice, thanks David, I will try that next!

This investigation was triggered (ahem) because I needed a way of firing something on every page change, and prior to Render.

Page Change api event doesn’t seem to be guaranteed to fire before page elements are rendered, apparently.

1 Like
7

I think you’ll struggle to do this perfectly. Ember expects to be in full control of rendering, so trying to hook into arbitrary points will be hard, and may cause issues (depending what you’re trying to do).

Obviously I don’t know what your end goal is… so maybe the pain is justified. In which case: feel free to ignore me :wink:

(of course, if you’d like to open a Dev topic about the problem you’re trying to solve, I’d happily take a look)

8

Happy to be explicit as the code is open source:

I’m working with a third party ad provider and they have an ad page reset function in javascript that needs to be run before the new page’s ads are triggered.

any improvement is welcome and I’ve already realised this on the Topic List with Johani’s code. (in an open PR).

But this left the Topic … I will try your suggestion next and adopt it in both instances if that improves things further.

9

Ah I see, so you’re not modifying the DOM directly :ok_hand:

In that case I hope routeWillChange will work - it should certainly fire before the next route is rendered.

Caveat is that… in the case of things like redirects, it may fire twice. Or may fire, and then the transition ends up being aborted. But maybe that’s fine in this case.

2 Likes
10

Yes, none of that naughty direct DOM modification malarky here at Merefield Technology Towers. :sweat_smile:

Yes, I’ll use the service, that’s what it’s for! I’ll revert with my experience as I’m sure the results might interest others.

3 Likes
11

So yes, that cleans up and things do happen in the right order on both routes now.

:rocket:

Thanks for your help!

2 Likes