geojs
geojs copied to clipboard
Drop jquery dependency
For modernization
@zachmullen this had come up in the past. we would still need something to replace it. what would be your suggestions?
For what purpose do you need to replace it? I would suggest using native APIs for element selection & manipulation. If you are talking about for XHR wrapping APIs, axios is a great one. For general why-isn't-this-in-the-standard-library sorts of things, underscore/lodash is nice.
To clarify, the intent of this is less about replacing jquery with things that meet the same needs, and more about removing jquery from any user-facing aspect of geojs. That is, downstreams of geojs should never have to know whether or not geojs depends on jquery. For example, this part of the docs should go away:
And any references to jquery or $
in our tutorials should be replaced. If it turns out that jquery truly is the best tool to meet the internal needs of geojs, then we should keep it, however that would surprise me since there are so many tools designed in the modern, module-centric world to replace various parts of jquery in a way that is more painless for developers.
Obligatory reference: http://www.vanilla-js.com/.
I love that it actually downloads a 0 byte file for you.
It would be easy to drop jquery from geojs's source. We use jQuery in four ways:
- A few trivial selector operations. These could be done with native code. The jquery syntax is more compact, but we don't do it very often.
- Iterate over some objects and lists. This can be replaced with
forEach
orObject.keys().forEach
- ajax calls. Again, easy to replace with native code.
- Deferred. It would be easy to move to native promises, though some of the tests will need to be refactored because jQuery's Deferred bahaves slightly differently. jQuery had the virtue of being present when cross-browser compatibility was a real issue. Now that browsers we care about all have the features we need, we can move to exclude it.
We do use jQuery in some of the examples and tutorials for ajax and selectors. We could continue using it there, or do without as we see fit (but removing it from examples could be done as a separate issue).
If any of your actual API surface involves jquery Deferred
types, I would strongly recommend breaking that in favor of native Promises for downstreams.