In an effort to make
Now, there’s four really good reasons for doing this.
First of all, the way b8r’s HTML-based components work intrinsically involves using
eval (it actually uses the AsyncFunction constructor, but same difference). Whether this represents a real security threat or not depends a lot on how those components are in fact loaded, but it’s definitely an argument.
Second — and this has proven a small but persistent pain point with b8r development — it makes linters happy. To begin with, the
<script> tag inside a component was actually the body of an async function with a ton of parameters. Using these parameters without annoying the lint gods involved /* global … */ to be added at the top of the scripts, while the fact that — for convenience — the code was async meant that linters would scream about use of
Third — with HTML components, defining a single global controller for a family of components involved some jumping through hoops as did, for example, using computed bindings or lists where the method was registered in the component body (this works fine, but generates error messages if you don’t programmatically add the bindings after the necessary methods are registered). Now you can just do the necessary work outside the component definition (but in the same file!)
Fourth — while b8r has moved over to the world of ES6 Modules, it is distributed in cjs form for those still living with
You are still writing CSS as CSS and HTML as HTML, but now it’s likely going to be inside back-ticks.
In addition to the four big arguments for building components this way, there are some further implications (mostly good).
First of all, if and when you need to use
import() inside a component, you can use relative paths without wondering “relative to what” (it used to be the location of b8r.js, because that’s where that code ends up executing).
Next, there was no convenient way to create multiple components in one source file. This is a mixed blessing — making it easy to define lots of small components in source files with no relationship between file name and component name presents the real risk of name-clashes. It may become necessary to introduce lint rules that prevent you from creating a component whose name does not match its source file in some way.
Finally, a really nice side-effect of this is that the boilerplate for a component is a lot more self-explanatory than it used to be. Yay!