jQuery as an optional dependency

[bassettsj]

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]

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]

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]

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]

• 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]

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.

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

[diessica]

How is this going? Could lend a hand