More Related Content
What's hot
What's hot (20)
Recently uploaded
Recently uploaded (20)
Ember & WebComponents
- 2. A brief introduction What are WebComponents?.
- 5. Light-Weight
- 9. Private
- 12. Light-Weight Why WebComponents? Cross Framework Private
- 15. Useful Addons* * Shameless Self-Plug https://github.com/alexlafroscia/ember-cli-stencil https://github.com/alexlafroscia/ember-wc-utils
- 18. Questions?
- 19. Thank you.
Editor's Notes
- Today I’m going to talk a bit about WebComponents and using them in Ember.
- Let’s start with talking about what WebComponents are. WebComponents are a means for developers to create components that are native to the browser. Instead of being tied to a framework like Ember or React, these extend from the built-in HTMLElement class, and like other HTML elements, can be used in any framework. As Ember developers, we’re familiar with the basic idea of components and why we want to use them. They let us create boundaries in our templates to encapsulate logic with explicit inputs and outputs -- namely, properties in and DOM out. This helps is re-use code throughout a single application or, if we’re lucky, across many. In order to have a discussion point, let’s take a quick look at a basic WebComponent implementation.
- Here’s a screenshot of something I put together in CodePen. If you want to open it up for yourself, you can check out the bit.ly link down at the bottom. To summarize, we define a component that renders a greeting based on the name attribute of the element. But let’s step through the code together to make sure we’re all on the same page. Starting down here with the JS file, we define a class for our new component. The constructor is pretty basic -- don’t worry about the attachShadow bit for now, we’ll come back to it. connectedCallback is the WebComponent equivalent of didInsertElement and is where we can read the name value that the user set, and create the contents of the component. Finally, down at the bottom we map the name-tag element to the class we just defined Above the JS we have a bit of HTML and CSS for the page, setting up some global styles and the page content, which uses our new element. We’ll dive into the details a bit more later, but to illustrate what it means to create your own HTML elements, I want you to focus on this part here. <advance animation> This doesn’t look all that different from what you may have seen with other web frameworks. You have a custom name for your component and can pass it properties to customize it. But in this instance there isn’t React or or Ember under the hood here making that work; that’s just an HTML file. Anywhere that a regular DOM element would be valid, our new name-tag element is too.
- Since Ember already supports its own components, let’s talk a bit about what sets WebComponents apart and why you might choose them over Ember components. There’s three main characteristics of WebComponents I want to dive into. Light-Weight They work across across frameworks Privacy features missing from other types of Components
- Let’s start with “light weight”. I’m sure you’ve heard this term describe lots of things, but what does it even mean, right? I’ll offer a definition that works well for WebComponents.
- Going back to the example component we saw before, the entire implementation is 17 lines of code, including the template and styles. Since they are built on top of primitives provided by the browser, they can be shipped to users without dependencies. So, if a tiny payload is what you’re after, WebComponents can be an excellent way to achieve that. Additionally, WebComponents can be lazy-loaded even in environments like Ember where lazy-loading isn’t a built-in feature. This way, the majority of the code is only downloaded once the user actually needs it.
- Another big benefit to writing WebComponents is that they work with any framework. This is less of a concern if you’re only writing Ember apps, but at many companies -- like here at Netflix -- there are applications written in Ember, React, Angular, Vue, whatever. Just like we take for granted that we can use a DIV in any templating language, a WebComponent can also be used anywhere that supports HTML. This works great for components that need to be shared across teams, like a design system implementation.
- A great example of an open-source project leveraging WebComponents for cross-browser support is Wired, a set of WebComponents that define these really interesting hand-drawn elements that are prefect for prototyping. Rather than creating React components specifically, authoring in WebComponents allows them to support any framework, or none at all. They can still maintain a great experience for React developers while also being inclusive other communities.
- The last major feature that makes WebComponents different is the ability to leverage ShadowDOM in WebComponents. ShadowDOM is a feature that has been introduced into Chrome and Safari over the last year or so, with support from FireFox and Edge planned for this year. It allows you to create a DOM tree within an element that is isolated from the tree outside of it. This isolation created a boundary that CSS styles can’t pass through, meaning that the inside of your component isn’t affected by global styles. Styles defined inside of the component also are prevented from affecting anything outside of the Shadow DOM.
- If we take a look at our example component again, we see that the template is inserted into the “shadowRoot” of the component. We have some global styles that would normally bleed into the component and set the color, but with Shadow DOM they don’t. Plus, the styles defined inside the component, setting the color to red, only affect the paragraph inside the component, not the one outside. It’s common these days to use build tools to achieve this effect. Ember addons like Ember CSS Modules or Ember Component CSS allow us to scope styles to a specific component by namespacing them at build-time. Shadow DOM allows us to achieve the same effect without any build-time concerns.
- If we look at the actual DOM tree we can see this isolation in action. In the top example, when exploring the DOM, we only see the “shadow root” where the private inner contents are stored. From the outside context, these elements do not exist. This means that DOM APIs that query for elements also don’t return anything inside of the Shadow DOM, making it difficult to alter their contents from the outside. If we open the shadow root in the inspector, shown in the second example, we can find the content that we inserted there, including the CSS styles for the paragraph tag.
- So if these features are compelling for you and you’re ready to try building some yourself, where should you start? You can always just write them manually, like the example code we’ve look at, but there are also tools that can make the development process easier. After looking at a bunch of the tools out there, I’ve come to really like Stencil.js.
- Stencil is written by the Ionic team, the authors of the Ionic hybrid app framework or their popular Ion Icons. Stencil’s values seem very much in line with Ember’s. They lean on conventions for their folder structure, have a focus on testing, and give you a build system out-of-the-box so you don’t have to get bogged down in configuration. Some other things I’ve really come to appreciate are support for Sass and TypeScript, lazy loading enabled by default, and automatic polyfilling for browsers that don’t yet support all of the required APIs. You can really just focus on creating great components and lean on Stencil for the complicated parts.
- Let’s take a look at the same name-tag element, this time build with Stencil. Right off the bat, you notice we’re working with TypeScript, which is supported by default by the Stencil build tools. Our class is decorated by the base Stencil implementation, which defines the name of the tag, the filename for the stylesheet, and whether or not to render to ShadowDOM. We’re explicit about what properties are expected and what their types are. There are additional decorators provided by Stencil for emitting events, defining observers, and creating public methods that can be called on the element. Down at the bottom we define a render method that returns a JSX template, which will feel very familiar to anyone with experience in React. Lastly, we can define our styles in a separate stylesheet, where Sass is supported. That file will be compiled to regular CSS by Stencil’s build tools and inserted into the ShadowDOM for us. Stencil’s build tools are able to compile a set of elements like this into a JavaScript package that is easily imported by tools like Webpack or the Ember CLI or linked to with a script tag. While you do have to pay for the overhead of the Stencil library itself, the improvements in development experience may be worth that cost.
- The last things I’d like to touch on is using WebComponents in Ember applications. For basic components like the first one we looked at, you can simply define the WebComponent in a JavaScript file and start using the custom element in your templates. If you choose to use Stencil for your own WebComponents, the “ember-cli-stencil” addon that I created handles finding Stencil components in your dependencies and will automatically pull them into your JavaScript bundle while maintaining support for lazy loading. It also handles setting up some boilerplate required to let Ember know about events your Stencil components may emit. The only snag you may run into is around binding event handlers on WebComponents.
- Much like Ember Components practice “Data Down, Actions Up”, WebComponents practice “Data Down, Events Up”. In this example, we use the element modifier form of the action helper to execute the greetZoey action when the greet event is fired. Prior to Ember 3.1, some assumptions made in the Glimmer compiler broke the ability to do this. As part of the initial angle-bracket Ember component support, anything that looked like an Element containing a hyphen was treated as an Ember component, which don’t support element modifiers. The above template won’t even compile. Now that angle-bracket components will come to Ember with a CamelCase identifier instead, Ember 3.1 was able to fix this issue.
- If you want a decent work-around solution for older Ember versions, the ember-wc-utils addon includes a helper component that can catch the events for you so that you avoid the error.
- I’m happy to take any questions that you may have now or chat afterwards.
- Alright, thanks!