DEV Community: Anagha GN

Understanding the Styles of APIs in Vue.js

Anagha GN — Mon, 13 Jan 2025 11:11:17 +0000

Vue is a JavaScript framework for building user interfaces. It builds on top of standard HTML, CSS, and JavaScript and provides a declarative, component-based programming model that helps you efficiently develop user interfaces of any complexity.
Vue components can be authored in two API styles: Options API and Composition API(Introduced above version 2.6), Both approaches have their unique benefits and drawbacks, and choosing the right one for your project can be a difficult decision.

Let’s dive deep into both styles of understanding

Options API:
The Options API is the traditional way of building Vue components. It defines a component's behavior and state using a set of options like data, methods, and computed properties.
data(): This function returns an object containing the component's reactive data properties. These properties will update the component's rendered output when their values change.
methods(): This function returns an object containing methods (functions) that can be used inside the component's template or other methods. These methods can manipulate the data or perform actions.
computed properties: These functions return a value based on the component's data. They are recalculated whenever any of their dependencies (reactive data properties) change.
One of the main benefits of the Options API is that it is simple and easy to understand. It follows a clear, declarative pattern that is familiar to many developers, and it is well-documented in the Vue documentation. This makes it a good choice for beginners who are just starting with Vue.

However, the Options API has some limitations that can make it difficult to use for more complex projects.
Another limitation of the Options API is that it can be inflexible when it comes to sharing logic between components.
Unit testing components built with the Options API can be more challenging. The spread of logic across different options makes it harder to isolate specific functionalities for testing.

Let's see the Example of Options API styling :

<template>
    <div>
        <h4>{{ name }}'s To Do List</h4>
        <div>
            <input v-model="newItemText" v-on:keyup.enter="addNewTodo" />
            <button v-on:click="addNewTodo">Add</button>
            <button v-on:click="removeTodo">Remove</button>
        </div>
        <ul>
            <li v-for="task in tasks" v-bind:key="task">{{ task }}</li>
        </ul>
    </div>
</template>
<script>
    export default { 
    data() { 
           return 
               {  name: "John", 
                  tasks: ["Buy groceries", "Clean the house"], 
                  newItemText: "", 
                };
            }, 
   methods: { 
          addNewTodo() 
            { 
               if (this.newItemText !== "") 
                {  this.tasks.push(this.newItemText); 
                   this.newItemText = ""; 
                } 
            }, 
         removeTodo(index) { this.tasks.splice(index, 1); }, }, };
</script>

Composition API :

The Composition API is a set of tools introduced in Vue 3 (and available for Vue 2 through a plugin) that provides an alternative way to write component logic compared to the traditional Options API. It focuses on composing reusable functions to manage a component’s state and behavior.
With Composition API, we define a component’s logic using imported API functions. It also allows developers to use the full power of JavaScript to define component behavior.
Composition API is typically used with . The setup attribute is a hint that makes Vue perform compile-time transforms that allow us to use Composition API with less boilerplate.<br> The foundation of Composition API is Vue’s built-in reactivity system. Functions like ref and reactive create reactive data that automatically updates the component when it changes. This simplifies state management compared to manually setting up getters and setters in the Options API.<br> The Composition API supports dependency injection through functions like provide and inject.<br> The Composition API is particularly beneficial for:</p> <p>Building complex and reusable components<br> Projects that prioritize code organization and maintainability<br> Applications that leverage TypeScript for type safety<br> The Composition API may seem like the best option to use. However, the Composition API is not without its drawbacks. One issue is that it can be more difficult to learn for developers who are not familiar with functional, reactive programming.<br> Another issue is that the Composition API is not backward compatible with Vue 2.6 and under by default. This means you will need to either upgrade to Vue 3.0 or import the Composition API via a plugin.</p> <p>Let’s see the Example of Composition API styling :<br> </p> <div class="highlight"><pre class="highlight plaintext"><code><template> <div> <h4>{{ name }}'s To Do List</h4> <div> <input v-model="newItemText" v-on:keyup.enter="addNewTodo" /> <button v-on:click="addNewTodo">Add</button> <button v-on:click="removeTodo">Remove</button> </div> <ul> <li v-for="task in tasks" v-bind:key="task">{{ task }}</li> </ul> </div> </template> <script> import { ref } from 'vue'; export default { setup() { const name = ref('John'); const tasks = ref(['Buy groceries', 'Clean the house']); const newItemText = ref(''); const addNewTodo = () => { if (newItemText.value !== '') { tasks.value.push(newItemText.value); newItemText.value = ''; } }; const removeTodo = (index) => { tasks.value.splice(index, 1); }; return { name, tasks, newItemText, addNewTodo, removeTodo }; }, }; </script> </code></pre></div> <p></p> <p>Here we import ref from Vue to create reactive data. The setup function replaces the data and methods options from the Options API. We create reactive references for name, tasks, and newItemText using ref.The addNewTodo and removeTodo functions are defined inside setup and manage the state changes. The setup function returns an object containing the reactive data and functions, making them accessible in the template.</p> <p>I hope you found the article Insightful, we explored the differences between these two approaches, highlighting their respective advantages and disadvantages. This should help you make an informed decision about which API to use in your next Vue project.</p> <p>Reference :<br> Vue.js<br> Options and Compositions API styles</p>

