Today I recognized an, at least in my eyes, weird behavior of the BindingBehavior in Aurelia. My use case was a group of badges showing the current filter criteria sent to the backend. Instead of showing a list of unreadable codes the API expected, I wanted to lookup the name in my master data dynamically. So I created a BindingBehavior which expects as value the filtered code and as additional parameter the type of master data where to look at.
(Quelltext, 8 Zeilen)
This seem to work or doesn't it? When the order of the filter types in the list remains the same this works quite well but when the order can change during user interaction the results become wrong. The problem here is that Aurelia reuses already rendered elements and just binds a listener to it's value to re-render the text node. This leads to the problem that the value for the lookup BindingBehavior will change but the additional parameter won't.
In my use case this happens all the time because the user can remove…
As stated in my last article, Web Components are a relative new way to build modern and reusable components. Even if the Web Components specifications are not implemented in some browsers like Firefox and Edge, there are ways to support them by using a polyfill. Aurelia itself is a single page application framework (SPA) which is based on the idea of Web Components. Some of you might ask: "Why do I need native Web Components when Aurelia provides the ability to use some of the main benefits out of the box?". The answer for this is pretty simple... Reusability :)
Since Web Components are native browser standards you can use them in general with any framework or library like Aurelia, Angular or even with React. This makes it easy for companies with multiple applications and frameworks to build components only once.
So how can we use Web Components in Aurelia?
In our example we will use one of the prepared aurelia skeletons ESNext + JSPM…
Web components are a relative new set of specifications which appeared at 2011 and aim for a better encapsulation and reusability of written components. These specifications consists of the Shadow DOM, Custom Elements, HTML Templates and Imports. Shadow DOM provides an API to work with an to the user hidden DOM tree, which enables the programmer to render his own elements like a native one. The Custom Elements specification defines the lifecycle a HTML element has, which is required to handle the element attributes and render the DOM of the custom element. There are two other specifications which describes how to import components into a document and how to define the component template. All of those play together to create super awesome web components :)
Here is a small example of a simple web component:
(Quelltext, 32 Zeilen)
And here is the usage of the component
(Quelltext, 10 Zeilen)
So why is not everyone using these awesome techniques already?
-> Because of the crappy…
2