DEV Community: bhanu prasad

Understanding Apollo Client Cache: How to Manage and Update Nested Data Structures Effectively

bhanu prasad — Wed, 22 May 2024 05:39:34 +0000

Apollo Client’s cache is designed to handle normalized data, where each entity is stored separately and identified by unique keys. Understanding this normalization process and how identifiers work is key to managing and updating the cache effectively.

How Apollo Cache Works

Normalization: Apollo Client normalizes the data by splitting the result into individual entities, each identified by a unique key. This key is usually a combination of the entity’s type (__typename) and its unique identifier (id).
Entity Storage: Each entity is stored in the cache separately. Relationships between entities are maintained using references. For example, in your case, cma_report would be stored with references to its lead, which in turn references property.

Example Query

Consider your query:

{
  cma_report {
    id
    lead {
      property {
        id
      }
    }
  }
}

When this query is executed, Apollo Client might normalize the data like this:

cma_report:{id} -> {id, lead: lead:{id}}
lead:{id} -> {property: property:{id}}
property:{id} -> {id}

Updating the Cache

When you perform a mutation, Apollo Client tries to update the cache based on the data returned from the mutation. If the mutation payload doesn't include enough information to match the normalized entities in the cache, it may fail to find the relevant entity.

For example, if your mutation looks like this:

mutation {
  updateCmaReport(id: 1, lead: {property: {id: 2}}) {
    cma_report {
      id
      lead {
        property {
          id
        }
      }
    }
  }
}

Issue with Missing IDs

If the mutation payload does not include the id for lead, Apollo Client cannot find the corresponding entity in the cache. In your case, the structure Apollo Client expects might look like this:

cma_report:{id} -> {id, lead: lead:{id}}

If the mutation payload is missing the lead.id, it cannot match lead:{id}. Therefore, the cache update fails, and Apollo might fall back to refetching the entire parent query to ensure the cache is up-to-date.

Fixing the Issue

By including the id for lead in the mutation response, you provide Apollo Client with the necessary information to find and update the correct entity in the cache. This aligns the mutation payload with the structure in the cache, allowing for a successful update.

Summary

To ensure Apollo Client’s cache is updated correctly:

Always include id fields for all nested entities in both queries and mutation responses.
Understand the normalized structure and how entities are referenced in the cache.
Ensure your mutation payloads match the expected structure in the cache.

By following these practices, you can leverage Apollo Client’s cache effectively and avoid unnecessary refetches.

Effective Terraform Variable Management in GitHub Actions

bhanu prasad — Sat, 11 May 2024 18:38:29 +0000

Managing variables in Terraform is crucial for flexibility and security in infrastructure automation. Terraform offers several methods to define and prioritize variables, which is particularly important in environments where configurations must be dynamic and secure, such as in continuous integration/continuous deployment (CI/CD) pipelines

In this article, we'll delve into the practical use of these variable management strategies in Terraform, especially focusing on a typical CI/CD setup using GitHub Actions. We'll also clarify how Terraform decides which variable values to use when different methods are combined.

Different Methods to Add Variables in Terraform

Terraform supports multiple methods for variable definition, each suitable for different scenarios:

Variable Definitions in Configuration Files (variables.tf):
This is the most straightforward method where variables are defined with possible default values.
```
variable "machine_type" {
  description = "The type of the GCP instance"
  type        = string
  default     = "e2-micro"
}
```
Using terraform.tfvars Files:
These files are used for setting variable values that override the defaults specified in variables.tf. Terraform automatically loads these values unless specified otherwise.
```
machine_type = "n1-standard-1"
```
Environment Variables:
Terraform can also read from environment variables prefixed with TF_VAR_. This is useful for passing sensitive data or for overriding values in CI/CD pipelines without changing code.
```
export TF_VAR_machine_type="n1-standard-1"
```
Command-line Flags:
For temporary overrides, such as during a manual deployment, you can specify variables directly on the command line.
```
terraform apply -var="machine_type=n1-standard-1"
```

Order of Precedence in Terraform Variables

Terraform evaluates these variable sources according to a specific order of precedence:

Command-line flags
Environment variables
Terraform configuration files (terraform.tfvars or .auto.tfvars)
Variable defaults in variables.tf

Understanding this hierarchy is essential for effectively managing variable values across different environments and deployment phases.

Example: Using Variables in GitHub Actions

Let’s consider a GitHub Actions workflow designed to deploy infrastructure on Google Cloud Platform using Terraform:

name: Deploy GCP Infrastructure
on: [push]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout code
      uses: actions/checkout@v4
    - name: Set up Terraform
      uses: hashicorp/setup-terraform@v3
    - name: Set up Google Cloud credentials
      uses: google-github-actions/setup-gcloud@v2
      with:
        service_account_key: ${{ secrets.GCP_SA_KEY }}
        export_default_credentials: true
    - name: Create terraform.tfvars
      run: |
        echo "machine_type=\"n1-standard-1\"" > terraform.tfvars
        echo "region=\"us-central1\"" >> terraform.tfvars
    - name: Terraform Apply
      run: terraform apply -auto-approve
      env:
        TF_VAR_machine_type: ${{ secrets.MACHINE_TYPE }}
        TF_VAR_region: ${{ secrets.REGION }}

In this workflow:

terraform.tfvars is generated dynamically in one of the steps. It sets machine_type and region for the Terraform apply.
Environment variables (TF_VAR_machine_type and TF_VAR_region) are set in the Terraform Apply step using GitHub Secrets.

Given the order of precedence, the environment variables will override the values set in the terraform.tfvars file. This setup allows the workflow to configure defaults in terraform.tfvars while overriding these with more specific values securely managed through GitHub Secrets, ideal for different deployment environments or sensitive configurations.

Understanding how to manage and prioritize variable definitions in Terraform is key to deploying secure and adaptable infrastructure, particularly in automated environments like CI/CD pipelines. By strategically using GitHub Actions and Terraform together, developers can ensure that infrastructure deployments are both efficient and secure, aligning with best practices in DevOps environments.

Deploy Google Cloud Run with Terraform: Full Guide

