How did you go about establishing structure and patterns that are typically enforced by frameworks? Was Web Components a big piece of that or were there also other major patterns you incorporated?
Great question. WC doesn’t provide any architectural structure beyond code encapsulation for your UI widgets. But this alone gets you per-feature sandboxing, even more strictly if you use the shadowdom to get runtime isolation as well (I typically don’t, but it’s a good fit for many solutions). This allows you to move ahead pretty quickly, knowing you can tear out and replace these elements easily if you got it wrong or the needs change, without core changes to the app. Yes, you still need foundational services like data access & caching, personalization, etc, which sit outside of WC, but the “best way” for those things is typically very tied to what you’re trying to build. So for those, I typically just start with a functional “sketch” of each service with a lot of code separation, and let the architecture emerge through iterations of refactoring as I start to understand what I need. The biggest refactor problems tend to have to do with precedence of rules and order of code execution, with the biggest issues at initial load as arrival scenarios get more complicated. But no framework is going to solve those problems optimally for your app, and more likely, the frameworks create more obstacles to doing it well. And then there’s always the problem that your devs need to be really knowledgeable in the framework to not apply it badly.
>How did you go about establishing structure and patterns that are typically enforced by frameworks?
I know PHP gets a lot of flak, but I think this is an excellent example of how that can be accomplished from a backend perspective using proven libraries.
In the example, the developer uses a library for most of the main features e.g. flip/whoops and FastRoute. By pulling together these libraries, in effect, they have created their own framework have they not?
generally I do this:
* make components that take responsibility for a bucket of concerns: like the app (track the app state--user, etc); then views (generic pages, more complex main-section things, etc); then more granular composable stuff like a highly specialized button (arbitrary example);
* communicate state changes up via events, for global or highly generalized coordination between anything just handle that on the window/self (setup/undo on the component lifecycle methods); send/intercept/capture these messages on the event.detail (use composition and bubbling);
* stick to first-principles: KISS, YAGNI; don't over-engineer your stuff, use encapsulation, if you don't need a shadowRoot it's not required, or use slotting..., use global styles where that's appropriate, use shadow encapsulation of styles where that's separately appropriate--keep those concerns separate and use common sense about appropriate separation of concerns;
* don't automate or use external libraries or anything fancy unless it has a clear self-apparent business case (for my work or the customer or the business); forget all the assumptions of the frontend community--it's mostly noise
