Gauge amount of work necessary to embed AGR pathway and/or ribbon widgets into AmiGO

[kltm]

We would like to see what compatibility issues there might be in getting some of the new widgets that have been written by GO for external groups embedded into AmiGO, namely the pathway widget and the ribbon. AmiGO is a very very old custom JS framework and we ran into some issue the first time we tried this (with react?). The idea would be to gauge how easy it would be to drop some react or web components in there and have them behave properly.

Closing this ticket would be a ballpark estimate of difficulty.

@pkalita-lbl

[kltm]

As discussed at the managers' call; adding for software essentials as it is research for gauging the possibilities of future projects. Noting that this is the research, not the actually final embedding (which we would want more user feedback for). Tagging @pgaudet

[kltm]

@tmushayahama Are https://github.com/geneontology/wc-ribbon and https://github.com/geneontology/wc-gocam-viz the correct resources for these two widgets?

[kltm]

@pkalita-lbl For the AmiGO side of things, it might be helpful to get a brief tour from me, either during one of the GO software calls (most Thursdays at 1pm) or as a one-on-one/small group at our convenience.

[pkalita-lbl]

That sounds good. I'm available during the GO software call time so if that makes one less meeting for you I'm all for it.

(Also hello 👋 from my work GitHub account)

[pkalita-lbl]

So far I can say that updates to the build process to enable integrating a typical, off-the-shelf Web Component or React component are pretty minimal and straightforward. I have a branch that shows a proof-of-concept with a few run of the mill third party components placed on the gene product details page here: https://github.com/geneontology/amigo/compare/issue-650-component-integration-demo

The key ingredient here is adding the babelify transform to browserify. It allows browserify (via Babel) to transform ES Module syntax (an increasingly common way for components to be distributed) and JSX syntax (although not strictly necessary for integrating React components it makes life easier and it's basically free once Babel is in the toolchain).

I tried using wc-gocam-viz as the Web Component injected into the page by AWebComponentThing.js, but I ran into a bit of trouble. The issue might be in the way that wc-gocam-viz is bundled and distributed. I'll need to take a closer look at that.

cc: @kltm

[kltm]

Talking to @pkalita-lbl , it looks like there might be a couple of strategies to move forward with what he's done so far that would 1) likely work and 2) not take too much time (discounting appropriate data loading for the moment). That said, there may be packaging changes that would make it all more natural, as mentioned above. Next steps would be exploring the cleaner path a little before making a final judgement for the roadmap.

[pkalita-lbl]

I pushed one more change to the issue-650-component-integration-demo branch which places the wc-gocam-viz widget on the gene product details page. There were two minor hurdles there:

1. I think version 0.0.49 of wc-gocam-viz was published incorrectly to NPM. The files referenced by the main and module fields of its package.json are missing from the installed package. To work around this I used version 0.0.48 instead. This is probably not a major thing to fix in wc-gocam-viz -- just a matter of documenting or even automating the correct publishing workflow.
2. In AmiGO (or any client that intends to require or import the package instead of using <script> tags) using the show-legend=true option is problematic because of how the legend image asset is located. It's possible for a client to use Stencil's setAssetPath and to copy the image file from node_modules to somewhere that's served statically. That seems like a lot of overhead for a client though, and I'd say we should look into solutions from the wc-gocam-viz side.

[pkalita-lbl]

Closing this issue because I think we've met the goal of understanding the level of effort to bring GO widgets into AmiGO.

Given the work that has been done in the branch related to this issue, the amount of work to required to add the pathway and/or ribbon widgets into AmiGO is relatively small. Assuming there are requirements about where to place the widgets (which pages and roughly where within those page layouts), the technical work would be:

1. Start with the changes in the demo branch and strip out some of the "exploratory" changes
2. Fetch any required information (i.e. GO-CAM IDs) from Solr on the backend and pass them to the frontend
3. Make front end changes to pick up required information from Solr; configure and place widgets according to requirements

1 and 3 are fairly small efforts. 2 is a little more unknown to me, but I assume there are some existing patterns to follow.

I should also say that all of my experimenting was done with the wc-gocam-viz widget. I assume that working with the wc-ribbon widget would be roughly similar.