geojs icon indicating copy to clipboard operation
geojs copied to clipboard

Drop jquery dependency

Open zachmullen opened this issue 5 years ago • 7 comments

For modernization

zachmullen avatar Jul 12 '18 17:07 zachmullen

@zachmullen this had come up in the past. we would still need something to replace it. what would be your suggestions?

aashish24 avatar Jul 12 '18 17:07 aashish24

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.

zachmullen avatar Jul 12 '18 17:07 zachmullen

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:

screen shot 2018-07-12 at 1 30 18 pm

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.

zachmullen avatar Jul 12 '18 17:07 zachmullen

Obligatory reference: http://www.vanilla-js.com/.

jbeezley avatar Jul 12 '18 17:07 jbeezley

I love that it actually downloads a 0 byte file for you.

zachmullen avatar Jul 12 '18 17:07 zachmullen

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 or Object.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).

manthey avatar Jul 12 '18 17:07 manthey

If any of your actual API surface involves jquery Deferred types, I would strongly recommend breaking that in favor of native Promises for downstreams.

zachmullen avatar Jul 12 '18 17:07 zachmullen