jQuery as an optional dependency

opencomponents / oc-client-browser

The OpenComponents Browser client

MIT License

6 stars 8 forks source link

jQuery as an optional dependency #40

Open bassettsj opened 6 years ago

bassettsj commented 6 years ago

Why? The overhead of loading all of jquery is not necessary for the oc-client-browser. Many of the same things can be done using the built in platform and polyfilling for legacy support. I would like to think about how we start to modernize the oc-client-browser to be jquery free and as small and light as possible.

nickbalestra commented 6 years ago

Been discussing this recently with @matteofigus and I'm totally onboard with this. There is a ton of potential in the oc-client browser, decoupling some of its deps is definitely a good place to start.

bassettsj commented 6 years ago

Sounds great, to me. I will see if I can at least get some idea of the internals by looking at adding a unit test or something smaller.

matteofigus commented 6 years ago

Totally! A couple of considerations:

I would like to keep the external api as is to be sure we can gracefully migrate to jqueryless
I think most of the optimisations could be leveraged by using modern browsers' native functionalities (fetch, selectors, etc). Neverthe;ess, I would like to keep supporting the old browsers. Perhaps a strategy could be to implement a simple browser detection at the beginning and load the jquery ponyfills only if the browser is outdated? Similar to what we do here: https://github.com/opencomponents/oc-client-browser/blob/master/src/oc-client.js#L351

Thoughts?

nickbalestra commented 6 years ago

100% on maintaining the API facade. We should also think about stuff like the exposed oc.$...
For polyfilling there are couple of ways we could go, I remember reading some time ago about the polyfill service built and mantained by the FT team and found that interesting. The registry could potentially, dynamically serve the bundle, perhaps could be an interesting path to investigate further? -> https://polyfill.io/v2/docs/

bassettsj commented 6 years ago

On API compatibility: Agreed I think we would need to maintain decent unit / integration tests for that. I think that would be a requirement or there would have to be just another browser client entirely. I think we could deal with the oc.$ by just making that still jQuery if it is available on the window or something.

Polyfilling: I really like the approach the stencil team is using for automatically feature detecting and loading only on demand. It might be a lot better to do feature detection over the FT approach of user agent sniffing.

Further discussions might be to invest some in modernizing build / tests as well if we are going to invest in the core.

Build: Grunt -> (webpack/rollup) - Publish esm and umd modules
Test: krama -> jest - Start adding tests using jest for new features while we move from karma

diessica commented 1 year ago

How is this going? Could lend a hand