DEV Community: mathumitha

Why do front end frameworks need node.js? Is not it server side?

mathumitha — Fri, 07 Apr 2023 07:38:32 +0000

Many of the developers who are just getting started with front end have questions like “Is not Node.js backend framework?”, “Why is it necessary to install Node.js for running my React application? Can’t I just link the CDN script and develop?”, “Are node.js and Javascript same?”. Don’t worry! This article will give you better clarity about Node.js and its role in both front-end and back-end applications.

Are javascript and node.js the same?

The answer is No. While Javascript is a programming language that can be used to create beautiful, interactive websites that run in a browser ecosystem, node.js is a server-side ecosystem built that allows the javascript to be run on the server-side.

Now, you may wonder what is the difference between running javascript in the browser and in the node.js run time?

Both browser run time and node.js run time use javascript as a programming language. node.js is built using Chrome’s v8 javascript engine. In browser, you will have access to cookies, web apis, document and window objects which do not exist in node.js. However, node.js has access to file system and support module systems like CommonJs and ES. As Javscript keeps evolving, node.js quickly incorporates the latest updates and make them available in the ecosystem. But browsers are bit slow to upgrade. In node.js ecosystem, import statements are supported out-of-the-box where as browser has limited support.

Now that, we have understood how javascript is used in browser runtime and node.js run time. Let’s see how node.js is used in front-end.

Let’s say you want to use react.js most of the tutorials ask you to install node and NPM unless you are explicitly searching to develop from cdn library. Why?? Let’s see..

The role of Node.js in front-end frameworks and libraries:
Even though Front-end frameworks can run seamlessly without relying node.js, in certain ways node.js plays a crucial role in improving the developer experience, optimising the overall architecture and providing a large-scale eco system to build the applications.

Lets talk about a few examples here,

Latest JavaScript features: As mentioned earlier, javascript version supported by node.js is way advanced than browser. It is running Chrome’s v8 engine and stays up-to-date with all new javascript features. Developers can start leveraging the latest features like import and reusable module systems. But, we can use transpilers to transform the javascript files to browser understandable formats.
NPM — Node Package Manager — It hosts wide range of both front end and backend javascript based packages running on the node.js run time. Unlike the traditional way in which we need to manually download the libraries to consume in the projects, npm provides a cool cli to install and manage packages. Build tools such as webpack, Browserify, Gulp and Grunt which are written in node.js and designed to be used with npm. Developers can leverage this type of building and bundling tools in their applications. Before arrival of these tools in npm, the backend systems were taking care of building and bundling tasks.
Code quality tools like Linters which help in identifying the issues related to syntax and even allow the developers to set the custom standards. These tools are built on top of node.js and can be leveraged in front-end applications.
There are many css preprocessors such as Sass, Less and packages like styled-component are available in npm. Testing — Frameworks like jest allows the developers to write unit tests which can help them capture the bug if code is modified in future.
node.js also helps in hot reloading with which, on every code save, the page would be refreshing automatically.

In summary, node.js is used in both front end and back end. In front-end, its mainly used for dependency management, building, testing and even server-side rendering. In backend, its used to build server side applcications and APIs. Overall, it provides a flexible platform with improved developer experience.

Shadow DOM simplified

mathumitha — Sun, 26 Jun 2022 08:05:59 +0000

DOM

Before we dive into shadow DOM, let's rewind what a DOM is. According to the definition, the DOM is a Programming Interface that allows the interaction with the structure, style, and content of a web page. The DOM parser parses the HTML/XML Document and creates a tree-like structure where each element in the tree is called a node. Likewise, the CSSOM parser parses the stylesheets/inline styles and creates a tree-like structure similar to DOM where-in each node contains the required style information. Finally, the outputs of DOM and CSSOM parsers are combined together, and the render tree is built which beautifully displays the content in the webpage.

Shadow DOM

Shadow DOM is an *encapsulated DOM * that is rendered separately from the main document. The script and styling present in the shadow DOM are private to the shadow DOM. This means that document.querySelector() will not return the Shadow DOM elements. The styles added to the shadow DOM will not leak outside of the Shadow DOM and the outside styles will not leak inside the shadow DOM. Therefore, you can apply styles directly to the generic selectors, ids, and classes without worrying about the conflicts. Shadow DOM provides both DOM and Style encapsulation.

Shadow DOM vs Virtual DOM

A few frameworks such as React.js, Vue.js make use of Virtual DOM to optimize the performance. React.js creates a copy of the real DOM and saves it in the memory. This copied version is called Virtual DOM. React.js doesn't update the real DOM directly. It runs a diffing algorithm to find out the changes. Whenever the state changes, React.js compares Virtual DOM with its previous versions. If it finds any, it updates only those changes into the real DOM. This process is called Reconciliation. So, the virtual DOM is used for improving performance and the Shadow DOM is used for encapsulation. You can create virtual DOM and attach it to shadow DOM or vice versa.

Are Web components and shadow DOM the same?

