Added compat exports and extensibility

[gianniguida]

Changes proposed in this pull request:
Added compat exports and extensibility.

Reviewers should focus on:
Check that nothing is broken.

Necessity

• Has the problem that is being solved here been clearly explained?
• If applicable, have various options for solving this problem been considered?
• For core PRs, does this need to be in core, or could it be in an extension?
• Are we willing to maintain this for years / potentially forever?

Confirmed

• Frontend changes: tested on a local Flarum installation.
• Core developer confirmed locally this works as intended.
• Tests have been added, or are not appropriate here.

[askvortsov1]

This makes sense, but I'm curious: is there a use case for having the initialization utils (e.g. addComposerAutocomplete) exported, since functions can't be overriden?

[davwheat]

I'd be a fan of exporting an object which contains these currently unexported utils, as this can be extended/overridden.

[askvortsov1]

I'd be a fan of exporting an object which contains these currently unexported utils, as this can be extended/overridden.

Functions cannot be extended or overriden.

[davwheat]

@askvortsov1 They can when part of an object. It's what we do in DiscussionControls, isn't it?

https://github.com/flarum/core/blob/master/js/src/forum/utils/DiscussionControls.js

[askvortsov1]

@askvortsov1 They can when part of an object. It's what we do in DiscussionControls, isn't it?

https://github.com/flarum/core/blob/master/js/src/forum/utils/DiscussionControls.js

The functions themselves are not changed. What happens is that when we call DiscussionControls.controls(discussion), the value of DiscussionControls.controls is resolved dynamically at runtime. This means that if other code overrides DiscussionControls['controls'] at some point during boot, the DiscussionControls.controls(discussion) call will resolve to the new (overriden, in our terms) value. But the actual function has not been changed.

So, if a function is imported as a function, not dynamically resolved as a member of an object, there is no way to "override" that function. If we were to extend or override the function in compat, we would be changing compat, but not the function itself.

[iPurpl3x]

This makes sense, but I'm curious: is there a use case for having the initialization utils (e.g. addComposerAutocomplete) exported, since functions can't be overriden?

@askvortsov1 this has been done here because it is done like that in flarum/tags. That is the only reason. I also don't currently see any use case for it. Please tell @gianniguida if he should remove those exports.

[askvortsov1]

This makes sense, but I'm curious: is there a use case for having the initialization utils (e.g. addComposerAutocomplete) exported, since functions can't be overriden?

@askvortsov1 this has been done here because it is done like that in flarum/tags. That is the only reason. I also don't currently see any use case for it. Please tell @gianniguida if he should remove those exports.

I think I would prefer not to export those, as they definitely aren't part of the public API