twbs
v5: Export DOM utils
Follow up of #32941
This commit exports exports all the DOM utils into a domUtils property, to be able to use them in thrid party JS plugins.
Motivation : The plan is to allow third party plugins to integrates as best as possible into Bootstrap system. Previously this was done through jQuery. But now Bootstrap is basically starting from scratch and locking itself.
- Without
Data, third party plugins cannot interact with core and other plugins because the map storing instances is private. - Without
EventHandler, third party plugins will never be able to have a similar event system, neither seamlessly integrate with jQuery when present. This is IMHO critical because it will lead to a scatter of patterns, namings, param handling, etc. SelectorEngineandManipulatorare bonuses, they are not necessary.
Usage : Since 2014 I develop Bootstrap Confirmation and always tried to stick to Bootstrap patterns, sometimes refusing changes because it would be incompatible with Popover behavior. I wouldn't like to offer a degraded v5 migration.
What next :
I think Bootstrap would benefits a documentation, or a least an introduction, to plugins creations, perhaps on the Extend page.
Unfortunately I don't know enough internals to propose somthing.
Not a fan of doing it this way tbh.
I understand the reason behind this request, but if we expose internal utilities, we have to consider changes to the structure of them always as breaking. This would mean we might need to delay some refactorings to a next major version rather doing them between minor ones. And we're currently in the process of reviewing older implementations to improve things.
Also I'm not sure if it was respected in their development to make them available to 3rd parties at some point. If you can control how the code is used, some cases can be simply disregarded until they lead to problems you are immediately aware of.
To get the instance of a component, every component class provides a getInstance() method which is basically the same as using Data.get. It was decided (not by me btw), that Data.set only allows to store one instance per element which may lead to users deleting instances (if they feel necessary) so they could add a plugin instance instead. This on the other hand could break our code, so not sure if we want to give them those tools.
EventHandler is a replacement for the jQuery event handling since jQuery was dropped as a dependency. But I'd like to argue that it has a few flaws and honestly I'd like to address some of those first. So allowing 3rd parties to use it as is now, makes things likely to break for them in the future or we'd have to delay those changes to v6 or something.
If we want to provide some better way for plugin developers I feel we should add some layer of abstraction over our internals for them to use. Or we could consider to add some functionality on the base-component in that regard and to allow developers to extend that class as we do with our components.
Just my two cents.
If we want to provide some better way for plugin developers I feel we should add some layer of abstraction over our internals for them to use. Or we could consider to add some functionality on the base-component in that regard and to allow developers to extend that class as we do with our components.
I totally agree. But this PR was a simple way to make this possible because I currently don't see any clean way to have Bootstrap plugins in V5.
Problem is : will such system will be available in a few months or in two years ?
Never developed some plugin for bootstrap myself, so it's hard for me know about the requirements you guys could have. Also I have no idea, how things been solved in the past or what steps been involved to make it work. Nor I'm aware if there are some best practise or patterns to achieve certain things.
I can totally understand that there are needs now that we dropped jQuery and as such changed some stuff on our end. I'm afraid that none of us really thought about the implications that might have on plugin developers (maybe I'm wrong tho).
I'm just not a fan of just easily opening things up, that we may have to take away again from you guys, because we realized that it causes problems for us.
Also this is just my opinion, there are more guys on this project. Maybe they are ok with this. I'm not going to be a show stopper, just sharing my thoughts.
About how long it would take to provide such functionality. Hard to say.. I'm pretty sure it wouldn't take two years. If someone who got a rough idea what the requirements are this likely could be done within a few weeks if at all that long.
I don't thing there was anything special done in the past. Bootstrap components being standard jQuery plugins, "we" just followed the patterns defined by jQuery. I also don't know if there are many plugins similar to Confirmation in the wild, it is a special case by totally inheriting from Popover. Bootstrap Datepicker for example (no v5 support yet) follows the design of Bootstrap 3/4 but does not actually depends on Bootstrap components.
That being said my point stays : if BT 5 does not exposes it's internal in some way, plugins (inherited or not) won't be able to propose a well known and standard API to users.
I also agree that simply exposing the internals is problematic for the maintenance :-)
Both opinions are considerably right.
Problem is : will such system will be available in a few months or in two years ?
I can tell we are on track to improve many things, and want to believe it would be done in a few months We have already started to clean-up stuff
Although is a great advance for community (and BS itself) to be extendable. In order to achieve a win win solution, @mistic100 which you think are the minimum needs of exportable helpers, to help on your implementation?
Closing as stale. Let’s pick up the conversation again soon if there’s something more to be done in v6.
It is stale because there wasn't any official answer by the Bootstrap team....
The need is still there.