bhanu prasad — Sat, 11 May 2024 18:08:05 +0000

Learn how to deploy a Google Cloud Run instance using Terraform, complete with a connection to a Cloud SQL instance, open IAM permissions, health checks, specified resource allocations, and environment variables.

What You'll Need

Before you start, ensure you have the following:

A Google Cloud account with billing enabled.
Terraform installed on your local machine. If not, download it from Terraform's official site.
Google Cloud CLI configured on your machine. Install and configure the Google Cloud CLI here.

Setting Up Your Terraform Configuration

Step 1: Initialize Your Terraform Project

Create a new directory for your Terraform configuration:

mkdir terraform-cloudrun
cd terraform-cloudrun

Now, create your main.tf file:

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 5.28.0"
    }
  }

  required_version = ">= 1.0"
}

provider "google" {
  project = "your-gcp-project-id"
  region  = "your-gcp-region"
}

Replace your-gcp-project-id and your-gcp-region with your actual Google Cloud project ID and region. This setup uses the environment variable GOOGLE_APPLICATION_CREDENTIALS for authentication, which should be set on the runner.

Step 2: Define Your Infrastructure

Cloud SQL Instance

Ensure your Cloud SQL instance is defined, either in Terraform or already existing:

resource "google_sql_database_instance" "default" {
  name             = "example-instance"
  database_version = "POSTGRES_15"
  region           = "us-central1"

  settings {
    tier = "db-f1-micro"
  }
}

Retrieving Secrets

Retrieve the database password securely from Google Secrets Manager:

data "google_secret_manager_secret_version" "db_pass" {
  secret = "db-password"
}

Ensure that the secret db-password exists in Google Secrets Manager with the appropriate permissions set for the service account used by Terraform.

Cloud Run Service

Define your Cloud Run service:

resource "google_cloud_run_service" "default" {
  name     = "example-service"
  location = "us-central1"

  template {
    spec {
      containers {
        image = "gcr.io/your-project-id/example-image"

        resources {
          limits {
            cpu    = "1000m"
            memory = "512Mi"
          }
        }

        env {
          name  = "DATABASE_URL"
          value = "postgres://username:${data.google_secret_manager_secret_version.db_pass.secret_data}@${google_sql_database_instance.default.private_ip}/dbname"
        }
      }

      service_account_name = google_service_account.default.email
    }
  }

  traffic {
    percent         = 100
    latest_revision = true
  }

  autogenerate_revision_name = true
}

IAM Permissions

Open IAM permissions for all users:

resource "google_cloud_run_service_iam_policy" "public" {
  location    = google_cloud_run_service.default.location
  project     = google_cloud_run_service.default.project
  service     = google_cloud_run_service.default.name

  policy_data = jsonencode({
    bindings = [
      {
        role    = "roles/run.invoker"
        members = ["allUsers"]
      },
    ]
  })
}

Step 3: Initialize and Apply Your Terraform Configuration

Run the following commands in your terminal:

terraform init
terraform plan
terraform apply -auto-approve

With these steps, you've successfully deployed a Google Cloud Run instance connected to a Cloud SQL instance with comprehensive configurations. This setup includes open IAM permissions, detailed health checks, specific resource allocations, and environment variables, all managed efficiently with Terraform.

Optimizing React Apps for Smooth UI Transitions and Enhanced Performance

bhanu prasad — Mon, 01 Apr 2024 12:25:52 +0000

In modern web applications, maintaining a responsive and smooth user interface is crucial for a positive user experience. However, intensive tasks like data fetching or processing can block the UI, making the application feel sluggish. React's useTransition hook and startTransition function offer a powerful solution to this challenge, allowing developers to prioritize user interactions over less critical updates. In this post, we'll explore how to utilize these tools to keep your app responsive, even during heavy rendering operations.

Understanding Non-Blocking State Updates

When React updates the state, it re-renders the component tree, which can be a blocking operation if the updates are complex. This means the main thread is occupied with rendering, delaying other tasks such as handling user inputs. Imagine you're cooking dinner but stop everything to answer the phone — dinner would be delayed. Similarly, in React, we want to ensure the UI remains responsive by allowing high-priority tasks (like user inputs) to interrupt lower-priority rendering tasks.

Enter useTransition

The useTransition hook provides a way to mark certain state updates as "transitions," signaling to React that these updates can be interrupted by more important tasks. It returns two values: isPending, indicating whether a transition is in progress, and startTransition, a function to trigger the transition.

Enhancing UI Responsiveness with useTransition

Let's dive into an example to see useTransition in action:

// TabContainer component manages which tab is currently active
export default function TabContainer() {
  const [tab, setTab] = useState('about');

  return (
    <Suspense fallback={<h1>🌀 Loading...</h1>}>
      <TabButton isActive={tab === 'about'} onClick={() => setTab('about')}>About</TabButton>
      <TabButton isActive={tab === 'posts'} onClick={() => setTab('posts')}>Posts</TabButton>
      <TabButton isActive={tab === 'contact'} onClick={() => setTab('contact')}>Contact</TabButton>
      <hr />
      {tab === 'about' && <AboutTab />}
      {tab === 'posts' && <PostsTab />}
      {tab === 'contact' && <ContactTab />}
    </Suspense>
  );
}

In the TabContainer, changing tabs is straightforward. However, imagine the "Posts" tab requires significant time to render due to heavy data processing. Without useTransition, clicking between tabs could freeze the UI, especially if "Posts" is selected.

jsx
Copy code
// TabButton component enhances user feedback during transitions
import { useTransition } from 'react';

export default function TabButton({ children, isActive, onClick }) {
  const [isPending, startTransition] = useTransition();

  if (isActive) {
    return <b>{children}</b>;
  }
  if (isPending) {
    return <b className="pending">{children}</b>;
  }
  return (
    <button onClick={() => {
      startTransition(() => {
        onClick();
      });
    }}>
      {children}
    </button>
  );
}

By wrapping the onClick event with startTransition, we ensure that tab changes are treated as lower priority. This allows the user to continue interacting with other parts of the UI, such as switching to a different tab, without waiting for the "Posts" tab to finish rendering.

