I usually have a default api root path... defaulted to /api... then I proxy /api in my dev host to my ui api instance... on deployed serviers/services, it's similar, where the load balancer will reroute the /api base path... or /api/v1.0.0/ etc in larger apps.
Often creating a tightly coupled api service for the UI, separated from any data services behind that.
I also set it to look for globalThis.__API_BASE__ that can be injected into *.html at build or deploy for other environments where a reverse-proxy is either a bad idea (S3, etc).
Beyond this, when the loading takes more than a second, I'll have the default html (especially in SPA) render a loader div along with the css for that loader... This renders the first part quickly, while being able to run updates as other pieces dynamically load in the beginning. /api/v.../features as an example, that is feature flags and config options that will inform other loaded items... dynamically loaded components, for example.
I think the biggest issues with form components is the styling to integrate modern toolkits. I really like bootstrap, I also like mui, and that's about all I really like as far as web based components.
Beyond this, just checked, seems like every browser in wide use now supports WebComponents, which is very cool. May have to start playing with it again. Previously, the shims needed were just crazy huge to say the least. Not too fond of many smaller downloads, but would be cool to create something modern-like without too many external libraries.
Would *REALLY* prefer to see an actual instruction writeup of the content in addition to, or even instead of the Video. When looking for answers for stuff like this, you don't always want to sit for a video for something that could be mostly copy-paste from an actual article.
Nice: It's worth noting that if you don't push to your repo regularly, it will stop running the cron jobs after a while, iirc 90 days. So it's not the most reliable thing for inactive builds.
NOTE: this will emphatically not work as expected when dealing with unicode or surrogate modifiers. Realistically if you're using anything other than US-ASCII, tread carefully.
TLDR; add TypeScript type annotations support directly to JS.
It might be a good idea, would also support a pragma statement near the top of a file to support JSX transforms in the box as a standard.
WARNING: GPLv3, can be argued that any application using this library must also be GPLv3, if you're serving this library on the internet, your entire application must provide source on request.
I tend to use the following library (MIT License): https://www.npmjs.com/package/mui-icons
Which wraps svg icons in a consistent way, compatible with the mui frameworks. Provides access to several icon libraries including an expanded set of material icons (cmdi).