Web Components in Action
eBook - ePub

Web Components in Action

Benjamin Farrell

Share book
  1. 432 pages
  2. English
  3. ePUB (mobile friendly)
  4. Available on iOS & Android
eBook - ePub

Web Components in Action

Benjamin Farrell

Book details
Book preview
Table of contents
Citations

About This Book

Summary Web Components are a standardized way to build reusable custom elements for web pages and applications using HTML, CSS, and JavaScript. A Web Component is well-encapsulated, keeping its internal structure separate from other page elements so they don't collide with the rest of your code. In Web Components in Action you'll learn to design, build, and deploy reusable Web Components from scratch.Foreword by Gray Norton.Purchase of the print book includes a free eBook in PDF, Kindle, and ePub formats from Manning Publications. About the Technology The right UI can set your sites and web applications apart from the ordinary. Using the Web Components API, you can build Custom Elements and then add them to your pages with just a simple HTML tag. This standards-based design approach gives you complete control over the style and behavior of your components and makes them radically easier to build, share, and reuse between projects. About the Book Web Components in Action teaches you to build and use Web Components from the ground up. You'll start with simple components and component-based applications, using JavaScript, HTML, and CSS. Then, you'll customize them and apply best design practices to maximize reusability. Through hands-on projects, you'll learn to build production-ready Web Components for any project, including color pickers, advanced applications using 3D models, mixed reality, and machine learning. What's inside

  • Creating reusable Custom Elements without a framework
  • Using the Shadow DOM for ultimate component encapsulation
  • Leveraging newer JS features to organize and reuse code
  • Fallback strategies for using Web Components on older browsers


About the Reader Written for web developers experienced with HTML, CSS, and JavaScript. About the Author Ben Farrell is a Senior Experience Developer at Adobe working on the Adobe Design Prototyping Team. Table of Contents

PART 1 - FIRST STEPS

  • The framework without a framework
  • Your first Web Component
  • Making your component reuseable
  • The component lifecycle
  • Instrumenting a better web app through modules

PART 2 - WAYS TO IMPROVE YOUR COMPONENT WORKFLOW

  • Markup Managed
  • Templating your content with HTML
  • The Shadow DOM
  • Shadow CSS
  • Shadow CSS rough edges

PART 3 - PUTTING YOUR COMPONENTS TOGETHER

  • A real-world UI component
  • Building and supporting older browsers
  • Component testing
  • Events and application data flow
  • Hiding your complexities

Frequently asked questions

How do I cancel my subscription?
Simply head over to the account section in settings and click on “Cancel Subscription” - it’s as simple as that. After you cancel, your membership will stay active for the remainder of the time you’ve paid for. Learn more here.
Can/how do I download books?
At the moment all of our mobile-responsive ePub books are available to download via the app. Most of our PDFs are also available to download and we're working on making the final remaining ones downloadable now. Learn more here.
What is the difference between the pricing plans?
Both plans give you full access to the library and all of Perlego’s features. The only differences are the price and subscription period: With the annual plan you’ll save around 30% compared to 12 months on the monthly plan.
What is Perlego?
We are an online textbook subscription service, where you can get access to an entire online library for less than the price of a single book per month. With over 1 million books across 1000+ topics, we’ve got you covered! Learn more here.
Do you support text-to-speech?
Look out for the read-aloud symbol on your next book to see if you can listen to it. The read-aloud tool reads text aloud for you, highlighting the text as it is being read. You can pause it, speed it up and slow it down. Learn more here.
Is Web Components in Action an online PDF/ePUB?
Yes, you can access Web Components in Action by Benjamin Farrell in PDF and/or ePUB format, as well as other popular books in Diseño & Diseño web. We have over one million books available in our catalogue for you to explore.

Information

Publisher
Manning
Year
2019
ISBN
9781638350705
Topic
Diseño
Subtopic
Diseño web

Part 1. First steps

You’ve probably been hearing more and more about Web Components lately. Much of this has to do with all the major, modern browsers now supporting them in recent months. This includes Microsoft Edge, because you can already download a developer preview while we wait for the official Chromium-backed release. It can get a bit confusing when you look deeper to see what Web Components actually are, though!
Not only has the collection of standards that make up Web Components changed a little over time, but, in reality, a Web Component can be created with Custom Elements alone! You can create your very own element that sits on your HTML page just like any other browser-provided one. More importantly, by using the Custom Element API, your element can be given custom logic to be a made a fully featured, tiny interactive component that looks simple from the outside and can work together with any other element on the page.
The first part of this book will zero in on how to create your first custom elements, as well as explore some best practices around them. At the end of the first part, even just exploring this one concept, you’ll be making Web Components that are actually useful in real-world situations, even allowing them to be wrapped up as a single piece managing its own dependencies, perhaps including other nested Web Components, ready to be dropped onto an HTML page.

Chapter 1. The framework without a framework

This chapter covers
  • What a Web Component is
  • The Shadow DOM
  • Custom Elements
  • Polymer Library and X-Tags
  • ES6/ES2015 language features