Visual Feedback and User Experience

The isPending flag from useTransition can be used to provide visual feedback to users, such as changing the opacity of a loading tab. This signals to users that their action is being processed without locking them out of other interactions.

Advanced Considerations

Synchronous Updates: startTransition is designed for synchronous state updates. Asynchronous operations, like data fetching, should be handled separately, potentially with Suspense.
Best Practices: Use startTransition for updates that can be deferred without harming the user experience. Not every state update needs to be inside a transition.
Conclusion
useTransition and startTransition are invaluable tools for creating fluid, responsive web applications in React. By prioritizing user interactions and allowing non-urgent updates to be interruptible, developers can significantly enhance the user experience. Experiment with these tools in your projects, and observe the improvements in responsiveness and performance firsthand.

Try It Yourself

Check out the interactive demo here to see useTransition in action. Notice how the UI remains responsive, even when switching to a tab that requires significant rendering time.

Additional Resources

For more information on useTransition and performance optimization in React, refer to the (useTransition)[https://react.dev/reference/react/useTransition] documentation which has comprehensive examples.

Optimizing PostgreSQL Trigger Execution: Balancing Precision with Control

bhanu prasad — Sat, 30 Mar 2024 17:28:55 +0000

PostgreSQL triggers are powerful tools that allow developers to automatically execute custom functions before or after changes are made to the database. They're essential for maintaining data integrity, enforcing business rules, and logging. However, managing trigger execution—especially avoiding unwanted side effects or recursive triggers—requires strategic approaches. In this post, we'll explore two sophisticated methods: using pg_trigger_depth() for controlling first-level trigger execution and employing session variables to finely tune recursive trigger behavior.

Using `pg_trigger_depth()` for First-Level Trigger Execution

The Challenge of Side Effects

Triggers can sometimes cause unintended side effects. For example, an AFTER INSERT trigger on a table might unintentionally activate another trigger, leading to a cascade of trigger executions. This can be problematic when you wish to limit the execution to only the initial trigger, avoiding any subsequent, possibly recursive, activations.

The `pg_trigger_depth()` Solution

pg_trigger_depth() comes to the rescue in scenarios where you want to ensure that only the first-level trigger— the one directly resulting from a user's action—is executed, while preventing further, potentially recursive trigger executions.

Example Scenario

Consider an employees table where you want to log every insert operation to an audit_log table. However, you wish to avoid logging operations that are side effects of other triggers.

sqlCopy code
CREATE OR REPLACE FUNCTION log_employee_insert() RETURNS TRIGGER AS $$
BEGIN
    IF pg_trigger_depth() = 0 THEN
        INSERT INTO audit_log(operation, details)
        VALUES ('INSERT', row_to_json(NEW));
    END IF;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

In this setup, pg_trigger_depth() ensures that the audit log is only written for the top-level insert operations on the employees table, avoiding any entries that might be indirectly caused by other triggers.

Using Session Variables to Control Recursive Execution

The Complexity of Recursive Triggers

In more complex scenarios, especially those involving foreign key relationships, you might still want triggers to execute as a result of cascading actions or updates—without falling into the trap of infinite recursion. This is where session variables offer a nuanced control mechanism.

The Role of Session Variables

Session variables allow you to dynamically enable or disable certain triggers during a session. This approach is particularly useful when you want to avoid recursive trigger execution during operations like updates or deletes that the trigger itself performs.

Example Scenario

Imagine a teams_users table where updates to user roles might trigger a cascade of updates across related tables due to foreign key relationships. However, within these triggered actions, you want to prevent certain triggers from executing recursively.

sqlCopy code
CREATE OR REPLACE FUNCTION update_user_role() RETURNS TRIGGER AS $$
BEGIN
    IF current_setting('session.skip_recursive_trigger', TRUE) = 'true' THEN
        RETURN NEW;
    END IF;

    -- Trigger logic here
    UPDATE related_table SET ...
    -- Set session variable to prevent recursion
    PERFORM set_config('session.skip_recursive_trigger', 'true', false);

    -- Further operations that might otherwise trigger recursion

    -- Reset session variable
    PERFORM set_config('session.skip_recursive_trigger', 'false', false);
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

By toggling the session.skip_recursive_trigger variable, the function controls whether certain parts of its logic should be skipped, effectively guarding against unintended recursive trigger execution.

When to Use Each Approach

Use pg_trigger_depth() when you need to ensure that only the direct effects of an operation trigger subsequent actions. It's ideal for avoiding unintended cascading triggers, particularly when you're interested in capturing only the initial user-driven event.
Use session variables when you require a more granular control over trigger execution, especially to enable or disable triggers dynamically within a single session. This method shines in complex scenarios where operations involve multiple related triggers, but you wish to prevent recursive executions or specific trigger actions during certain operations.

Conclusion

Mastering the use of pg_trigger_depth() and session variables in PostgreSQL allows developers to elegantly manage and control trigger executions, safeguarding against unwanted recursive behaviors while maintaining the flexibility to implement complex business logic. By choosing the appropriate strategy based on the specific needs of your application, you can harness the full power of PostgreSQL triggers to maintain data integrity, enforce rules, and log activities efficiently.

Mastering React's cloneElement and Children.map: A Guide with Practical Code Examples

bhanu prasad — Wed, 27 Mar 2024 07:14:17 +0000

Creating dynamic and reusable components in React often involves understanding and leveraging more advanced concepts and patterns. Two particularly powerful features for handling component children are React.cloneElement and React.Children.map. Furthermore, the compound component pattern exemplifies how to structure complex component systems with clear, hierarchical relationships between components. This post will explore these concepts with practical examples, including how to create a flexible Tabs component and an intuitive Accordion.

Deep Dive into `React.cloneElement`

The React.cloneElement function enables developers to clone a React element, allowing modifications to its props and children. It's especially useful for enhancing or customizing children components passed to a parent component without altering the original element directly.

Example: Enhancing Children with cloneElement

const EnhancedContainer = ({ children }) => {
  const enhancedChildren = React.Children.map(children, child =>
    React.cloneElement(child, { className: 'enhanced' })
  );

  return <div className="container">{enhancedChildren}</div>;
};

// Usage
const App = () => (
  <EnhancedContainer>
    <h1>Enhanced Heading</h1>
    <p>This paragraph is enhanced.</p>
  </EnhancedContainer>
);

In this example, EnhancedContainer uses React.Children.map to iterate over its children, applying React.cloneElement to each child to add an enhanced class name.

Leveraging `React.Children.map`

React.Children.map is a utility that helps iterate over children, which could be a single element or an array of elements. It's invaluable for applying transformations or validations to child components in a flexible way.

Example: Conditional Styling with List Components

const List = ({ children, isOrdered }) => {
  const listItems = React.Children.map(children, child =>
    React.cloneElement(child, { isOrdered })
  );

  return isOrdered ? <ol>{listItems}</ol> : <ul>{listItems}</ul>;
};

const ListItem = ({ children, isOrdered }) => (
  <li className={isOrdered ? 'ordered' : 'unordered'}>{children}</li>
);

// Usage
const App = () => (
  <List isOrdered={true}>
    <ListItem>First Item</ListItem>
    <ListItem>Second Item</ListItem>
  </List>
);

Here, List takes ListItem components as children and dynamically adjusts their styling based on the isOrdered prop by utilizing both React.Children.map and React.cloneElement.

Advanced Example: Tabs Component

Building on these concepts, the compound component pattern allows for the creation of more complex UI structures, such as a Tabs component system where each Tab and its content are defined through sub-components for maximum flexibility.

import React, { useState, cloneElement, Children } from 'react';

const Tabs = ({ children }) => {
  const [activeIndex, setActiveIndex] = useState(0);
  const newChildren = Children.map(children, (child, index) => {
    if (child.type.displayName === 'TabPanel') {
      return cloneElement(child, { isActive: index === activeIndex });
    } else if (child.type.displayName === 'TabList') {
      return cloneElement(child, { setActiveIndex, activeIndex });
    } else {
      return child;
    }
  });

  return <div>{newChildren}</div>;
};

const TabList = ({ children, setActiveIndex, activeIndex }) => (
  <div>
    {Children.map(children, (child, index) =>
      cloneElement(child, {
        isActive: index === activeIndex,
        onClick: () => setActiveIndex(index),
      })
    )}
  </div>
);
TabList.displayName = 'TabList';

const Tab = ({ isActive, onClick, children }) => (
  <button className={isActive ? 'active' : ''} onClick={onClick}>
    {children}
  </button>
);
Tab.displayName = 'Tab';

const TabPanel = ({ isActive, children }) => (
  isActive ? <div>{children}</div> : null
);
TabPanel.displayName = 'TabPanel';

// Usage Example
const App = () => (
  <Tabs>
    <TabList>
      <Tab>Tab 1</Tab>
      <Tab>Tab 2</Tab>
      <Tab>Tab 3</Tab>
    </TabList>
    <TabPanel>Content 1</TabPanel>
    <TabPanel>Content 2</TabPanel>
    <TabPanel>Content 3</TabPanel>
  </Tabs>
);

Advanced Example: Accordion Component

Similarly, an Accordion component can be constructed using the compound component pattern to allow for an accordion where each panel can be individually controlled and styled.

import React, { useState, cloneElement, Children } from 'react';

const Accordion = ({ children }) => {
  const [activeIndex, setActiveIndex] = useState(null);

  const cloneChild = (child, index) => {
    if (child.type.displayName === 'AccordionItem') {
      return cloneElement(child, {
        isActive: index === activeIndex,
        onToggle: () => setActiveIndex(index === activeIndex ? null : index),
      });
    }
    return child;
  };

  return <div>{Children.map(children, cloneChild)}</div>;
};

Accordion.Item = ({ isActive, onToggle, children }) => (
  <div>
    {Children.map(children, child => {
      if (child.type.displayName === 'AccordionHeader') {
        return cloneElement(child, { onToggle });
      }
      return child;
    })}
    {isActive && children.find(child => child.type.displayName === 'AccordionBody')}
  </div>
);
Accordion.Item.displayName = 'AccordionItem';

Accordion.Header = ({ onToggle, children }) => (
  <button onClick={onToggle}>
    {children}
  </button>
);
Accordion.Header.displayName = 'AccordionHeader';

Accordion.Body = ({ children }) => (
  <div>{children}</div>
);
Accordion.Body.displayName = 'AccordionBody';

// Usage Example
const App = () => (
  <Accordion>
    <Accordion.Item>
      <Accordion.Header>Header 1</Accordion.Header>
      <Accordion.Body>Content 1</Accordion.Body>
    </Accordion.Item>
    <Accordion.Item>
      <Accordion.Header>Header 2</Accordion.Header>
      <Accordion.Body>Content 2</Accordion.Body>
    </Accordion.Item>
  </Accordion>
);

In JavaScript, functions are first-class objects, meaning they can have properties and methods just like any other object. This is a powerful feature of the language that React leverages for its component model. When you define a React component as a function, you're not just creating a blueprint for a piece of UI; you're also creating an object that can hold more than just its execution logic. By attaching other components (or any other values) as properties to a function component, you're essentially creating a namespace that groups related components together. This makes the component API cleaner and more modular, and it enhances the discoverability and readability of the components.

Here's a simple illustration of the concept:

function MyComponent() {
  // Component logic here
}

// Attaching a sub-component as a property
MyComponent.SubComponent = function() {
  // Sub-component logic here
};

// MyComponent is a function and an object at the same time
console.log(typeof MyComponent); // "function"
console.log(typeof MyComponent.SubComponent); // "function

These advanced examples showcase the power of React's composition model, combined with React.cloneElement and React.Children.map, to create flexible and reusable component architectures. Through these patterns and utilities, developers can build complex UI components that are both maintainable and adaptable to various contexts and requirements.

Streamlining Component Logic with "Children as Function" in React

bhanu prasad — Mon, 25 Mar 2024 17:47:20 +0000

The "Children as Function" pattern in React, distinct from the Render Props pattern, utilizes children as a function to dynamically render content. This approach allows parent components to dictate the rendering logic of their children in a highly flexible and reusable manner.

Core Advantages

Simplifies Component Composition: Avoids prop drilling and reduces component hierarchy complexity.
Enhances Flexibility: Enables dynamic rendering based on parent component's state or props.
Boosts Reusability: Facilitates the creation of utility components that can adapt their rendering based on different contexts.

Use Cases

1. Conditional Rendering Based on Device Type

The AutoSizer component provided is a practical example of the "Children as Function" pattern, designed to dynamically adjust the rendering of its children based on the parent component's size. This is particularly useful in responsive layouts and complex UIs where component size needs to adapt to available space.

First, let's create a utility hook useResizeRect to listen for resize events and provide the current dimensions of the AutoSizer component's element:

import React, { useState, useEffect } from 'react';

// Hook to listen for resize events and return the element's rect
const useResizeRect = (ref) => {
  const [rect, setRect] = useState(null);

  useEffect(() => {
    if (!ref.current) return;

    const setDimensions = () => {
      setRect(ref.current.getBoundingClientRect());
    };

    setDimensions();

    window.addEventListener('resize', setDimensions);
    return () => window.removeEventListener('resize', setDimensions);
  }, [ref]);

  return rect;
};

Next, let's implement the AutoSizer component as per the snippet you've provided. For the sake of completeness, we'll add the missing Box component, assuming it's a styled component that accepts flexGrow and css props. You might replace this with a div or any other container element suitable for your project:

import React, { useRef } from 'react';

// Assuming Box is a styled component or similar. Replace with your own implementation
const Box = ({ children, flexGrow, css, ref }) => (
  <div ref={ref} style={{ flexGrow, ...css }}>
    {children}
  </div>
);

const AutoSizer = ({ children }) => {
  const ref = useRef(null);
  const rect = useResizeRect(ref);

  return (
    <Box ref={ref} flexGrow={1} css={{ position: 'relative' }}>
      <Box css={{ position: 'absolute', top: 0, right: 0, bottom: 0, left: 0 }}>
        {rect && children({ width: rect.width, height: rect.height })}
      </Box>
    </Box>
  );
};

Finally, to use the AutoSizer, we can render a component inside it that adjusts its content or styling based on the provided width and height. Here's an example of a component that displays its dimensions:

const ResponsiveComponent = () => (
  <AutoSizer>
    {({ width, height }) => (
      <div style={{ width: '100%', height: '100%', backgroundColor: '#f0f0f0' }}>
        The size is {width}px by {height}px.
      </div>
    )}
  </AutoSizer>
);

export default ResponsiveComponent;

In this example, ResponsiveComponent uses the AutoSizer to adapt its content based on the available space, demonstrating how the "Children as Function" pattern can effectively manage dynamic sizing concerns in a React application. This pattern enables components to remain decoupled and reusable while still being able to respond to changes in their environment.

2. The `CustomizableForm` Component

This component renders a basic form and accepts an optional children prop. If children is a function, it calls this function with the form and additional props. Otherwise, it renders the form directly.

mport React from 'react';

// Mock functions for demonstration purposes
const useFormik = () => ({
  submitForm: () => alert('Form submitted'),
  resetForm: () => alert('Form reset'),
  // Add additional formik mock handlers and properties as needed
});

const CustomizableForm = ({ children }) => {
  const formik = useFormik(); // Assume this hook returns our form handlers and state

  // Define the default form UI
  const defaultForm = (
    <form onSubmit={formik.submitForm}>
      {/* Form fields go here */}
      <input type="text" placeholder="Enter something..." />
      <button type="submit">Submit</button>
    </form>
  );

  // If children is a function, call it with the form and additional props
  // Otherwise, render the default form
  return typeof children === 'function' ?
    children({
      form: defaultForm,
      submitForm: formik.submitForm,
      resetForm: formik.resetForm,
      // Include additional form state or handlers as needed
    }) :
    defaultForm;
};

export default CustomizableForm;

Usage Example

1. Using `CustomizableForm` Directly

When you want to use the CustomizableForm without customization, simply render it without passing children.

const App = () => (
  <CustomizableForm />
);

2. Customizing `CustomizableForm` with Additional Content

To customize the form, provide a function as children that returns a React element. This function receives an object containing the default form component and form handlers, allowing you to incorporate the form into a more complex structure or augment it with additional elements.

const CustomizedForm = () => (
  <CustomizableForm>
    {({ form, resetForm }) => (
      <>
        {form} {/* Render the default form */}
        <button onClick={resetForm} type="button">Reset</button>
        {/* Additional custom content can go here */}
      </>
    )}
  </CustomizableForm>
);

export default CustomizedForm;

This approach offers the best of both worlds: the simplicity and reuse of a standard form component with the flexibility to customize and extend it as needed, without duplicating the core form logic and markup across the application.

Optimizing PostgreSQL Queries with Function Volatility: Volatile, Stable, and Immutable

bhanu prasad — Fri, 22 Mar 2024 19:09:59 +0000

In PostgreSQL, the choice of function volatility—Volatile, Stable, and Immutable—plays a significant role in how the query optimizer plans and executes queries. Understanding these categories and applying them correctly can lead to substantial performance improvements. Let's dive deeper into each category, including comprehensive examples, to illustrate their use cases and how they influence PostgreSQL's optimizer.

1. Volatile Functions

When to Use: Volatile functions should be used when the function's output can change between calls with the same input parameters within the same session. This includes functions that make external calls, query or modify the database, or rely on non-deterministic sources like the current time.

Optimizer Behavior: The optimizer assumes that a volatile function's result can change on every call. Therefore, it will re-execute the function each time it appears in a query, avoiding any optimizations that rely on caching or pre-computation of function results.

Example:

CREATE OR REPLACE FUNCTION fetch_latest_price(stock_symbol text)
RETURNS numeric AS $$
BEGIN
    -- Imagine this function queries a constantly updating table of stock prices
    SELECT price INTO STRICT FROM stock_prices WHERE symbol = stock_symbol ORDER BY updated_at DESC LIMIT 1;
    RETURN price;
END;
$$ LANGUAGE plpgsql VOLATILE;

-- Example Query
SELECT stock_symbol, fetch_latest_price(stock_symbol)
FROM stocks
WHERE stock_symbol = 'AAPL';

In this example, fetch_latest_price is volatile because the price of a stock can change between calls. PostgreSQL will execute this function every time it's called, ensuring the latest price is retrieved.

2. Stable Functions

When to Use: Stable functions are appropriate when the function's output is consistent for the same input parameters within a single transaction or query execution, but may vary between transactions. These functions do not modify the database and are not affected by changes in database state that might occur while the query is running.

Optimizer Behavior: The optimizer can make certain assumptions about stable functions, such as reusing results within a single query execution. This can reduce the number of function calls, improving query performance.

Example:

CREATE OR REPLACE FUNCTION user_has_permission(user_id int, permission text)
RETURNS boolean AS $$
BEGIN
    -- Checks if a user has a specific permission, which is unlikely to change during the execution of a query
    SELECT EXISTS (
        SELECT 1 FROM user_permissions WHERE user_id = user_id AND permission = permission
    ) INTO result;
    RETURN result;
END;
$$ LANGUAGE plpgsql STABLE;

-- Example Query
SELECT username
FROM users
WHERE user_has_permission(id, 'view_dashboard');

In this scenario, user_has_permission is stable because, while user permissions can change over time, they're unlikely to change during the execution of a query. The optimizer can call the function once per user and reuse the result, avoiding unnecessary database lookups.

3. Immutable Functions

When to Use: Immutable functions should be used when the output is exclusively determined by the input parameters and does not change, regardless of session state or transaction changes.

Optimizer Behavior: The optimizer can apply the most aggressive optimizations with immutable functions. It can precompute results at query planning time, cache results across multiple executions, and use these in index expressions.

Example:

CREATE OR REPLACE FUNCTION add_numbers(a int, b int)
RETURNS int AS $$
BEGIN
    RETURN a + b;
END;
$$ LANGUAGE plpgsql IMMUTABLE;

-- Example Query
SELECT add_numbers(5, 10) AS result;

add_numbers is immutable because the sum of two numbers doesn't change. PostgreSQL can precompute calls to this function where possible, even optimizing queries that use add_numbers in conditions or stored procedures.

Properly categorizing functions as Volatile, Stable, or Immutable allows PostgreSQL's optimizer to make informed decisions, leading to more efficient execution plans. Volatile functions offer freshness, Stable functions balance predictability with flexibility, and Immutable functions enable the highest degree of optimization through result caching and precomputation. Understanding and leveraging these categories can greatly enhance the performance and scalability of PostgreSQL-based applications.

Handling NEW and OLD Immutability in PostgreSQL Triggers

bhanu prasad — Wed, 20 Mar 2024 17:19:35 +0000

In PostgreSQL, triggers are a powerful feature for automating responses to data changes within a table. A common hurdle is the immutability of NEW and OLD records, which cannot be directly modified within trigger functions. Here's a more code-focused exploration of how to navigate this constraint effectively.

Attempting Direct Modification

First, let's look at a typical attempt that won't work due to immutability:

sqlCopy code
CREATE OR REPLACE FUNCTION try_direct_update()
RETURNS TRIGGER AS $$
BEGIN
  -- Trying to directly update NEW's field (won't work)
  NEW.updated_at = NOW();
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