LLM Fundamentals — Hallucinations in LLMs 101 [Part I]

Anagha GN — Fri, 20 Sep 2024 06:05:23 +0000

Def: A hallucination is a perception in the absence of an external stimulus that has a compelling sense of reality (Ref: Wiki).

In simple terms, a hallucination is an unreal perception that feels real.

For human beings — Hallucination traces its roots in the fields of pathology and psychology. It is defined as a set of experiences where a person perceives something that isn’t actually present. In human beings, hallucinations can affect any of the senses, including:

Auditory hallucinations: Hearing sounds, voices, or noises that aren’t there
Visual hallucinations: Seeing things that aren’t actually present, such as objects or people
Olfactory hallucinations: Smelling odours that have no external source
Gustatory hallucinations: Tasting flavours that aren’t actually present.

Hallucinations can be caused by a range of factors, including mental health conditions, neurological disorders, substance abuse, or extreme stress and fatigue.

Hallucinations in LLM
The emergence of LLMs and their wide-scale adoption in recent years has opened innumerable opportunities to integrate AI/ML seamlessly into technology products across domains. However, while doing so it has become imperative to understand Hallucinations in LLMs and the impact it has on the adoption of LLMs in live technology platforms wrt the reliability of the output that the LLM systems generate.

Within the realm of (Natural Language Processing (NLP), hallucination is typically referred to as a phenomenon in which the generated content appears nonsensical or unfaithful to the provided source content (Filippova, 2020; Maynez et al., 2020).

LLM Hallucination — Ref #2 (A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions Huang et al.)

Categorization of Hallucination in LLMs
Initially, LLM Hallucinations were categorized into 2 types:

Intrinsic Hallucinations: The output generated by the LLM that contradicts the source content. For instance, in the abstractive summarization in the below example, the generated summary “The first Ebola vaccine was approved in 2021” contradicts the source content “The first vaccine for Ebola was approved by the FDA in 2019.”
Extrinsic Hallucinations: The output generated by the LLM cannot be verified from the source content (i.e., output that can neither be supported nor contradicted by the source). For example, in the abstractive summarization task in the below example, the information “China has already started clinical trials of the COVID-19 vaccine.” is not mentioned in the source. We can neither find evidence for the generated output from the source nor assert that it is wrong. Notably, extrinsic hallucination is not always erroneous because it could be from factually correct external information. Such factual hallucination can be helpful because it recalls additional background knowledge to improve the informativeness of the generated text. However, in most of the literature, extrinsic hallucination is still treated with caution because its unverifiable aspect of this additional information increases the risk from a factual safety perspective.

Abstractive Summarization — Ref #1 (Survey of Hallucination in Natural Language Generation — Ji et al.)

In recent times, the LLMs emphasize user-centric interactions, and their hallucinations appear at factual levels. Taking this into consideration Huang et al. in their paper “A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions” introduced a more granular hallucination taxonomy as follows:

Categories of Hallucinations

Factual Hallucination**
Existing LLMs frequently manifest tendencies to produce results that are either inconsistent with real-world facts or are most likely misleading. This poses a challenge to the trustworthiness of artificial intelligence. In such a context, such factual errors are classified as factuality hallucinations.

Depending on whether the generated factual content can be verified against a reliable source, they can be further divided into two primary types:

Factual Inconsistency — It refers to situations where the LLM’s output contains facts that can be grounded in real-world information, but present contradictions. This type of hallucination occurs most frequently and arises from diverse sources, encompassing the LLM’s capture, storage, and expression of factual knowledge. As shown in the below example, when inquired about “the first person to land on the Moon”, the model erroneously generated “Yuri Gagarin”, which contradicts the real-world fact.

Factual Fabrication — Here the LLM’s output contains facts that are unverifiable against established real-world knowledge. As demonstrated in the below example, while “the origins of unicorns” traditionally lack empirical grounding, the model fabricated a plausible historical origin for unicorns.

Types of Factual Hallucinations — Ref #2 (A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions Huang et al.)

Faithfulness Hallucination
LLMs by default are trained to align with the instructions given by the user. As the use of LLMs shifts towards more user-centric applications, ensuring their consistency with user-provided instructions and contextual information becomes crucial. Moreover, LLM’s faithfulness is also reflected in the logical consistency of its generated content. From this perspective, Huang et al. categorize three subtypes of faithfulness hallucinations:

*Instruction inconsistency *— In this type of hallucination the LLM’s outputs deviate from a user’s directive. While some deviations might serve safety guidelines, the inconsistencies here signify unintentional misalignment with non-malicious user instructions. As shown in the below example, the user’s actual intention is translation, However, the LLM erroneously deviated from the user’s instruction and performed a question-answering task instead.
Context inconsistency — These are the hallucinations where the LLM’s output is not consistent/faithful with the user’s provided contextual information. As shown in the below example, the user mentioned the Nile’s source being in the Great Lakes region of central Africa, yet the LLM’s response contradicted the context.
Logical inconsistency — In this type of hallucination the LLM outputs reveal internal logical contradictions, especially observed in their reasoning tasks. As a result, inconsistencies appear both among the reasoning steps themselves and between the steps and the final answer. As shown in the below example, while the reasoning step of dividing both sides of the equation by 2 is correct, the final answer of x=4 is inconsistent with the reasoning chain, leading to an incorrect result.

Types of Faithfulness Hallucinations — Ref #2 (A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions Huang et al.)

References
Survey of Hallucination in Natural Language Generation — Ji, Ziwei and Lee, Nayeon and Frieske, Rita and Yu, Tiezheng and Su, Dan and Xu, Yan and Ishii, Etsuko and Bang, Ye Jin and Madotto, Andrea and Fung, Pascale
A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions — Lei Huang and Weijiang Yu and Weitao Ma and Weihong Zhong and Zhangyin Feng and Haotian Wang and Qianglong Chen and Weihua Peng and Xiaocheng Feng and Bing Qin and Ting Liu
Note: Significant content of this tech blog has strong references from the above 2 papers.

In our next blog, we will dive deep into the key aspects contributing to hallucinations in LLMs. Stay tuned 💡

From Fish to Flying Dogs: Vivek’s Playful Guide to SOLID Principles with Tara at NonStop

Anagha GN — Wed, 07 Aug 2024 11:18:10 +0000

Scene: Tara, a new Intern, has just joined NonStop IO Technologies Pvt. Ltd. She’s eager to learn about best coding practices. Vivek, the Project Manager, decides to explain the SOLID principles to her using the context of aquatic and terrestrial animals. They are sitting in the company lounge with a cup of coffee.

Vivek: (smiling) Welcome to NonStop IO Technologies, Tara! How’s your first day going?

Tara: (grinning) It’s been great so far, Vivek. Just trying to soak in all the new information. By the way, I’ve been hearing a lot about these SOLID principles. What’s all the hype about?

Vivek: (chuckling) Ah, the famous SOLID principles! They’re like the Avengers of software design — each one has its superpower to save us from bad code. Let’s start with the Single Responsibility Principle, or SRP. Imagine a Zoo class that handles feeding, entertaining, and displaying animals. It’s like asking a fish to swim, walk, and fly. Impossible, right?

Tara: (laughing) I’d love to see a flying fish, though!

Vivek: (laughs) True! But in coding terms, it’s a mess. Here’s an example of how the Zoo class violates SRP:

Violation Example:

class Zoo {
  void feedAnimals() {
    print('Feeding animals');
    // Code to feed animals
  }
  void entertainAnimals() {
    print('Entertaining animals');
    // Code to entertain animals
    Fish fish = Fish();
    fish.swim();
    Bird bird = Bird();
    bird.fly();
    bird.walk();
    Dog dog = Dog();
    dog.walk();
    dog.swim();
  }
void displayAnimals() {
    print('Displaying animals');
    // Code to display animals to visitors
  }
}

Explanation:

The Zoo class handles multiple responsibilities: feeding animals, entertaining them, and displaying them. This violates SRP because changing one responsibility (e.g., how animals are entertained) would require modifying the Zoo class, making it more complex and error-prone.
Correction Example:

class Feeder {
  void feedAnimals() {
    print('Feeding animals');
    // Code to feed animals
  }
}
class Entertainer {
  void entertainAnimals() {
    print('Entertaining animals');
    // Code to entertain animals
    Fish fish = Fish();
    fish.swim();
    Bird bird = Bird();
    bird.fly();
    bird.walk();
    Dog dog = Dog();
    dog.walk();
    dog.swim();
  }
}
class Displayer {
  void displayAnimals() {
    print('Displaying animals');
    // Code to display animals to visitors
  }
}
Correction Explanation:

Each class (Feeder, Entertainer, Displayer) now has a single responsibility. This makes the code more modular and easier to maintain.
Tara: Got it! So each class has its responsibility. What’s next?

Vivek: Next up, OCP — the Open/Closed Principle. Classes should be open for extension but closed for modification. Here’s how our Zoo class violates OCP:

Violation Example:

class Zoo {
  void showAnimals() {
    Fish fish = Fish();
    Bird bird = Bird();
    Dog dog = Dog();
    fish.swim();
    bird.fly();
    bird.walk();
    dog.swim();
    dog.walk();
  }
}

Explanation:

The Zoo class directly depends on specific implementations of Fish, Bird, and Dog. If you want to add a new animal, you’d have to modify the showAnimals method, which violates OCP.
Correction Example:

abstract class Swimmer {
  void swim();
}
abstract class Walker {
  void walk();
}
abstract class Flyer {
  void fly();
}
class Fish implements Swimmer {
  @override
  void swim() {
    print('Fish is swimming');
  }
}
class Bird implements Walker, Flyer {
  @override
  void fly() {
    print('Bird is flying');
  }
@override
  void walk() {
    print('Bird is walking');
  }
}
class Dog implements Walker, Swimmer {
  @override
  void swim() {
    print('Dog is swimming');
  }
@override
  void walk() {
    print('Dog is walking');
  }
}
class Zoo {
  final List<Swimmer> swimmers;
  final List<Walker> walkers;
  final List<Flyer> flyers;

Zoo(this.swimmers, this.walkers, this.flyers);

void showSwimmers() {
    for (var swimmer in swimmers) {
      swimmer.swim();
    }
  }
void showWalkers() {
    for (var walker in walkers) {
      walker.walk();
    }
  }
void showFlyers() {
    for (var flyer in flyers) {
      flyer.fly();
    }
  }
}

Correction Explanation:

By using interfaces (Swimmer, Walker, Flyer), the Zoo class can work with any new animal that implements these interfaces, adhering to OCP.
Tara: So, no tearing down walls for a new animal? Sounds like a relief for the animals and the developers!

Vivek: (grinning) Exactly! Now, LSP — Liskov Substitution Principle. This principle ensures that derived classes can substitute base classes without breaking the system. Here’s how it’s violated:

Violation Example:

abstract class Swimmer {
  void swim();
}

class Fish implements Swimmer {
  @override
  void swim() {
    print('Fish is swimming');
  }
}

class Dog implements Swimmer {
  @override
  void swim() {
    print('Dog is swimming');
  }

  void bark() {
    print('Dog is barking');
  }
}

Explanation:

In this example, Dog is substituting for Swimmer, but it introduces additional behaviors (bark()) that Fish doesn’t have. This could cause issues when using a Swimmer in a context where only swimming is expected, as Dog introduces unexpected behavior.
*Correction Example:
*

abstract class Swimmer {
  void swim();
}

class Fish implements Swimmer {
  @override
  void swim() {
    print('Fish is swimming');
  }
}

class Dog implements Swimmer {
  @override
  void swim() {
    print('Dog is swimming');
  }
}

Correction Explanation:

Both Fish and Dog implement the Swimmer interface correctly, focusing solely on swimming. This adheres to LSP as both classes can be used interchangeably wherever a Swimmer is expected without introducing unexpected behaviors.
This adjustment ensures that the Swimmer interface remains consistent and reliable, adhering to LSP by not introducing additional methods or behaviors that aren’t expected by the base interface.

Tara: (giggling) Unless it’s on some sort of superhero potion!

Vivek: (laughs) Exactly! For superheroes, we have a separate interface. Then, we have ISP — the Interface Segregation Principle. This principle means no client should be forced to depend on interfaces it doesn’t use. Here’s how it’s violated:

Violation Example:

abstract class Animal {
  void swim();
  void walk();
  void fly();
}
class Fish implements Animal {
  @override
  void swim() {
    print('Fish is swimming');
  }
@override
  void walk() {
    throw UnimplementedError(); // Fish can’t walk
  }
@override
  void fly() {
    throw UnimplementedError(); // Fish can’t fly
  }
}
class Bird implements Animal {
  @override
  void swim() {
    throw UnimplementedError(); // Bird can’t swim
  }
@override
  void walk() {
    print('Bird is walking');
  }
@override
  void fly() {
    print('Bird is flying');
  }
}
Explanation:

The Animal interface forces all animals to implement swim, walk, and fly, even if they don’t need those methods. This violates ISP because Fish and Bird are forced to implement methods that don’t apply to them.
Correction Example:

abstract class Swimmer {
  void swim();
}
abstract class Walker {
  void walk();
}
abstract class Flyer {
  void fly();
}
class Fish implements Swimmer {
  @override
  void swim() {
    print('Fish is swimming');
  }
}
class Bird implements Walker, Flyer {
  @override
  void fly() {
    print('Bird is flying');
  }
@override
  void walk() {
    print('Bird is walking');
  }
}

Correction Explanation:

By using separate interfaces (Swimmer, Walker, Flyer), each animal class only implements the methods it needs. This adheres to ISP by ensuring that classes are not burdened with unnecessary methods.
Tara: (laughing) Or making a dog try to fly — though, a cape might help!

Vivek: (chuckling) True, true. And finally, we have DIP — Dependency Inversion Principle. High-level modules shouldn’t depend on low-level modules but on abstractions. Here’s how it’s violated:

Violation Example:

class Zoo {
  void showAnimals() {
    Fish fish = Fish();
    Bird bird = Bird();
    Dog dog = Dog();
    fish.swim();
    bird.fly();
    bird.walk();
    dog.swim();
    dog.walk();
  }
}

Explanation:

In this design, the Zoo class depends on concrete implementations (Fish, Bird, Dog). If we want to change the behavior or add new animal types, we need to modify the Zoo class, which violates DIP.
Correction Example:

abstract class Swimmer {
  void swim();
}

abstract class Walker {
  void walk();
}

abstract class Flyer {
  void fly();
}

class Fish implements Swimmer {
  @override
  void swim() {
    print('Fish is swimming');
  }
}

class Bird implements Walker, Flyer {
  @override
  void fly() {
    print('Bird is flying');
  }

  @override
  void walk() {
    print('Bird is walking');
  }
}

class Dog implements Walker, Swimmer {
  @override
  void swim() {
    print('Dog is swimming');
  }

  @override
  void walk() {
    print('Dog is walking');
  }
}

class Zoo {
  final Swimmer swimmer;
  final Walker walker;
  final Flyer flyer;

  Zoo(this.swimmer, this.walker, this.flyer);

  void performShow() {
    swimmer.swim();
    walker.walk();
    flyer.fly();
  }
}

void main() {
  Zoo zoo = Zoo(Fish(), Dog(), Bird());
  zoo.performShow();
}

Correction Explanation:

We define Swimmer, Walker, and Flyer interfaces as abstractions. Fish, Bird, and Dog implement these interfaces as low-level modules. The Zoo class depends on these abstractions (Swimmer, Walker, Flyer) rather than concrete implementations.
Now, the Zoo class is not tightly coupled to specific animal classes. We can easily swap out different implementations (e.g., replace Dog with a Cat that implements Walker) without changing the Zoo class. This design adheres to the Dependency Inversion Principle, promoting flexibility and maintainability.
Tara: So, the pet-sitter is prepared for anything — from fish to flying birds?

Vivek: (grinning) Exactly! It’s about being adaptable and prepared for change. And that, my dear intern, is a quick tour through the SOLID zoo!

Tara: (smiling) That was fun and enlightening! Now I can brag about understanding SOLID principles to my friends.

Vivek: (laughing) You sure can! And remember, this is just the beginning. At NonStop IO Technologies Pvt. Ltd., we’re all about quality code and having fun while learning. You’ll get the best mentoring and training here.

Tara: (grateful) I can already see that. Thanks for the awesome explanation, Vivek! I’m looking forward to learning more.

Vivek: (smiling) Anytime, Tara! Welcome aboard, and remember, we’re all in this together — whether you’re a dog, bird, or even a flying fish! 😊

Conclusion: Understanding and applying SOLID principles helps create a more flexible, maintainable, and scalable codebase. At NonStop IO Technologies Pvt. Ltd., we take pride in providing top-notch mentoring and training to ensure our developers can apply these principles effectively, making our software as robust and adaptable as a well-tended zoo.

React Portals Explained: A Guide for Developers

Anagha GN — Fri, 26 Jul 2024 08:20:55 +0000

React Portals provide an advanced capability in React, enabling developers to render components outside the main React component hierarchy. This functionality is particularly useful for creating modals, tooltips, and other elements that need to exist outside their parent component’s DOM structure. By leveraging portals, developers can achieve more flexible and robust user interface designs, enhancing the overall user experience.

In this article, we will delve into React Portals, examining their functionality and demonstrating how to utilize them effectively within your React applications.

Introduction to React Portals
React Portals offer a solution for rendering components into a DOM node that exists outside the usual component hierarchy. Typically, rendering a component in React inserts it as a child within its parent component’s DOM structure. However, there are cases, such as creating modals or dropdown menus, where it is necessary to render a component elsewhere in the DOM.

React Portals address this by allowing a component’s output to be rendered in a different DOM node, outside of its parent component’s DOM hierarchy. This approach enables the visual display of components at any location within the DOM while maintaining their logical position in the React component tree.

This functionality is made possible by a feature in react-dom called “portals.” The react-dom library provides a createPortal method, which takes two arguments: the content to be rendered (referred to as children) and the target DOM node where the content should be rendered, as demonstrated below:

`import {createPortal} from 'react-dom';
createPortal(children, domNodeContainer);`

Some use cases for React Portals include:

Modal Dialogs: Modals often need to overlay the entire page, requiring them to be rendered outside the current component hierarchy to ensure they appear above all other content. React Portals facilitate the rendering of modal components outside their parent components, simplifying the management of their visibility and behavior.
Tooltips and Popovers: These components usually need to be displayed near a specific element or at a certain position on the page. React Portals allow you to render tooltips and popovers in a different part of the DOM, enabling precise positioning relative to the triggering element.
Dropdown Menus: To ensure correct positioning and layering, dropdown menus must often be rendered outside their parent component. React Portals make it easy to render dropdown menus outside the regular component hierarchy, while still maintaining their interaction with the triggering elements.

Benefits of using React Portals
React Portals provide several advantages when building React applications, including:

1. Versatile Component Placement: React Portals enable components to be rendered anywhere in the DOM, outside the usual component hierarchy. This offers greater flexibility for creating complex UIs and precisely positioning components as needed.

2. Separation of Visual and Logical Concerns: Portals allow the visual display of a component to be separated from its logical position in the component tree. This improves code organization and makes the codebase easier to understand and maintain.

3. Reduced CSS Conflicts: By rendering components through portals, their styles are isolated from parent and sibling components. This helps to prevent CSS conflicts, ensuring that the styles of portal components remain unaffected by the surrounding environment.

4. Improved Accessibility: Portals are particularly useful for creating accessible components, such as modals. By rendering them at the top level of the DOM, they become more accessible to screen readers and assistive technologies, enhancing the overall accessibility of the application.

5. Seamless Integration with Third-Party Libraries: React Portals make it easier to integrate third-party libraries or components that need to be rendered outside the main React hierarchy. This allows external functionalities to be incorporated seamlessly while maintaining the integrity of the React application.

6. Enhanced Performance: React Portals can boost application performance by reducing unnecessary re-renders. Since portal components are rendered outside the regular component hierarchy, they can be updated independently, minimizing the need for re-renders throughout the entire application.

How to implement React Portals?
To illustrate the functionality of React Portals, let’s build an example using a modal.

Create React application

`npm create vite@latest
Need to install the following packages:
create-vite@5.4.0
Ok to proceed? (y) y
✔ Project name: … sample-react-portal
✔ Select a framework: › React
✔ Select a variant: › JavaScript`

Now, we will develop an application component that includes a button element and a modal component. The modal will be displayed only when the button is clicked.

App.jsx

`import { useState } from 'react';
import './App.css';
import Modal from './modal.jsx';

function App() {
 const [isOpen, setOpen] = useState(false);
 return (
  <div>
   <button
    onClick={() => {
     setOpen(true);
    }}>
    Open
   </button>
   <Modal isOpen={isOpen} onClose={() => setOpen(false)} />
  </div>
 );
}
export default App;`

The provided code defines an App component that includes a button for toggling the visibility of a modal component. The display of the modal is controlled by the isOpen state variable. When the button is clicked, the modal appears. The modal can be closed by invoking the onClose function, which updates the state to hide the modal.

modal.jsx

`import React from 'react';
import { createPortal } from 'react-dom';
import './modal.css';

export default function Modal({ isOpen, onClose }) {
 if (!isOpen) return null;
 return createPortal(
  <div className='modal'>
   <div className='modal-container'>
    <div className='modal-body'>
     <p>Sample Modal</p>
    </div>
    <button onClick={onClose}>Close</button>
   </div>
  </div>,
  document.getElementById('modal') // this instructs `react-dom` to render the modal outside the current React component hierarchy.
 );
}`

The modal component is designed to accept two props: isOpen and onClose. The isOpen prop determines the visibility of the modal, while the onClose prop is a callback function that gets invoked to close the modal.

When the isOpen prop is set to false, the modal is not rendered, and the component returns null, meaning no content is displayed.

When the isOpen prop is true, the component utilizes the createPortal function to render the modal content outside the current React component hierarchy. The createPortal function takes two arguments: the JSX code representing the modal and the target DOM element where the modal should be rendered. In this scenario, the target DOM element is specified as document.getElementById(‘modal’). This instructs react-dom to render the modal within the DOM element with the ID modal, effectively positioning it outside the normal React component tree.

index.html

To proceed, open the index.html file. You’ll find a div element with the ID root. This element serves as the container for all React-rendered content.

In the main.jsx file (for Vite) or the index.js file (for Create React App), you’ll observe that react-dom references this root element. It constructs a new DOM structure dedicated to React components and renders each component within this structure.

For our project, modify the index.html file by adding another div element with the ID modal. This will serve as the target for rendering our modal component outside the main React component tree.

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <link rel="icon" type="image/svg+xml" href="/vite.svg" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Sample React Portal</title>
  </head>
  <body>
    <div id="root"></div>
    <div id="modal"></div>
    <script type="module" src="/src/main.jsx"></script>
  </body>
</html>modal.css

Let’s apply some basic styling to our modal:

modal.css

p {
 color: black;
}
.modal {
 position: fixed;
 z-index: 2;
 top: 0;
 left: 0;
 width: 100%;
 height: 100%;
 background-color: rgba(0, 0, 0, 0.5);
 overflow: auto;
}
.modal-container {
 background-color: #fefffe;
 margin: 10% auto;
 width: 50%;
 padding: 10px;
}

Now, let’s start the server to view the components in action. Execute the following command and open the URL [http://127.0.0.1:5173/] in your browser:

`npm run dev`

Output:

React Portal Example

We can see that the button element is rendered within the main root container, representing the primary container for the entire React application. However, the modal component, despite being defined within the parent App component, is rendered in a separate target location in the DOM, typically outside the regular React component tree.

In our code, the modal component is a child of a div element within the App component, which is centrally located in the root container. React Portals enable us to define the modal component within the App component while rendering it in a different part of the DOM, outside the regular React tree structure. This functionality allows us to pass values to the modal’s props and render content within the modal component effectively.

Important Considerations and Potential Issues

React Portals offer valuable capabilities, but there are several important factors to consider:

1. Target DOM Nodes: When utilizing portals, ensure the target DOM node exists within the document. If the target node is missing, it can lead to errors or unintended behavior. It is prudent to confirm the presence of the target node before attempting to render portal content.

2. Event Propagation: Events emitted from a portal component will, by default, bubble up through the React tree and may trigger event handlers on parent components. This default behavior might not always be desirable. To control event propagation and limit event handling to within the portal, consider using stopPropagation() or other event management techniques.

3. Styling Challenges: Since portal components are rendered outside the standard React component hierarchy, applying CSS can be tricky. Styles that depend on parent-child relationships might not behave as expected. It is advisable to use specific CSS selectors or scoped styling to ensure that portal components are styled correctly.

4. Performance Considerations: React Portals can enhance performance in certain scenarios, but they can also introduce overhead. For instance, rendering a large list of items (e.g., 1,000 entries) through a portal requires two render passes: one for the virtual DOM and another for the actual DOM. This additional rendering step can impact performance, particularly with large amounts of content. To avoid performance issues, use portals selectively and only when necessary.

React Portals offer a robust solution for rendering components outside their parent component hierarchy, enabling the creation of complex and flexible user interfaces by placing components at any location within the DOM. Utilizing portals can help with separating concerns, enhancing accessibility, and providing greater adaptability in developing React applications.
To ensure effective use and avoid potential pitfalls, it is essential to adhere to the considerations and best practices outlined in this guide. With careful application, React Portals can significantly expand the capabilities of your React applications and improve the overall user experience.
Take advantage of React Portals to craft dynamic, interactive, and visually engaging components in your React projects.

Building Scalable Flutter Apps with Ease

Anagha GN — Thu, 25 Jul 2024 17:05:55 +0000

Building large-scale apps with diverse features and large developer teams requires a modular approach. Vyuh is a framework that uses a CMS-driven methodology to create scalable Flutter apps, allowing dynamic updates without App Store/Play Store releases. Born from the need to manage complex, content-driven features efficiently, Vyuh integrates with Sanity.io to drive the entire app experience.

It balances the flexibility of no-code tools for business teams with the power of full-code IDEs for developers. Vyuh separates responsibilities, enabling business teams to create app journeys through high-level components defined in the CMS, while developers focus on the implementation details in Flutter. This approach ensures modular, transferable features, controlled navigation, and seamless third-party integrations, all supported by a strong design system.

To get into its deep dive, let see below is a sample conversation that happened between Tara (who is a client and wanted to have the News app to be developed and deployed quickly) and Vivek (who is a Project Manager at NonStop IO Technologies Pvt Ltd) who knows the capability and adaptability of Vyuh framework very well. Below is the screenshot of the home page of their News App.

Project Manager (Vivek): Hello Tara, our News App has been Developed and Published!

Client(Tara): (After installing the app) Ahh! Wow really??? in just a week? (After checking the smoothness of the app)…This news app is Good for me!!. Just a few changes need to be made.

Vivek: yeah, sure! can you tell me which changes?

Tara: Instead of opening this News/Category Page on a separate page, can we open it from a dialog that will be coming from the bottom??

Vivek: Umm.. Do you mean BottomSheet, yes we can open it.

Tara: But Vivek, it will again take a day to make this change and then publish and then review. How hectic the process is! Isn’t it?

Vivek: But Tara, We can do it instantly, you just have to refresh your app

Tara: (Surprisingly) What?? are you joking??

Vivek: No Tara. Let me share my screen.

Tara: Wow.. that’s great! I just wanted to see if we could open this BottomSheet as a full screen. Just a thought. Can we do that now??

Vivek: Yes Sure! let me change it to a Full Screen. Please reopen/refresh your app

Tara: Wow, we are shuffling news also, that is great! but Vivek I feel this BottomSheet to be opened into a full screen, could be better. Is it? What if we could open up 80% of the full-screen height? What say, now feels like we need to wait for it again for a day.

Vivek: Na Tara, the same thing we can do again and instantly. Just we have to set a Size here.

Tara: Wow am I dreaming?? That's awesome Vivek. I wanted to know which tool you are using and how you developed it. Like you, can I also make these navigation changes without touching the code?

Vivek: Yes Tara, Sure you can make these changes. Here we have used a production-grade and CMS driven framework, that is Vyuh Framework.

Tara: Oh I see!! Vivek, can you give me a brief introduction?

Vivek: Yes Sure Tara! Vyuh is a tool that helps you build apps quickly and easily using Flutter. It uses a content management system (CMS — Sanity) to control the app, so you can make changes and add new features without needing a big team or a lot of time. This makes it super flexible and fun to work with.

Key features include:

1. Easy Updates: Change your app’s look and feel without going through the app store.
2. Custom Content: Create and manage different types of content easily.
3. Team-Friendly: Smaller teams can achieve big things with Vyuh.
4. Integrations: Easily connect with other services and tools.
5. Design Consistency: Maintain a consistent look across your app using a design system.
6. Powerful Tools: Manage app state, navigation, and more with ease.
7. Secure Storage: Keep your data safe.
Vyuh is perfect for companies wanting to build impressive apps quickly, experiment with different designs, and ensure a smooth and efficient development process.

Tara: Wait, Vivek! Sorry for interrupting you, can you please tell me “Create and manage different types of content easily.” What does that mean?

Vivek: Sure! For example Tara, here you can see my shared screen, right? If you want the sequence of this news home screen to change, say if you want News Group to be on the top then News List, and then News Carousel then you can make those changes from here quickly.

Tara: Ohhh I see… that’s very cool..

Vivek: Yes, Vyuh is a framework designed for building production-grade Flutter apps with a CMS-driven approach. This means it uses a Content Management System to manage and drive the app’s experience, significantly reducing the time needed to add new features with a smaller team. Vyuh offers incredible flexibility and control over your app’s journey and content, making UI development fun and dynamic.

The framework covers all the essentials for building large-scale apps, such as:

CMS-driven (aka Server-driven) UI
Custom Content types
Actions, Layouts, Conditions, Routes
Custom journeys & Conditional flows
Modular development of Features with independent teams
Third-party integrations via Plugins
Remote configuration with Zero App Store releases
Design System-based UX
Analytics
Feature Flags and A/B/N testing
Networking
Authentication
Navigation and Routing
State Management with the sophistication you desire
Error Handling
Theming
Storage and Secure Storage and much, much more…

Let me tell you the immediate benefits of Vyuh:

1. Faster App Deployments: Update your app experience without needing app store releases or deployments
2. Explorative Power: Try different designs and user experiences without changing any code
3. Small Teams, Big Outcomes: Build advanced apps quickly with smaller teams
4. Extensibility Built-In: Customize every part of your app, from content blocks to layouts and routes.
5. Design System First: Ensure a consistent look across your app using a design system
6. Easy Third-Party Integrations: Easily connect with various APIs (like ReST, GraphQL, WebSockets) for more features
7. Powerful State Management: Use MobX for flexible and sophisticated app experiences
8. Developer Productivity: Speed up development with dynamic updates through the CMS and Flutter’s Hot Reload
9. Growing Integrations: Access a growing set of plugins for everything from networking to payments
10. Fundamentals Ready: Start your app development with built-in basic features.
These benefits help enterprises build and manage their apps more efficiently, from flagship applications to platforms for white-labeled apps.

Tara: Wow Vivek, that’s awesome!! I wanted to know more about it.

Vivek: Sure, Tara you can visit this Vyuh website and as you can see in this live demo, here on this site you will get all about its features, integrations, and pricing which is very worth paying. Is it?

Tara: Yeah! So grateful to be part of Vyuh and NonStop IO Technologies.

Vivek: So happy to work with you. Thank you!

Tara: Bye Vivek. Thank you!

So after seeing this live demo given by Vivek, you can imagine how customizable, comprehensive, and extensible this Vyuh framework is! It provides us with the thought that rather than thinking of your App in terms of screens of content, you make an important mind-shift: “Think of your app as a collection of features where each feature contributes a set of components”. So let’s be ready for the surprises that are coming from Vyuh Framework. Stay tuned!

Hope you enjoyed this article!

Ref: Vyuh Framework