helen
commented
10 years ago Backing up to think through the goals of the wrapper. Interested in any thoughts on other goals that may be missing, or things that shouldn't affect design decisions.
- Protect ourselves against breaking changes in the library that's used. This is the most common case, and illustrated in WordPress core in the upgrade to Masonry 3.
- Ease a transition to another library. This is a lesser concern, as the library of choice should be well-vetted before inclusion, but something to at least consider in the wrapper's design. It is very unlikely that all things can be accounted for perfectly. JS errors have become much more crippling today - we may not always consider them to be as severe as a PHP fatal (although in some applications, it still results in a "white screen of death"), but to a user, they don't feel all that different.
So, with that, I think we do need something more generic. It may be that the wrapper in its basic form only supports the basics, although we should consider that essentially all of the currently noted potential usages in core will include Ajax.
ericandrewlewis
I'm curious how generic others think this wrapper should be.
Select2 has a rather specific API regarding AJAX endpoints and the data expected by them. Presumably similar libraries have their own opinionated internals which may differ, so exposing a generic Select2 wrapper doesn't sound like a good option to me. Rather, a one-off per use case - here, offering $().wpUsersDropdown().