This code will fail because NEW cannot be directly modified in a trigger function.

A Workable Strategy

To update NEW without breaking the rules, we use a mutable copy:

sqlCopy code
CREATE OR REPLACE FUNCTION update_timestamp_correctly()
RETURNS TRIGGER AS $$
DECLARE
  mutable_new RECORD; -- A mutable copy of NEW
BEGIN
  mutable_new := NEW; -- Copy NEW to our mutable variable
  mutable_new.updated_at := NOW(); -- Update the timestamp on our copy
  RETURN mutable_new; -- Return the modified copy back to the trigger
END;
$$ LANGUAGE plpgsql;

This function effectively updates the updated_at timestamp by operating on a mutable copy of NEW.

Attaching the Function to a Trigger

To utilize our function, we attach it to a trigger on the desired table:

sqlCopy code
CREATE TRIGGER ensure_updated_timestamp
BEFORE UPDATE ON user_actions
FOR EACH ROW
EXECUTE FUNCTION update_timestamp_correctly();

This trigger setup ensures that any update to user_actions will automatically refresh the updated_at column, courtesy of our custom function.

Key Takeaways

Direct modification of NEW and OLD is off-limits in trigger functions due to their immutable nature.
The workaround involves creating a mutable copy of NEW, making the desired modifications, and then returning this copy.
This approach maintains data integrity and enables complex logic within triggers without direct modification restrictions.

