Saturday, 27 October 2018

The seemingly weird way in which styles are handled with CSS modules.

The first time I worked with code that used Webpack's CSS modules I didn't quite understand why it did what it did.

It turns out there is a reason why Webpack handles styles with CSS modules this way (...well obviously) and I learnt of it only recently.

For those of you who aren't familiar with what CSS modules is, here's the gist of it:

1. You write up your CSS.


2. Import your styles, inject it into your component.


3. Webpack then rewrites your class to look like this

post_postTitle_xb4ac

The class above consists of three parts separated by underscores. The first is the parent class, the second, the class added to the current component and the third is a hash.

So the question is why would we want to handle our CSS this way?

The answer...encapsulation.

The three parts mentioned above, combined, creates a class that won't conflict with other components. This means that when you write out your components in react and you add styles to them using CSS modules, the styles you apply to one element will be applied to only that element and won't spill over into another element.

This makes it easier to maintain your CSS when your application begins to grow in size. You won't have to worry about having to namespace your selectors to prevent styles from one component ending up on another.

The CSS modules technique is also probably a way of mimicking the style encapsulation that the shadow DOM provides by default. With the advent of web components and with the way frameworks that use web components use the shadow DOM you'll notice that this is becoming the preferred way of writing CSS (ie. having CSS scoped to its component).

It turns out all you need to work with CSS modules is a CSS module compiler. With Webpack this functionality is available and only needs to be enabled by way of configuration.

There seem to be other options too like this one here:
https://github.com/gajus/babel-plugin-react-css-modules.

Hope this post helped in some way.

Saturday, 20 October 2018

What the dom is and what it isn't

I've been hearing people refer to the DOM in conversations and a lot of the time I get the feeling they don't completely understand what it actually is. At one point neither did I. And hey we're constantly learning right?

So what exactly is the DOM?

If I had to settle on a definition for it, it would look something like this:
The DOM is a set of APIs that can be used to manipulate the structure, content and styling of an XML or HTML document.

“Umm... wait but isn't like the HTML we write the DOM?” I hear you ask.
The answer... not exactly. A lot of people may use the word DOM interchangeably with HTML but there is a difference between the two.

Let us consider how the browser handles HTML documents.

When you write your markup, add some styling to it and then add in the content you need for your HTML document the browser converts the code you've written into its equivalent DOM representation. What this means is that the entire page structure, styling and content is now represented by a set of objects.

These objects are arranged in a particular way. In fact they are related to each other in pretty much the same way the HTML or XML tags in your document are related to each other, with child nodes appearing below parent nodes.

You will find that if you draw out this relationship in the form of a diagram it looks pretty much like the tree data structure (for those of you who've studied computer science). Hence often times you'll hear it referred to as the “DOM tree”.

To illustrate, let us consider the following example. Given below is an example of a basic HTML document.

If the objects in this document were to be plotted out in diagram form, the diagram would look something like this.


Each element in the tree is referred to as a “node”. OK so we know about the tree and its nodes now but what does this have to do with the DOM?

Well the nodes in the tree are a part of your DOM and they contain all the information about their content, styling and position in the DOM tree. Each node contains a reference to its parent and child nodes. This information can be used to manipulate or modify the document. This is done via an interface.

If you've written DOM manipulation code in Javascript before you will have used APIs like 'getElementById' and 'querySelector' which are used to search for elements in the DOM, 'createElement' which is used to create an element and 'remove' which is used to remove a node in the tree.

The DOM is a model that specifies how the document can be structured while also providing an API to access and modify it.

Finally, while we usually access the DOM via Javascript, there can exist implementations for it in other languages as well since it was designed to be language agnostic.

Hope this post helped. Given below are a few links in case you feel like reading further.

w3c - Dom introduction
MDN - Introduction to the DOM
Wikipedia: Document Object Model