Building Framework Agnostic UI with Web Components

Editor's Notes

• #2: Hi everyone! My name is Piotr Nalepa and I’m really happy to speak here in front of such prominent group of fellow devs. Today I’m going to talk about building reusable user interfaces with Web Components. Before I start my speech I have a couple of questions to you: How many of you already know Web Components? How many of you actually tried to build some kind of UI or app with Web Components?
• #3: Let me introduce myself. Who am I? I’m a Senior Software Engineer at Auto1 Polska. We’re building the online marketplace for efficient buying and selling of inspected used cars. In short, it’s a platform for selling used cars. Apart from that, I’m also a blogger. I have my own blog which contains a lot of articles I’ve written since 2009. Quite long time, isn’t it? There you can read about CSS, JavaScript, even some PHP and bash stuff (old times). On my blog I’m sharing my knowledge regarding web development. I recommend to check it after this presentation. You’ll see the URL at the end of this slideshow presentation. In my free time, I enjoy watching and playing football a lot. I’m playing as a goalkeeper in futsal, because I’m not scared being hit hard by the ball ;)
• #4: Have you ever needed to build UI and reuse it in multiple projects? This is very common situation nowadays and there are many tools that can help to achieve that, for instance Bootstrap or Foundation. I bet you know them. Things like Bootstrap help to build user interfaces rapidly, but there are some caveats of using it: you have to be sure the CSS is loaded correctly. What does it mean? It means the styles have to be loaded in a correct order and they cannot interfere with your custom CSS styles in an unexpected way, like rules overriding. you have to be sure that the HTML code is implemented correctly, and you have to be sure JS is applied correctly to Bootstrap elements. These 3 things complicates development a bit. Have you ever been in situation that you implemented some Bootstrap code like in examples and it didn’t work? That’s what I’m talking about. In terms of UI build with Web Components there is one more win. You’re building UI that uses only native JS features, so they can be easily reused across many different projects, no matter the JS framework you’re using or if you’re using just vanilla JS.
• #7: Having many projects that accomodate similar UI sometimes make it difficult to stick with one selected library because of the project requirements or designs require something slightly different, but crucial from UI perspective, that haven’t been implemented in one library, but it might exists in another one. Oftentimes you might want to create your own, custom UI part of web app or website, but it leads to reinventing the wheel.
• #8: There are many UI libraries on the market. Among them Bootstrap and Foundation are ones of the most popular libraries. There was a time in the past that if you looked on the website design you already knew what tool it was built with. Now it had changed of course.
• #9: From my point of view the biggest challenge is to implement correct code samples in the correct way. By this I mean, implementing it inthe way it doesn’t force you to drop initial ideas for your UI, because a component from selected UI library is not flexible enough as you thought before.
• #11: Building universal UI elements that can be reused in many places, in many different projects is difficult. The main difficulty is to build elements that are flexible enough when implementing and cover most of the use cases.
• #12: Creating custom elements that look the same way no matter the project is another challenge. At the begining it’s easy to keep everything looking consistent. The problem begins after a longer time of development, when new requirements come. In such cases it’s extremely important to avoid making UI parts working only in some specific use cases and thinking you’ll fix it later. It’s also challenging to think about a possible use cases that have to be covered with a specific UI feature. Personally I believe that covering most of possible use cases at the beginning will pay off in the future, even if it take a bit more time to deliver a functionality.
• #13: As I mentioned it earlier, developers tend to reinvent the wheel with any new project. Smart developers see patterns and try to extract them as a kind of library for the future usage.
• #15: In the context of IT
• #17: Allows you to keep design consistency across the projects
• #18: There’s no need for extra code development.
• #19: Having already existing UI elements library makes it less time-consuming to use them.
• #20: Becuase of using browser-native features
• #29: Thre’s a biggest win and a difference from Bootstrap like libraries
• #35: Another big win
• #37: On this slide you can a code sample that is used to generate some basic custom element. I’m going to explain you in details in the next slides.
• #65: In this approach, the web application is broken down into its features, and each feature is owned, frontend to backend, by a different team. This ensures that every feature is developed, tested and deployed independently from other features
• #66: An approach to developing web application as a composition of small frontend apps. Instead of writing a large monolith frontend application, the application is broken down into domain specific micro frontends, which are self-contained and can be developed and deployed independently.
• #68: Each team owns a feature. It means,they can decide what tools to use in order to deliver a specific set of functionalities
• #69: Each feature app can be developed and deployed independently from other apps.
• #71: Each team should be able to choose and upgrade their stack without having to coordinate with other teams. Custom Elements are a great way to hide implementation details while providing a neutral interface to others.
• #72: Isolate Team Code Don’t share a runtime, even if all teams use the same framework. Build independent apps that are self contained. Don’t rely on shared state or global variables.
• #73: Independent deployment Just as with microservices, independent deployability of micro frontends is key. This reduces the scope of any given deployment, which in turn reduces the associated risk. Regardless of how or where your frontend code is hosted, each micro frontend should have its own continuous delivery pipeline, which builds, tests and deploys it all the way to production. We should be able to deploy each micro frontend with very little thought given to the current state of other codebases or pipelines. It shouldn't matter if the old monolith is on a fixed, manual, quarterly release cycle, or if the team next door has pushed a half-finished or broken feature into their master branch. If a given micro frontend is ready to go to production, it should be able to do so, and that decision should be up to the team who build and maintain it.
• #74: As a higher-order benefit of decoupling both our codebases and our release cycles, we get a long way towards having fully independent teams, who can own a section of a product from ideation through to production and beyond. Teams can have full ownership of everything they need to deliver value to customers, which enables them to move quickly and effectively. For this to work, our teams need to be formed around vertical slices of business functionality, rather than around technical capabilities. An easy way to do this is to carve up the product based on what end users will see, so each micro frontend encapsulates a single page of the application, and is owned end-to-end by a single team. This brings higher cohesiveness of the teams' work than if teams were formed around technical or “horizontal” concerns like styling, forms, or validation.
• #78: We should be able to develop a single micro frontend without needing to think about all of the other micro frontends being developed by other teams. We may even be able to run our micro frontend in a “standalone” mode, on a blank page, rather than inside the container application that will house it in production. This can make development a lot simpler, especially when the real container is a complex, legacy codebase, which is often the case when we're using micro frontends to do a gradual migration from old world to new. However, there are risks associated with developing in an environment that is quite different to production. If our development-time container behaves differently than the production one, then we may find that our micro frontend is broken, or behaves differently when we deploy to production. Of particular concern are global styles that may be brought along by the container, or by other micro frontends. The solution here is not that different to any other situation where we have to worry about environmental differences. If we're developing locally in an environment that is not production-like, we need to ensure that we regularly integrate and deploy our micro frontend to environments that are like production, and we should do testing (manual and automated) in these environments to catch integration issues as early as possible. This will not completely solve the problem, but ultimately it's another tradeoff that we have to weigh up: is the productivity boost of a simplified development environment worth the risk of integration issues? The answer will depend on the project!
• #85: Follow the rules. And there’s also one more win!
• #86: When following micro frontends approach with Web Components