By embracing this strategy, developers can craft sophisticated triggers that respect PostgreSQL's constraints while achieving desired data manipulations.

Understanding ON DELETE CASCADE and ON UPDATE CASCADE in SQL Foreign Key Relationships

bhanu prasad — Tue, 19 Mar 2024 13:30:36 +0000

When working with relational databases, it's essential to maintain the integrity and consistency of your data. Foreign key constraints play a crucial role in this, ensuring that relationships between tables remain consistent. Two critical options that can be applied to foreign key constraints are ON DELETE CASCADE and ON UPDATE CASCADE. These options automate the maintenance of referential integrity between tables, but it's important to understand how they work and when they should be used. In this blog post, we'll explore these options with examples for a clearer understanding.

Foreign Key Constraints: A Primer

Before diving into the specifics of cascading actions, let's briefly touch on what a foreign key constraint is. A foreign key in one table points to a primary key in another table, establishing a link between the two tables. This relationship enforces referential integrity, ensuring that the foreign key values in the referencing table correspond to primary key values in the referenced table.

ON DELETE CASCADE

The ON DELETE CASCADE option ensures that when a row in the parent (referenced) table is deleted, all corresponding rows in the child (referencing) table are automatically deleted. This is particularly useful in parent-child relationships where the existence of the child data is dependent on the parent data.