Hello, and thanks for reading Web Components in Action! I’ve been using Web Components for a few years now on just about every web development project I’ve had.
As web developers, it’s our job to choose the right tools for any given project. This can get complicated, because it’s not just the project’s immediate needs that matter. Your team’s needs do as well, as do whether the project is part of a bigger ecosystem at your company, how it will be maintained, and how long it will need to be maintained. The list goes on.
Of course, these decisions aren’t unique to web developers, but one major difference between us and many software developers is that the web community has put out an astounding number of tools, libraries, and frameworks. It can get difficult to keep up with all of them—so much so that “framework fatigue” has been a topic of conversation for some time now.
Adoption of these new tools seems to happen at lightning speed. Putting aside frameworks for a moment, even something as niche as task runners for building your JavaScript (JS) projects has changed dramatically over the past few years. I’ve seen the switch from Grunt in 2012 to Gulp just a couple of years later, and now there’s a tendency to go minimal by using the Node.js NPM (Node Package Manager) to run build scripts. Speaking of package managers, we developers have waffled between NPM, Bower, and Yarn for running our frontend dependencies.
Build tooling and package managers are one thing. They are small but significant pieces of our web development workflow. Yet this same churn is happening with how we actually build our applications and UI, which is arguably the most central and important part of web development.
For individual developers, this can definitely be hard to keep up with, although it’s exciting to learn a new framework or library. Some have a steeper learning curve than others, and, in many cases, you’re learning the framework’s “system” as opposed to fundamental HTML/JS/CSS concepts.
As a developer on a team or in a company, there are additional challenges. At the start of a project, you’ll need to agree on what tools you’ll use to develop with over the lifecycle of the project. This includes build tools, testing tools, and, of course, any frameworks or libraries. Not everyone will agree on the best choice. If the team is large and working on many projects, it can be tempting to let developers on each project pick their own tools. After all, it’s good to analyze the needs of the project and use the appropriate tools. But this also ignores the inevitable, when developers must work together to create common pieces of UI or integrate a newly adopted design system that is mandated companywide. Eventually, using different tools and frameworks may come back to bite your team.
If everyone agrees, begrudgingly or not, on the same framework, things can be great for a while. Even then, two or three years down the line, the framework can become dated. Using older technology begins to feel a little stifling, especially to junior developers on your team who want to keep their skills up-to-date with the rest of the web community. At this point, your organization is faced with the choice of redoing the entire technology stack using a new framework or keeping the old one and facing the perception of not being an innovative place to work.
It’s a difficult problem and decision for sure! The question that begs asking, of course, is “What’s the alternative?” I’ve talked to quite a few people who want to break free of the constant framework churn for a variety of reasons. “Why can’t we just use plain HTML, JS, and CSS?” is a common question. One of the biggest benefits of not buying into a framework is being able to focus on core web development concepts rather than learning framework-specific skills that may or may not transfer to the next popular framework. Another huge benefit is being able to try small libraries and microframeworks that solve specific needs in your project. The barrier of entry to these, and even new frontend build tools, is much lower given that you aren’t fighting a specific development environment provided by the latest popular framework.
Modern frameworks are extremely useful and solve some big problems, but why don’t we hear more about using so-called “vanilla JavaScript,” given developers’ desire to try other things? We do, to some extent. Consider this poll by the State of JavaScript, conducted in 2017: https://2017.stateofjs.com/2017/front-end/results/. You’ll note that no-framework development is second in popularity, behind only React.
However, we don’t know specifics on why folks claim to prefer no framework, or vanilla JS. What kinds of things are those developers building? What tools/processes are they using? I’d be curious to know if they build a framework of sorts themselves to make up for the lack of structure and code organization that modern frameworks usually provide.
This last point about structure and code organization is why no-framework web development has been a nonstarter for me in the past, and it’s why I’ve always turned to the latest framework. Without structure, your code becomes spaghetti. Maintaining and writing new features can be madness without predictable project organization. Nevertheless, I wanted to break free of big, all-encompassing frameworks; when I saw Web Components for the first time, I saw a huge opportunity to do just that.
So . . . how? To really tackle this question, we need to understand what Web Components really are. Before I get into the specifics, we’ll use a browser’s date picker as an example we’ve all likely come across. While it’s not a Web Component, per se, it’s a similar concept if you peek inside.

1.1. What are Web Components?

The popular modern frameworks of today largely offer code reusability in the form of components or modules. Generally speaking, these are shareable and standalone pieces of code (HTML/JS/CSS) that offer visual style and interactivity, and possibly have an API or options you can set to offer customization.
Think about what’s already in your browser. And consider that we already have reusable, modular pieces that offer style and interactivity, and come with an API.
Of course, I’m talking about HTML tags or DOM elements. These are rendered in the DOM and have a specific type of functionality. A <div> tag or <span> tag is fairly generic and is used to hold text or a mixture of elements. A <button> or an <input> element is more specific in functionality and style. Whe...

Table of contents