Reduce boilerplate for firing events

Instead of requiring this boilerplate:

import { createEventDispatcher } from 'svelte';
const dispatch = createEventDispatcher();

with the warning that the call to createEventDispatcher must happen at the top level, just provide a global variable dispatch (maybe there can be a project-level option for the name), and if you detect that it is used, emit the boilerplate during compilation, otherwise omit it.

[Conduitry]

I’m not sold on this being a great idea, but technically I don’t think this would be much of a hassle.

There’s precedent for special $$-prefix variables (although currently it’s a precedent of one, $$props). It’d be pretty easy to inject the appropriate import and call createEventDispatcher() and assign it to $$dispatch if that variable were used.

I can’t speak to other tooling, but there’s a mechanism already in place that the compiler is using to tell eslint-plugin-svelte3 about variables that it’s injecting (used for $$props as well as the $-prefixed store autosubscriptions), and this could be used to tell the plugin about $$dispatch without any more work needed in the plugin.

But, again, none of this is necessarily an endorsement of this being a good idea. Just that it’s reasonable from a technical standpoint.

[rixo]

It seems it would spite @antony, so I turned this feature into a preprocessor: https://github.com/rixo/svelte-preprocess-autoimport.

This way, everyone can try it and choose for themselves.

I too have always been bothered by the boilerplaty syntax of createEventDispatcher and, increasingly, also by the micro management of lifecycle functions imports like onMount and onDestroy, that often come and go as a component evolves…

On the other hand, I’ve lived through the “everything global” and “libraries attach to default prototypes” era of JS, and so I’m pretty wary of magic imports and magic in general. And I guess that the lack of imports in the source code will surely trip up tooling like Typescript.

Yet, as long as it is limited to the framework’s own helpers, I think the added magic vs reduced boilerplate & micro management trade off might be worth it. I’m personally going to try this in my code, and see if I encounter any major setbacks that would make me reverse course.