The DevFest Nantes 2019 presentation of Building Complex Applications with Web Components is probably one of the most important to Lit developers; everyone references Justin Fagnani's presentation of how to do routing, lazy loading, and context management. The presentation includes a section on dependency injection: how an object can request its dependencies from other components higher up in the DOM tree.

One of the problems I have with the code as presented is that it fails to handle the case where the dependency supplier must perform some asynchronous work before sending the dependency to the requester. I'll show you how to extend the example to handle that, and what capabilities that extension gives you.

It's commonplace in Web Components to use custom events. The custom event type is an inheritor of the Event class, but it includes a new field, detail: any, that allows you to attach data to the Event, which is useful for passing data up to the listener, right?

Wrong. It's a trap. You could, theoretically, inherit from CustomEvent and narrow the content of detail to what you specifically want, and I've seen lots of code where people do exactly that.

But there's a better way: just inherit from Event. Skip the CustomEvent class and just create your own events. I'll show you how.

This blog post teaches an elegant way to isolate a complex Lit ContextProvider object in a ReactiveController, so you can compose it into multiple applications, and you can compose multiple different contexts into one application, without duplicate code or visual clutter. We tap into the host's lifecycle to correctly manage creating and populating and providing event listeners to handle context update requests.

It also shows how to write a Mixin to access that context without having to spam your entire app with context changes or force your developers to hand-write consumer code.

As a bonus, it includes both an elegant way to declare a base class with multiple mixins, and a nifty trick for creating truly private fieldnames without the Private Fieldname syntax, because the latter has a known performance problem.

I recently chose Lage to help refactor a monolith web application into a monorepo. Here's what I learned.

In my day job, I'm responsible for a fairly large web application of about 52,600 lines of TypeScript. In reality, that one web application is four independent major single-page applications and two minor ones, all of which rest on a classic collection of component library, server interface, and localization. It's getting a bit unwieldy to work in, and any edit cycle now takes about 25 seconds to rebuild the whole thing while working on it.

That's just a little too long in the era of hot module reloading. Plus it's hard to know where the boundaries are, and the guy I inherited it from cut a few corners here and there, stealing useful code across the hierarchy rather than re-arranging the hierarchy. I managed to disentangle the first-level dependencies a few months ago, so that no SPA is dependent upon something within another, and now the time has come to break it up into multiple workspaces. After looking through the list of possible tools, I picked Lage.