Plugin content/state needs to be globalized

[gregoryjjb]

... but I can't just slap the whole plugin in the global store, as there's functions in there. This leaves two issues:

1. Choosing what goes in the store and what stays local on the component
2. How it gets into the store.

Regarding 1: I could have an array of "plugin data" in the store like name, description, etc, that doesn't contain any functions. Using that data in the store the plugin component/container could load the rest of the plugin itself. This could result in possibly multiple dynamic imports of the same file (it gets imported and serializable parts get stored, then it gets loaded again in the local component) but this may not be that bad.

Regarding 2: currently the loaded plugin is determined by the URL, eg localhost/COM4/LTC1234. I am considering only using the port in the URL (localhost/COM4) and getting the part number from the global store but I feel like there could be drawbacks to this. I think that storing more plugin info in the store would remedy the problems somewhat.

[gregoryjjb]

Solution so far:

1. All pieces of the plugin go under a component that knows the port (gets it from the URL)
2. This component does the import and passes the entire plugin object to the (traditional) plugin and stores the serializable part in the global store
3. This component also passes the port to containers for the graph and serial monitor, which use the port to grab the appropriate plugin and serial info from the store.

[JeremySorensen]

I think you are right to not have the hardware in the URL