https://hax.psu.edu is built entirely using web components, as well as the whole hax ecosystem. All of our "apps" are web components, haxcms being the biggest one which is entirely web components. I often get asked, how is this possible. So here's the questions asked as well as my answers from a recent Slack message in Apereo.
how do you manage state across an app made up of plenty of web components?
We only use web components. hard stop. "apps" become:
- more and more web components State is managed by MobX for a larger data store as in the case of hax editor or haxcms as app router is vaadin-router so it's also a web component in a singleton pattern
- Singleton patterns are used for things that would be good to check in with. For example dialog, tooltip, toast as obvious ones but less obvious would be translation engine, text editor highlight selection menu. Screenshot shows several sub-system style singletons that are in haxcms
- Theme are in effect web components that boil up to a single tag, you can actually modify them in any hax site by inspecting the DOM and typing the name of another known element and watch the state management not be impacted. It is a lot of abstraction of theme from store to make work but it's awesome 🙂 . The CMS is in effect, storing all the mobx / state work and ensuring that the router is talked to to generate the CMS content for the site
- Theme development gets into mobx in our docs - https://haxtheweb.org/documentation/developers/haxsite/data-store
how do you manage communication, if a web component instance used by another which is used by another (e.g. an form in a feed shown in a content area) needs to communicate with a web component that is a deep decendant of another (e.g. a statusbar inside a footer)
If things need to talk to each other the two common patterns we use above come into play. If it's integral to the app then a prop in a mobx store. Singletons can be called directly via requestAvailability call on the global window, or we'll use events for bubble up / communication sorta stuff. Click a button, button emits the simple-modal-show event, the singleton is listening on the window and reacts to the event. This can also just be collapsed items that bubble up a message with parents listening. When the elements are completely disconnected from one another, singleton has worked great so that we can keep things abstracted.
- You can read more about our i18n singleton here -- https://dev.to/btopro/i18n-in-web-components-2gii micro front-ends in our setup are also talked to via a singleton so - might be interesting stuff here -- https://dev.to/btopro/building-micro-frontends-with-vercel-lit-45oe
if you want to use lots of web components in your page and they are made up of web components, but 2 of them happen to have dependencies which use html snippets that use a tag, but both web components mean different web components with that tag... basically a name clash
You are correct. We have ensured we don't make clashing name space elements. There's patching to allow this in the spec and future spec work to make it native, but regardless we just don't get into name clashes. In part because of how we don't bundle our assets so we only ship 1 copy of (for example) lit. There are not multiple copies of lit in what sits on the CDN / local unbundled copy of assets.
- magic script talks about this process; we've enhanced it but use the same methodology invented in 2020 https://dev.to/btopro/part-1-how-penn-state-unbundles-web-components-for-cdn-deployments-20di
- Our monorepo helps make sure everything keeps in sync as well as our build scripts which compile everything in place using a fork of polymer CLI tools (deprecated but only thing I can find that provides the functionality) and then terser to minify in place - https://github.com/haxtheweb/webcomponents
Top comments (0)