Option to force use canvas/disable shadowroot and webcomponent

[josh-hemphill]

A continuation of #316

To review, In large apps, each section needs to be able to load and unload its dependencies since other portions of the app often have no need for most of them. Having some way to keep it out of global scope and make sure everything can be dereferenced so the garbage collector can clean up after it.

Right now WebComponents can only be defined, but not deleted, scoped, or replaced; once you assign a class to that custom component, there's no way to clean up all the code attached to it. So having a configuration option to force the use of canvas would be helpful.

I briefly looked at trying to implement this when I was doing #319 , but anything I did to try and bypass Shadowroot or customComponents caused everything to break in weird ways.

[TonyGermaneri]

The project was written first as a web component, so not surprising. I think the only things that make it register globally are the window.canavaDatagrid assignment and the web component registration. Shadowroot should be able to be kept without polluting the global scope. What errors did you get from removing window.customElements.define('canvas-datagrid', Grid);? I think that's the only line you'd have to remove to stop the web component from registering. The window assignment is pretty easy to prevent.

I'm very pro your cause here, I hope we can figure it out.

[ndrsn]

Perhaps we should consider a separate build target/output for the web component version? That way we would not have to (conditionally) pollute the global namespace for environments that will not be using that version.

This ties into the idea of having individual wrappers for different uses of canvas-datagrid: Vue, React, or web component. It would introduce a breaking change — unless we have some kind of transition period where we support both? Meaning, perhaps let the default export (canvas-datagrid.js) behave as before, but add additional build outputs, and eventually phase out the use of lib/main.js as entry point for the build.

[josh-hemphill]

I might look into creating a separate entry file. That might also give me some ideas how to resolve the remaining eval. A separate entry file I think makes a lot of sense, since there would be no point in changing the initialization after it's been initialized, and that decision is made at the level of the project being written.

[josh-hemphill]

I've started working on this. Got a little sidetracked while setting up the rollup to do the multi-entry; @ndrsn would you be open to a PR for ndrsn/is-pritable-key-event to use rollup to create an ESM compatible output? It would mean I could get rid of 1 of the rollup plugins, it shouldn't affect the webpack here since it should still be resolving based on the package.json main property.

On another note around multiple bundles and inputs, a solution to whole eval class issue, and cross-browser compatibility in general would be to have both a normal UMD bundle and a UMD bundle that injects a lot of Babel polyfills for class and maybe even custom component.

[ndrsn]

Just saw this now:

@ndrsn would you be open to a PR for ndrsn/is-pritable-key-event to use rollup to create an ESM compatible output?

I wouldn't be opposed to this, but seeing as how TypeScript can output ESM, and I don't believe any projects other than canvas-datagrid use it, I think it would be nicer to reconfigure TypeScript. Maybe we can even get rid of webpack?

[josh-hemphill]

I agree, I wrote this before looking at the typescript migration.