11. Global Space

There is one important aspect to address before concluding this chapter. When you use widgets in a WEM project, the WEM runtime will render these widgets within the page, and the styles and JavaScript associated with the widget will be added in a global context. Therefore, you must be careful when naming your CSS selectors and JavaScript identifiers, just as you would when building a standard website.

While there are modern solutions to this issue, WEM does not yet support all of them. In later chapters, we will explore these solutions in greater detail. For now, let's take a brief look at the potential issues.

CSS

In CSS, naming collisions occur when two or more styles are defined with the same selector. This can lead to unexpected results, potentially overriding earlier styles. For example, consider the following:

// Bob's button widget
.button {
	background-color: tomato;
}

// Jane's button widget
.button {
	background-color: lightgoldenrodyellow;
}

Design systems like Bootstrap often use simple class names such as .btn or .alert. This is because you typically want to incorporate one design system per website. However, widgets are not design systems, and as demonstrated in the example above, it is easy to create conflicts when using generic names.

JavaScript

When using JavaScript in your widget, you must be cautious when naming your functions, classes, and variables. If you are not careful, you may inadvertently override them, leading to undefined behavior in the widget's functionality. For instance:

// Bob's button widget
function clickHandler() {
	console.log("My name is Bob.");
}

// Jane's button widget
function clickHandler() {
	console.log("Jane here!");
}

In this example, clicking Bob's button will log "Jane here!" to the console. While this may seem like a harmless example, it is not the expected behavior. There are multiple ways to address this issue, but they are beyond the scope of this chapter.

WEMscript

The scriptreference statement is also susceptible to naming collisions. Consider the following example:

<? 
	/* In Bob's button widget */
	scriptreference "button" FileUrl(@ButtonJs) 
?>

<? 
	/* In Jane's button widget */
	scriptreference "button" FileUrl(@ButtonJs) 
?>

It is important to note that it does not matter that both use @ButtonJs as the same reference name, as this is a local variable of the widget. However, using "button" as a namespace is too generic. In this case, it will not override other functionalities but will instead use the script that has already been registered under the name "button". Another statement that has the same issue is called scriptmodule, which we will discuss in later chapters.

How to Solve

There are various ways to address these issues, with some solutions being better than others. One simple approach is to avoid using generic names like button. Instead, use a format like yourcompanyname-componentname to make it less generic. In CSS, you would have something like:

.janescompany-button {
	background-color: tomato;
}

In a scriptreference, you would write:

<? scriptreference "janescompany-button" FileUrl(@ButtonJs) ?>

This is just one of the possible solutions, and there are many more depending on the context. I have also omitted a solution for JavaScript, as that topic requires a dedicated section of its own, which we will explore in later chapters.

Conclusion

For now, it is essential to remember that you should avoid using generic names unless you are absolutely certain of what you are doing.

Now that you have learned the basics of building a widget, we also need to discuss the risks and responsibilities involved in this process. The next chapter will be serious but very important!