Listening order and plugin dependencies

[hsablonniere]

The activate listener is done in a setTimeout see here.

This means the plugin order of a bespoke config will not be the order in which plugins listen for events and therefore not the order in which their behaviour is triggered. This is confusing for newcomers and it prevents plugin dependencies.

Do we know why this setTimeout was set in the beginning?

[mojavelinux]

I'm in favor of changing this behavior. It has caused me problems when writing plugins. I can only speculate why it was done this way, but my guess is that it was done to alleviate having to mandate a plugin order. However, it's much more logical to document an order than to use this hack.

[mojavelinux]

The problem here is that core is activating the first slide after the plugins are initialized. As a result, it clobbers the work done by bespoke-hash.

To fix this, I think the activeSlide should be undefined by default. After the plugins are initialized, core should only activate the first slide if activeSlide is still undefined.

That kind of raises the question as to why core is calling activate(0). Presumably this is done to mark the end of plugin initialization. But perhaps a dedicated event like ready would be better.

[mojavelinux]

I think bespokejs/bespoke#71 has to be solved in order to make this change. I can't think of a way based the old behavior of core to make this work.

[mojavelinux]

I've tried to come up with some tricks, but they are very non-deterministic. That's because we can't really be sure that it was core that called activate(0) (and not some other action immediately after). It's best just to say that if we fix this, then it will depend on the next version of bespoke-core.

[mojavelinux]

Okay, I came up with a way to do it that will make it compatible with old and new core. I added an option flag named deferStart which enables the old behavior. If anyone upgrades the plugin and doesn't upgrade core, they will need to set this option. That seems reasonable.