No. Shadow DOM is the technology used in Web components. Web components are developed on top of shadow DOM. They make use of encapsulation provided by shadow DOM. They provide the set of APIs using which we can create encapsulated, reusable, custom elements. These components are framework agnostic that can be used across all javascript applications.

Difference between web components and components created by Vue.js, React, Angular

DOM encapsulation:
As I said earlier, the difference lies in the encapsulation part. Although the frameworks support component reusability, a component will still have access to elements in other components using query selector APIs (document.querySelector()). In the case of Web components, each component is strongly encapsulated and can only be accessed within the shadow DOM. document.querySelector() does not return the elements on other web components.
Style encapsulation:
The frameworks like Vue.js and React.js don't support style encapsulation natively. For vue.js, vue-loader supports scoped attribute for style tags. Other frameworks make use of css modules, css-in-js libraries to handle style encapsulation. However,Angular supports emulated style encapsulation. It provides an option called encapsulation in the component API.

Building blocks of shadow DOM

Shadow host - The shadow host is the same as the other child nodes attached to the real DOM. It can be div, span, or anything in this list. <text-area>, <input /> have their own shadow DOM built-in by the browser.
Shadow tree - The DOM tree inside the shadow DOM
Shadow root - The root node of the Shadow tree

Shadow DOM looks like below,

HTML Structure

Creating Shadow DOM

const shadowHost = document.createElement('div');
const shadowRoot = shadowHost.attachShadow({mode: 'open'});
shadowHost.id = 'shadow-host';
shadowRoot.innerHTML = `
<h1>Hi, there!/h1>
<style>
   h1 {
     color: green;
   }
</style>`;

Hence, any element that calls attachShadow will become a shadow host and create a shadow tree.
In the above code, the mode is set to open. If the shadow root is created with open mode, the shadow root can be accessed by the real DOM elements in the following way,

document.querySelector('#shadow-host').shadowRoot.innerHTML

If the mode is set to closed, the above code will return null.

Browser compatibility

Shadow DOM is supported by the latest browsers such as Chrome, Firefox (63 and onwards), Opera, Safari, and Edge. The polyfills are also available for the unsupporting browsers.

Create shareable ESlint configs for Vue projects

mathumitha — Tue, 17 May 2022 05:08:06 +0000

Linting helps projects follow the best practices, enforce coding conventions and ensure code quality. ESlint is a static code analysis tool that exclusively lints Javascript code.

Any project that has an ESlint setup will adhere to code uniformity regardless of the expertise of developers. ESlint scans the code, reports the potential errors and stylistic errors then and there. Hence, developers can fix the errors on the fly even before it goes for code review.

While ESlint fixes the coding style, Prettier can accompany to fix formatting.

In this article, Let's create a package that exposes a reusable ESlint config that can be shared across Vue projects.

Run the following command to create npm package. Make sure that the package name starts with eslint-config such as eslint-config-vue-standards, If the project has npm scope, you can name it @scope/eslint-config as such.

npm init

This will create a package.json file under our project directory.

Let's install ESlint,

npm install eslint --save-dev

ESlint is installed in devDependencies and add it to peerDependencies to ensure that consumer applications install the same version of ESlint.

Next, Let's install the ESlint plugin that supports Vue files.

npm install eslint-plugin-vue --save

ESlint rules are completely configurable based on our style guide. You can enable/disable them completely or under certain conditions. To know more, check this guide.

There are many shareable ESlint Configs used by many companies such as eslint-config-airbnb recommended by Airbnb. Similarly, you can also create your own set of configs as a package for your project or company based on the style guide you follow and share it across for the other teams to consume. Let's install some of the existing configs that already enforce the best practices.

npm install eslint-config-airbnb-base eslint-plugin-import eslint-plugin-vuejs-accessibility --save

Let's create a configuration file index.js where we can extend the installed configs.

module.exports = {
  env: {
    es6: true,
    browser: true,
    node: true,
  },
  parserOptions: {
    ecmaVersion: 2021,
    sourceType: "module",
    ecmaFeatures: {
      jsx: true,
    },
  },
  extends: [
    "eslint:recommended",
    "airbnb-base",
    "plugin:import/recommended",
    "plugin:vue/recommended",
    "plugin:vuejs-accessibility/recommended"
  ],
  rules: {
    "vue/camelcase": ["error"],
  },
};

There, env and parserOptions are used to define the environments such as node, browser, and parsers such as jsx, ecma. I have added vue/camelcase rule with error configuration that will throw an error when expressions inside vue <template> does not follow camelCase conventions.

Let's configure prettier now,

npm install prettier --save-dev

Like ESlint, Prettier also has to be a peerDependency.

Let's install prettier configs,

npm install eslint-config-prettier eslint-plugin-prettier --save

Our final configs will look like the below after prettier configs added,