Example

Consider two tables: files and doc_reports_files. The files table contains file information, and doc_reports_files links these files to specific property reports.

files table:
- id (Primary Key)
- url
doc_reports_files table:
- property_id
- file_id (Foreign Key referencing files.id)

If we establish an ON DELETE CASCADE constraint on the file_id foreign key, deleting a row in files will automatically delete the corresponding rows in doc_reports_files.

SQL to create foreign key with ON DELETE CASCADE:


ALTER TABLE doc_reports_files
ADD CONSTRAINT fk_file_id
FOREIGN KEY (file_id)
REFERENCES files(id)
ON DELETE CASCADE;

Demonstration:


-- Assume there's a file with id = 1, and it's linked to several properties in doc_reports_files.
DELETE FROM files WHERE id = 1;
-- This will automatically delete all rows in doc_reports_files that reference file_id = 1.

ON UPDATE CASCADE

The ON UPDATE CASCADE option is similar to ON DELETE CASCADE but applies when the primary key in the parent table is updated. All corresponding foreign key values in the child table are automatically updated to match the new primary key value.

Example

Continuing with our previous example, if we apply ON UPDATE CASCADE to the file_id foreign key and then update a file's id in the files table, the file_id in doc_reports_files will also update to reflect this change.

SQL to add ON UPDATE CASCADE:


