Always call registry's trigger method from withRegistration

[tgvashworth]

This is to make it possible to add a runtime hook to trigger, even when the app is running out of debug mode (as TweetDeck does).

🚀

[angus-c]

@sayrer and I put it behind the debug guard because we were concerned about perf. That's two extra function calls for every trigger, and there can be multiple triggers per click

[tgvashworth]

If I benchmarked the difference, how much would be unacceptable?

[angus-c]

Almost impossible to answer. What's the use case you need it for?

[tgvashworth]

Am working on Flight tooling, hooking into trigger to show what's being triggered where amongst other things. Afaict, really the only hookable bit of Flight is the registry (exposed in standalone, mostly requireable in AMD), and the one method that isn't always exposed is trigger.

I would say it's fine to keep behind debug mode, but TweetDeck can't run in debug mode because we're passing non-seriablizable data around, and we aren't the only ones – the Airbnb search page does it too, and most likely others.

Unless there's another way to advice every component's trigger, added at runtime after the flight app may have loaded, the utility of & scope for the tools I'm building will be severely limited :/

My view is that two, essentially noop, function calls per trigger is fine.

[angus-c]

idea from @kloots: do a this.after('trigger', function() {//...});

[tgvashworth]

What's this in that example?

[angus-c]

your component (just the regular advice pattern)

[tgvashworth]

There isn't a component here – it's an external tool that hooks into Flight. That's why I need it on the registry – it's the only bit has externally exposed methods that are called with a component's context (from withRegistration).

Fwiw, I am actually using advice on trigger, but it's the registry's trigger – and that's why I need it to not be behind the debug flag.

[kloots]

If you're already using advice to go around trigger(), could you not just have your wrapper for trigger() fire a custom event on the document that could then be listened to by any third party?

[tgvashworth]

I'm not already using advice to go around trigger – I'm only able to do that when it's exposed and not behind the flag. This PR just makes it possible when the flag is off.

[sayrer]

I'd like to know why you're passing non-serializable data around before we start hacking things up to work around it.

[tgvashworth]

@sayrer I don't know why we are, but we are.

To summarise again: I want a way to hook into every trigger on all components, with arguments. This is possible with registry.trigger, but the call cannot be behind a flag for the tools to be useful to TweetDeck and, it turns out, Airbnb. I'm sure there are others.

If there's an alternate way to do this without a PR, I'm all ears.

[sayrer]

I want to know why Tweetdeck can't use debug mode... this is what it's for. Restating the thread as a demand is a bit facile.

[tgvashworth]

We have a huge amount of non-Flight code and so in some cases it's simply impractical to use something serializable to get data in and out of that layer.

[tgvashworth]

Closing as we agreed offline to add the necessary data to the DEBUG global.