Un-Opinionated vs Opinionated Within Frameworks

Un-Opinionated vs Opinionated Within Frameworks

One of the first pros and cons of each framework like Angular or React spits out is that it is “Opinionated” or that it is “Un-Opinionated”, and that is a huge reason to use that framework and a huge reason not to use the other. For the longest time, the project file structure has seemed to me like the main attribution to the opinionated nature of a framework, But there is so much more to it.

The Opinionated nature of a utility is also defined by how rich the “Swiss army knife (SAF)” it provides the developer. Each framework will supply some SAF for us the developers to use to write our code in a specific manner.

Examples :

1. React — Functional components, Hooks, JSX/TSX
2. Angular — HttpClient, RouterModule, I18N, Two-way binding

I love using these two frameworks as the prime examples for this due to the polarising differences between them.

The less opinionated a utility is, the more diverse it becomes, but as a result it is less structured.

One of the simplest examples one can provide is fetching the query parameters from a route.

The Diffrences

Angular The code block shows the “Angular way” of fetching the query params, ~99% of tutorials are written as seen below, but notice how both ways use the “ActivatedRoute” utility provided by Angular.

import {ActivatedRoute} from '@angular/core'
constructor(private **route**: ActivatedRoute) {

     const queryParams = **route**.snapshot.queryParams;

     **route**.queryParams.subscribe(console.log)

}

React We have 2 different optional ways to render the component which each gives a slightly different way to fetch the query. Yes, there is a lot of similarity between the patterns, and maybe behind the scenes they use the same solution, but this way gives us flexibility and high diversity to do things that perform better in our application. In the solutions given we use vanilla JS or an open-source library

import {useSearchParams} from 'react-router-dom' 

export const Component = () => {
  const [searchParams, setSearchParams] = useSearchParams();
  const id = searchParams.get("id")

   const search = window.location.search;
   const params = new URLSearchParams(search);
   const id2= params.get("id");

}

export class ComponentClass {
   constructor() {

 const search = this.props.location.search;      URLSearchParams(search).get("id"); 
}

}

The example of getting the query parameters is silly and very small, but it shows us a simple example of how the swiss knife that was given can benefit or hurt us. I am not saying that one is better than another, but what I am saying is: Be aware of the tools that are given in your Swiss army knife.

Knowing what you have or don’t have can increase your coding speed and quality of work.

Having an opinionated or unopinionated framework is an idealogy that strives from the orientation of the framework. Angular for example is a framework that targets enterprises which means it idealizes shared knowledge base and **predictive code. **This decision has its payoffs, for example, bundle size and performance but for an enterprise, these payoffs are maybe worth it.

Predictive Code

Predictive code is the ability to assume correctly, or with high accuracy, how something is written and implemented. It is one way to validate how consolidated a team/group and the code-base is. Predictive code can be broken down into main areas:

1. Naming conversions
2. Community-wide Best Practices
3. Team/Group agreed-upon Best Practices
4. Common Utilities
5. Linting and static code analysis
6. Typings (or some solution that helps the IDE like JsDocs)

All 6 criteria can be done in any framework. Although the opinionated level of a framework will determine how many of the items listed above are dealt with through the framework and how many the team/group has to handle on its own.

The results of Predictive Code are:

1. New team/group members will adjust quickly to the coding style of the pre-existing team.
2. Code reviews are simpler since agreed-upon standards make it easier to accept or reject PRs.
3. Debugging is much easier as we can predict bug location and vulnerable points.
4. Creating schematics (code that generates code) can be achieved to increase development speed and “force” the agreed-upon best practices upon the team.

Summary (TLDR)

Opinionated and Unopinated frameworks can be changed to “More Opinionated and less opinionated”. the level of the framework opinion can be measured and perceived by how many utilities it provides and enforces upon its users. The result of the amount of the utilities is how predictive our code becomes. Any codebase can, and should, become structured and “opinionated”, due to the framework and/or the team handling the codebase.

Good luck with your projects :)