ALTER TABLE doc_reports_files
ADD CONSTRAINT fk_file_id
FOREIGN KEY (file_id)
REFERENCES files(id)
ON UPDATE CASCADE;

Demonstration:


-- Assume we want to update the id of a file from 1 to 101.
UPDATE files SET id = 101 WHERE id = 1;
-- This will automatically update all rows in doc_reports_files that referenced file_id = 1 to now reference file_id = 101.

Key Takeaways

ON DELETE CASCADE and ON UPDATE CASCADE automate the maintenance of referential integrity, simplifying database management and preventing orphaned records.
It's crucial to use these options judiciously, as cascading actions can lead to unintended data loss, especially with ON DELETE CASCADE.
Always ensure you have backup mechanisms in place before implementing cascading deletions or updates, particularly in production environments.

Understanding and correctly implementing ON DELETE CASCADE and ON UPDATE CASCADE can greatly enhance your database's integrity and consistency. However, remember that with great power comes great responsibility—use these features wisely to avoid unexpected data loss.

Enhancing Web Performance with HTML5 Data-* Attributes

bhanu prasad — Sat, 16 Mar 2024 13:03:39 +0000

Understanding Data-* Attributes

HTML5 introduced data-* attributes as a way for web developers to store custom data directly within HTML elements. These attributes allow us to embed additional information without using non-standard attributes or extra properties in the DOM. The beauty of data-* attributes lies in their flexibility and simplicity, enabling developers to keep the data associated with the specific HTML element, which is both accessible and manipulable by JavaScript.

<div id="userProfile" data-user-id="12345" data-user-role="admin"></div>

In this example, data-user-id and data-user-role are custom attributes added to a div element. These attributes can store information relevant to that particular element, which can later be accessed via JavaScript.

Advantages:

Simplicity: Easily embed custom data.
HTML5 Standard: Fully supported and consistent across modern browsers.
JavaScript Integration: Seamlessly access and manipulate with JavaScript using the dataset property.

Lazy-Loading IFrames with `Data-*` Attributes

A common challenge for web performance is optimizing the loading time of iframes. Traditionally, iframes are loaded immediately when the page loads, which can significantly slow down the page if there are multiple or heavy iframes. A solution is to implement lazy-loading of iframes using data-* attributes, specifically by utilizing data-src for the iframe's source URL instead of the standard src attribute.

How it Works:

Initially, set the iframe's src attribute to a data-src attribute to prevent it from loading.
Use the Intersection Observer API to monitor when the iframe comes into view.
Once the iframe is about to enter the viewport, dynamically set its src attribute from the data-src value, causing the iframe to load.

<iframe class="lazy-load" data-src="https://example.com" frameborder="0"></iframe>

// Wait until the DOM is fully loaded before running the script
document.addEventListener('DOMContentLoaded', () => {
    // Select all iframes with the class 'lazy-load'
    const iframes = document.querySelectorAll('iframe.lazy-load');

    // Create a new IntersectionObserver to watch when elements come into view
    const observer = new IntersectionObserver((entries) => {
        // Loop through each entry (iframe being observed)
        entries.forEach(entry => {
            // Check if the iframe is in the viewport
            if (entry.isIntersecting) {
                // Get the iframe element from the entry
                const iframe = entry.target;
                // Set the iframe's src attribute to the value stored in data-src
                iframe.src = iframe.dataset.src;
                // Stop observing the iframe as it has already been loaded
                observer.unobserve(iframe);
            }
        });
    });

    // Observe each iframe for when it enters the viewport
    iframes.forEach(iframe => observer.observe(iframe));
});

This technique significantly speeds up page load times by ensuring iframes only load when needed, reducing unnecessary resource loading and improving user experience.

Dynamic Image Galleries

Another practical application of data-* attributes is in creating dynamic image galleries. Instead of loading all images at once, which can be resource-intensive and slow down the page, you can use data-src for images and apply the same lazy-loading principle.

How it Works:

Store the image's URL in data-src instead of src.
As the user scrolls, use Intersection Observer to detect when an image is about to enter the viewport.
Dynamically load the image by setting src from data-src.

<img class="lazy-load" data-src="path/to/image.jpg" alt="Gallery image">

// Listen for the DOMContentLoaded event to ensure the DOM is fully loaded before executing the script.
document.addEventListener('DOMContentLoaded', () => {
    // Select all image elements with the class 'lazy-load'.
    const images = document.querySelectorAll('img.lazy-load');

    // Create a new IntersectionObserver object to detect when the selected images come into the viewport.
    const observer = new IntersectionObserver((entries) => {
        // Iterate over each entry in the array of observed elements.
        entries.forEach(entry => {
            // Check if the current entry (image) is intersecting with the viewport.
            if (entry.isIntersecting) {
                // Access the image element from the current entry.
                const img = entry.target;
                // Set the image's source attribute ('src') to the value of its 'data-src' attribute.
                // This triggers the loading of the image.
                img.src = img.dataset.src;
                // Stop observing the current image since it's now loaded, to improve performance.
                observer.unobserve(img);
            }
        });
    });

    // Use the observer to observe each image for viewport intersection.
    // This sets up the lazy-loading behavior.
    images.forEach(img => observer.observe(img));
});

