Syndesis: POC loading atlasmap or apicurio via custom element.

[gashcrumb]

This is a...

[ ] Feature request
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Documentation issue or request
[*] Research

We need to evaluate the feasibility of loading external components like atlasmap or apicurio using a custom HTML element rather than integrating external components through angular's boostrapping mechanism like we do currently.

Ideally a simple web page that doesn't use angular could use this custom element to display either of these external components. Bonus points for using some other web tech like react or vue or something.

[gashcrumb]

Example code from micro-frontends to take a look at -> https://github.com/neuland/micro-frontends/blob/master/1-composition-client-only/team-green/fragments.js

[gashcrumb]

Make sure to read the text under "How to Create a Custom Element?" on https://micro-frontends.org/ unfortunately i can't see a way to link to this directly, there's some gotchas in there to watch out for.

[gashcrumb]

Other option would be to just POC this right in syndesis as well, but either way, that might be too complicated up front. Were I to do it in Syndesis I'd replace this line -> https://github.com/syndesisio/syndesis/blob/master/app/ui/package.json#L52 with probably just a local repo with the custom element wrapper.

The one spot it's currently used is here and there's only a couple bits of data to share, the input API schema and then a change callback.

Then ideally we could get rid of these and replace this, probably could have an onChange event generated with an updated output?

Also this line and related stuff could go too...

[gashcrumb]

@riccardo-forina CC

[aileenc]

Why would we not migrate Apicurio and AtlasMap to React as well?

[gashcrumb]

This isn't saying that couldn't happen, this is more about isolation, i.e. avoid lots of touch points for external components so that the external component doesn't have to stay in lock step with the main syndesis UI framework choices. At least in theory.

[seanforyou23]

Alrighty - I can finally say.. we've done it. By _we_ I mean largely @riccardo-forina and @kahboom :)

The high level take away for me is that custom elements (along with Shadow Dom) afford us a lot in terms of namespacing functionality/styling and avoiding conflicts with other modules in a same app, but packaging/managing the isolated dependencies turned out to be much more of the challenge here.

To really take this solution all the way would require more work on atlasmap/apicurio to restructure them in a way that's inviting to this type of integration. A good bit of work toward this is already in place for atlasmap on the kahboom-atlasmap-wc branch mentioned below - and now that we've been through the meat of this process, doing this again for apicurio wouldn't be near as much effort.

You can see it in action by pairing the following two feature branches.

https://github.com/seanforyou23/syndesis/tree/react-ui and
https://github.com/seanforyou23/atlasmap/tree/kahboom-atlasmap-wc

The main issue we're still facing is that the event binding doesn't work out of the box, so even though we were able to successfully import atlasmap as web component, at the moment you can't do much more than look at it.

I will demo this work tomorrow, and can go into more detail then - but of course feel free to share any questions or comments here so we can keep the discussion open for everyone.