module.exports = {
  env: {
    es6: true,
    browser: true,
    node: true,
  },
  parserOptions: {
    ecmaVersion: 2021,
    sourceType: "module",
    ecmaFeatures: {
      jsx: true,
    },
  },
  extends: [
    "eslint:recommended",
    "airbnb-base",
    "plugin:import/recommended",
    "plugin:vue/recommended",
    "plugin:vuejs-accessibility/recommended",
    "prettier",
    "plugin:prettier/recommended",
  ],
  rules: {
    "vue/camelcase": ["error"],
  },
};

It is important to note that the prettier configuration file .prettierrc.js must reside in the consumer application.

module.exports = {
  tabWidth: 2,
  singleQuote: true
}

Yay.We are done!
You can publish this package and start using in any vue application. To test it locally, you can install by running the following command.

npm install <path-to-application>/eslint-vue-blog --save-dev

This package is available in Github.

Dynamic Brand theming using CSS variables

mathumitha — Sat, 26 Jun 2021 14:38:03 +0000

Recently, I got to work on an e-commerce checkout page builder (No code tool) where the merchants can change the theme according to their brand. The merchants can configure their brand colour and secondary colour to various elements like buttons, containers, texts, etc. This configuration will be fetched using APIs and applied to checkout pages on rendering. I was exploring various approaches such as SASS/LESS/Stylus variables, CSS-in-JS libraries and CSS variables for applying the theme. After a deep exploration, I ended up using CSS variables. In this article, I would like to explain the pros and cons of each approach and how I ended up using CSS variables.

SASS/LESS/Stylus variables:

CSS preprocessors are scripting languages that allow developers to write DRY styles using variables, functions, mixins, etc. These DRY styles would be converted into raw CSS styles in compile time. If we are aware of all theme-related information during compile time, we can easily map them to these variables and achieve theming. As the checkout has to allow the merchants to change the theme dynamically in run time, we cannot go with this approach.

CSS-in-JS libraries:

There are many CSS-in-Js libraries available in the market such as styled-components, emotion, glamorous, etc. These provide extensive theming support. However, these libraries require <ThemeProvider /> which has to be wrapped over the app in order to provide theming context. Vendor lock-in is another disadvantage of using this. We will not be able to easily switch to a different approach in the future. As we got used to the traditional CSS approach, the learning curve is also steep.

CSS Variables:

CSS variables a.k.a custom properties allow us to change the values dynamically in the run time using Javascript. We can use var()to use a variable in the references of the stylesheet. You can assign the value of CSS variable either in CSS or javascript. Many latest browser versions support CSS variables. As CSS variables are supported by native CSS and the learning curve is also shallow, I preferred CSS variables for my theme-able system.

Let’s create a simple checkout page that contains the shipping address section, the payment section and the cart section. The merchant would be able to configure brandColor, secondaryColor and bodyBackgroundColor for these sections.

Step 1 — Mapping the variables to check out elements

Let’s map each variable to the respective checkout elements.
brandColor- This is used for primary buttons, logo and border colours
secondaryColor — This is used in the apply coupon input group
bodyBackgroundColor- This is applied as a background colour to the main container.

Step 2 — Using the CSS variables in the stylesheet.

To assign a CSS variable to a property, we have to use var().

Let’s have a look at the selectors which use brandColorvariable. The value for this variable will be set using javascript during run time.

secondaryColor variable is used for the apply coupon button.

bodyBackgroundColor is applied to the main container of the application.

Step 3 — Creating Merchant configuration JSON

Our theme builder configuration will be exposed via API from the server. The configuration JSON will be looking something like this

In order to demo, let’s mock the server response with static JSON. getMerchantConfigfunction will return a promise which resolves the merchant configuration using the merchantId argument.

Step 4 — Setting values for CSS variables in Javascript

Now, let’s see how the variables are set in Javascript. As the variables are used across the stylesheet, let’s set the variables in the root element.

const root = document.querySelector(':root');
root.style.setProperty('--brandColor', merchant.brandColor);
root.style.setProperty('--secondaryColor', merchant.secondaryColor);
root.style.setProperty('--bodyBackgroundColor', merchant.bodyBackgroundColor);

Now, we have to get the theme configuration for the merchant. Let’s say Merchant 1 is active. we have to call getMerchantConfig function by passing merchantId merchant1.

const setTheme = async () => {
  const merchant = await getMerchantConfig('merchant1');
  const root = document.querySelector(':root');
  root.style.setProperty('--brandColor', merchant.brandColor);
  root.style.setProperty('--secondaryColor',     merchant.secondaryColor);
  root.style.setProperty('--bodyBackgroundColor', merchant.bodyBackgroundColor);
};
setTheme();

The final Js code will be looking like this.

That’s all, We are done with it 😎. You can see the working demo in the codepen. You can play around by passing different merchantIds to getMerchantConfig function. You can also try configuring other properties such as font-size, font-family, etc.

Conclusion:

Theming is much more simplified using CSS variables. There is no vendor lock-in. CSS variables are supported by native CSS and have great browser compatibility. It’s the best fit for my feature. CSS variables have much more potential other than theming. It reduces plenty of repetitive tasks. You can give it a try. I’m attaching a few good resources here.