This script enhances page performance by ensuring iframes are only loaded when they're about to be visible to the user, reducing unnecessary network requests and speeding up the initial page load time.

Just like Dad's quick glance to make sure it's the sports section and not the ads, your users will appreciate the snappy access to content with lazy-loaded image galleries.

Integrating Lazy Loading with React

While our previous examples showcased how to implement lazy loading in vanilla JavaScript, it's important to note that these principles are universally applicable and can be seamlessly integrated into modern JavaScript frameworks, including React. React's declarative nature and component-based architecture make it an ideal candidate for incorporating lazy loading in a way that is both efficient and straightforward.

React Example: Lazy-Loading Images

Let's consider a simple React component that lazy loads images:

import React, { useEffect, useRef } from 'react';

interface LazyImageProps extends React.ImgHTMLAttributes<HTMLImageElement> {
  src: string;
  alt?: string;
}

const LazyImage: React.FC<LazyImageProps> = ({ src, alt, ...props }) => {
  const imgRef = useRef<HTMLImageElement>(null);

  useEffect(() => {
    const observer = new IntersectionObserver(entries => {
      entries.forEach(entry => {
        if (entry.isIntersecting) {
          const img = entry.target as HTMLImageElement;
          img.src = img.dataset.src!;
          observer.unobserve(img);
        }
      });
    });

    if (imgRef.current) {
      observer.observe(imgRef.current);
    }

    return () => {
      if (imgRef.current) {
        observer.unobserve(imgRef.current);
      }
    };
  }, [src]);

  // Spread the rest of the props directly onto the img element
  return <img ref={imgRef} data-src={src} alt={alt} {...props} />;
};

export default LazyImage;

In this React component, useEffect and useRef hooks are utilized to replicate the lazy loading behavior. The useEffect hook sets up the Intersection Observer to monitor the image referenced by useRef. When the image comes into view, the data-src attribute is transferred to src, and the image is loaded.

The journey towards optimizing web performance transcends specific technologies, frameworks, or libraries. The principles behind lazy loading, leveraging HTML5's data-* attributes, and employing the Intersection Observer API, are universally applicable, offering a bridge between the foundational aspects of web development and the modern, component-based approach seen in frameworks like React.

As we've seen, whether you're working with vanilla JavaScript or a sophisticated framework, the goal remains the same: to enhance user experience through improved page load times and resource management. These techniques embody a framework-agnostic philosophy, ensuring that web developers can apply them across a multitude of projects, regardless of the underlying technology stack.

DEV Community: bhanu prasad

Understanding Apollo Client Cache: How to Manage and Update Nested Data Structures Effectively

How Apollo Cache Works

Example Query

Updating the Cache

Issue with Missing IDs

Fixing the Issue

Summary

Effective Terraform Variable Management in GitHub Actions

Different Methods to Add Variables in Terraform

Order of Precedence in Terraform Variables

Example: Using Variables in GitHub Actions

Deploy Google Cloud Run with Terraform: Full Guide

What You'll Need

Setting Up Your Terraform Configuration

Step 1: Initialize Your Terraform Project

Step 2: Define Your Infrastructure

Cloud SQL Instance

Retrieving Secrets

Cloud Run Service

IAM Permissions

Step 3: Initialize and Apply Your Terraform Configuration

Optimizing React Apps for Smooth UI Transitions and Enhanced Performance

Understanding Non-Blocking State Updates

Enter useTransition

Enhancing UI Responsiveness with useTransition

Visual Feedback and User Experience

Advanced Considerations

Try It Yourself

Additional Resources

Optimizing PostgreSQL Trigger Execution: Balancing Precision with Control

Using pg_trigger_depth() for First-Level Trigger Execution

The Challenge of Side Effects

The pg_trigger_depth() Solution

Example Scenario

Using Session Variables to Control Recursive Execution

The Complexity of Recursive Triggers

The Role of Session Variables

Example Scenario

When to Use Each Approach

Conclusion

Mastering React's cloneElement and Children.map: A Guide with Practical Code Examples

Deep Dive into React.cloneElement

Leveraging React.Children.map

Advanced Example: Tabs Component

Advanced Example: Accordion Component

Streamlining Component Logic with "Children as Function" in React

Core Advantages

Use Cases

1. Conditional Rendering Based on Device Type

2. The CustomizableForm Component

Usage Example

1. Using CustomizableForm Directly

2. Customizing CustomizableForm with Additional Content

Optimizing PostgreSQL Queries with Function Volatility: Volatile, Stable, and Immutable

1. Volatile Functions

2. Stable Functions

3. Immutable Functions

Handling NEW and OLD Immutability in PostgreSQL Triggers

Attempting Direct Modification

A Workable Strategy

Attaching the Function to a Trigger

Key Takeaways

Understanding ON DELETE CASCADE and ON UPDATE CASCADE in SQL Foreign Key Relationships

Foreign Key Constraints: A Primer

ON DELETE CASCADE

Example

ON UPDATE CASCADE

Example

Key Takeaways

Enhancing Web Performance with HTML5 Data-* Attributes

Understanding Data-* Attributes

Lazy-Loading IFrames with Data-* Attributes

Dynamic Image Galleries

Integrating Lazy Loading with React

React Example: Lazy-Loading Images

Using `pg_trigger_depth()` for First-Level Trigger Execution

The `pg_trigger_depth()` Solution

Deep Dive into `React.cloneElement`

Leveraging `React.Children.map`

2. The `CustomizableForm` Component

1. Using `CustomizableForm` Directly

2. Customizing `CustomizableForm` with Additional Content

Lazy-Loading IFrames with `Data-*` Attributes