DEV Community: Sabber Hossain

Level Up Your React Skills: 10 Advanced Techniques for Senior Devs

Sabber Hossain — Thu, 30 Jan 2025 03:08:17 +0000

As React applications grow more complex, the patterns that were “just fine” when you were starting out might start to feel limiting. Maybe you’ve built a successful MVP, but now you’re noticing subtle performance issues. Or perhaps your state management has gotten tangled, and your data fetching logic has mushroomed into something unrecognisable.

1. Use useCallback with a Persistent Service Reference
We often see useCallback used to memoize inline arrow functions in event handlers. We do this to make sure that the function reference remains stable and does not trigger unnecessary re-renders when passed as a prop.

But as you level up, you’ll find you can use it to maintain stable references to more complex services—like WebSockets, workers, or other persistent resources—so they aren’t re-created unnecessarily on each render.

This approach builds on the basics of useRef and useCallback: you’re ensuring a long-lived service connection remains stable. This can save performance overhead and avoid unintended reconnections.

Example:

function createExpensiveService() {
  // Pretend this sets up a WebSocket or a shared worker
  return { send: (msg) => console.log('Sending:', msg) };
}

function usePersistentService() {
  const serviceRef = React.useRef(createExpensiveService());
  // Memoize the send function so it never changes
  const stableSend = React.useCallback((msg) => {
    serviceRef.current.send(msg);
  }, []);
  return stableSend;
}
function MyComponent() {
  const send = usePersistentService();
  return <button onClick={() => send('HELLO')}>Send Message</button>;
}

2. Using a Ref for Simplicity Instead of State
Sometimes we make the mistake to put all changing data in a state. But sometimes, you just need a value that won’t trigger a re-render. In these cases, using a ref is actually simpler and more efficient.

For example, imagine a counter that you just need to read and update internally without affecting the UI. A ref is perfect. No need for useState or fancy renders—just a stable box to store a changing value.

Example:

function MyCounter() {
  const counterRef = React.useRef(0);
  const increment = () => {
    counterRef.current++;
    console.log('Ref count is now:', counterRef.current);
  };
  return <button onClick={increment}>Increment (Check Console)</button>;
}

3. Using Suspense for Data Fetching with a Global Resource Cache
In many React apps, fetching data involves useEffect, loading states, and a bunch of manual checks. Suspense can simplify all of this by allowing components to “read” from a special data resource. If the data isn’t ready, the component automatically suspends, and React shows a fallback UI until the data arrives. This approach centralises loading logic, making your components cleaner and more focused on rendering.

Example (Conceptual):

function createResource(fetchFn) {
  let status = 'pending';
  let result;
  const promise = fetchFn().then(
    data => { status = 'success'; result = data; },
    err => { status = 'error'; result = err; }
  );
  return {
    read() {
      if (status === 'pending') throw promise;
      if (status === 'error') throw result;
      return result;
    }
  };
}

const userResource = createResource(() => fetch('/api/user').then(r => r.json()));

function UserProfile() {
  const user = userResource.read();
  return <div>Hello, {user.name}!</div>;
}

function App() {
  return (
    <React.Suspense fallback={<div>Loading user data...</div>}>
      <UserProfile />
    </React.Suspense>
  );
}

4. Suspense with Dynamic Imports and Preload Hints
Code splitting is common with React.lazy(), but you can take it further by preloading code before the user needs it. This reduces the wait time when they finally click a button or navigate to a certain route. Start loading your heavy components in the background so that they are instantly ready when needed.

Example:

const HeavyChart = React.lazy(() => import('./HeavyChart'));

function usePreloadHeavyChart() {
  React.useEffect(() => {
    import('./HeavyChart'); // start preloading on mount
  }, []);
}

function Dashboard() {
  usePreloadHeavyChart();
  return (
    <React.Suspense fallback={<div>Loading Chart...</div>}>
      <HeavyChart />
    </React.Suspense>
  );
}

5. Error Boundaries that Retry Automatically
At some point, something in your app may fail — maybe a network request or a lazy-loaded component. Traditional error boundaries show a fallback UI and stop there. By enhancing them, you can try recovering automatically, retrying after a short delay. This can be a great user experience improvement, turning a temporary glitch into a seamless recovery.

Example:

class AutoRetryErrorBoundary extends React.Component {
  state = { hasError: false, attempt: 0 };
  static getDerivedStateFromError() {
    return { hasError: true };
  }
  componentDidUpdate() {
    if (this.state.hasError) {
      setTimeout(() => {
        this.setState(s => ({ hasError: false, attempt: s.attempt + 1 }));
      }, 2000);
    }
  }
  render() {
    if (this.state.hasError) return <div>Retrying...</div>;
    return this.props.children(this.state.attempt);
  }
}

function UnstableComponent({ attempt }) {
  if (attempt < 2) throw new Error('Simulated Crash!');
  return <div>Loaded on attempt {attempt}</div>;
}

// Usage
<AutoRetryErrorBoundary>
  {(attempt) => <UnstableComponent attempt={attempt} />}
</AutoRetryErrorBoundary>

6. Virtualising Lists with Dynamic Item Heights
When you have huge lists, rendering every item can kill performance. Virtualisation libraries (like react-window) render only what’s visible. But what if items have unpredictable heights? You can measure them dynamically and feed those measurements back into your virtualisation logic. This reduces both memory usage and rendering time, keeping scrolling silky smooth.

Example:

import { VariableSizeList as List } from 'react-window';

function useDynamicMeasurement(items) {
  const sizeMap = React.useRef({});
  const refCallback = index => el => {
    if (el) {
      const height = el.getBoundingClientRect().height;
      sizeMap.current[index] = height;
    }
  };
  const getSize = index => sizeMap.current[index] || 50;
  return { refCallback, getSize };
}

function DynamicHeightList({ items }) {
  const { refCallback, getSize } = useDynamicMeasurement(items);
  return (
    <List height={400} itemCount={items.length} itemSize={getSize} width={300}>
      {({ index, style }) => (
        <div style={style} ref={refCallback(index)}>
          {items[index]}
        </div>
      )}
    </List>
  );
}

7. Using a State Machine for Complex UI Flows
When your component starts to feel like a spaghetti mess of if statements, a state machine can help. Tools like XState integrate nicely with React hooks. Instead of juggling multiple booleans, you define states and transitions in a single, clean chart. It’s a mental model shift: you’re writing a “map” of how your UI flows, making it easier to understand and debug.

Example:

import { useMachine } from '@xstate/react';
import { createMachine } from 'xstate';

const formMachine = createMachine({
  initial: 'editing',
  states: {
    editing: { on: { SUBMIT: 'validating' } },
    validating: {
      invoke: {
        src: 'validateForm',
        onDone: 'success',
        onError: 'error'
      }
    },
    success: {},
    error: {}
  }
});

function Form() {
  const [state, send] = useMachine(formMachine, {
    services: { validateForm: async () => {/* validation logic */} }
  });
  return (
    <button onClick={() => send('SUBMIT')}>
      {state.value === 'editing' ? 'Submit' : state.value.toString()}
    </button>
  );
}

8. Controlled Concurrency with useTransition and Task Queues
React 18 introduced useTransition to help you mark certain state updates as “non-urgent.” This can be a game-changer for performance under heavy load. Imagine fetching large amounts of data or performing expensive calculations. By deferring non-urgent updates, you keep the UI responsive and avoid locking up the main thread.

Example:

function ComplexUI() {
  const [isPending, startTransition] = React.useTransition();
  const [data, setData] = React.useState([]);

  function loadMore() {
    startTransition(() => {
      setData(old => [...old, ...generateMoreData()]);
    });
  }
  return (
    <>
      <button onClick={loadMore}>Load More</button>
      {isPending && <span>Loading more data...</span>}
      <List data={data} />
    </>
  );
}

9. useImperativeHandle to Create Controlled Component APIs
Sometimes you need a parent component to directly control a child — like calling childRef.current.focus() on a custom input. useImperativeHandle is a hook that lets you define what a parent sees when it uses ref on a child component. This is perfect for creating neat, controlled component APIs that feel like calling a method on a class instance, but in a React-friendly way.

Example:

const FancyInput = React.forwardRef((props, ref) => {
  const inputRef = React.useRef();
  React.useImperativeHandle(ref, () => ({
    focus: () => inputRef.current.focus(),
    getValue: () => inputRef.current.value
  }));
  return <input ref={inputRef} {...props} />;
});

function Parent() {
  const fancyRef = React.useRef();
  return (
    <>
      <FancyInput ref={fancyRef} />
      <button onClick={() => fancyRef.current.focus()}>Focus Input</button>
    </>
  );
}

10. Progressive Hydration with a Custom Hook
Server-side rendering (SSR) can get your content to the user fast, but hydrating a huge app all at once can slow interactivity. By delaying hydration for non-critical parts of your page, you can keep the initial load snappy. A custom hook that gradually hydrates certain components after a delay can make SSR feel even more seamless.

Example:

function useProgressiveHydration(delay = 1000) {
  const [hydrated, setHydrated] = React.useState(false);
  React.useEffect(() => {
    const t = setTimeout(() => setHydrated(true), delay);
    return () => clearTimeout(t);
  }, [delay]);
  return hydrated;
}

function HeavyComponent() {
  const hydrated = useProgressiveHydration();
  return hydrated ? <ExpensiveTree /> : <Placeholder />;
}

Final Thoughts
These techniques aren’t meant to be used all at once, and certainly not in every codebase. They’re tools — advanced ones — that become helpful as your applications and your skills grow. Consider these approaches when you start running into the limitations of simpler patterns.

MySQL Partitioning Guide: Improve Query Performance with Range, List, and Hash Partitioning

Sabber Hossain — Fri, 24 Jan 2025 03:16:59 +0000

MySQL পার্টিশনিং একটি ডেটাবেস অপ্টিমাইজেশন টেকনিক যা বড় টেবিলকে ছোট, সহজে ব্যবস্থাপনা করা যায় এমন অংশে বিভক্ত করে। এটি ডেটার সাথে কাজ করা সহজ করে তোলে, কোয়েরি পারফরম্যান্স বৃদ্ধি করে এবং বড় ডেটাবেজের স্কেলেবিলিটি নিশ্চিত করে।

MySQL-এ পার্টিশনিংয়ের ধারণা
পার্টিশনিং এমন একটি প্রক্রিয়া যা একটি টেবিলের ডেটা বিভিন্ন অংশে (partition) ভাগ করে, যেখানে প্রতিটি অংশ টেবিলের একটি লজিক্যাল সাবসেট। যখন একটি কোয়েরি চালানো হয়, তখন ডেটাবেজ ইঞ্জিন শুধুমাত্র প্রাসঙ্গিক পার্টিশনে কাজ করে, যা ডেটা স্ক্যানের পরিমাণ কমিয়ে আনে এবং কার্যক্ষমতা বৃদ্ধি করে।

পার্টিশনিংয়ের ধরন
১. Horizontal Partitioning
এটি ডেটার সারিগুলিকে বিভক্ত করার প্রক্রিয়া। প্রতিটি পার্টিশনে সমান সংখ্যক কলাম থাকে, কিন্তু সারির সংখ্যা আলাদা হতে পারে। MySQL-এর পার্টিশনিং মূলত এই প্রকারের উপর নির্ভর করে।

MySQL-এ আনুভূমিক পার্টিশনিং প্রধানত তিনটি ভিন্ন পদ্ধতিতে করা যায়:

ক. রেঞ্জ পার্টিশনিং (Range Partitioning)
রেঞ্জ পার্টিশনিংয়ের ক্ষেত্রে, একটি নির্দিষ্ট কলামের মান যদি একটি নির্দিষ্ট পরিসরের (range) মধ্যে পড়ে, তবে সেই সারি সংশ্লিষ্ট পার্টিশনে রাখা হয়।
উদাহরণস্বরূপ, যদি আপনার একটি sales টেবিল থাকে এবং এটি year কলামের ভিত্তিতে পার্টিশন করা হয়:

CREATE TABLE sales (
    id INT,
    amount DECIMAL(10, 2),
    year INT
)
PARTITION BY RANGE (year) (
    PARTITION p1 VALUES LESS THAN (2000),
    PARTITION p2 VALUES LESS THAN (2010),
    PARTITION p3 VALUES LESS THAN (2020),
    PARTITION p4 VALUES LESS THAN MAXVALUE
);

এখানে, ২০০০-এর আগে, ২০১০-এর আগে, এবং ২০২০-এর আগে আলাদা আলাদা পার্টিশনে ডেটা বিভক্ত হবে।

খ. লিস্ট পার্টিশনিং (List Partitioning)
লিস্ট পার্টিশনিংয়ে একটি কলামের নির্দিষ্ট মানের তালিকা অনুযায়ী সারিগুলো বিভিন্ন পার্টিশনে বিভক্ত করা হয়।
উদাহরণস্বরূপ:

CREATE TABLE sales (
    id INT,
    region VARCHAR(50),
    amount DECIMAL(10, 2)
)
PARTITION BY LIST COLUMNS (region) (
    PARTITION p1 VALUES IN ('North', 'East'),
    PARTITION p2 VALUES IN ('South', 'West')
);

এখানে অঞ্চল অনুযায়ী ডেটা বিভক্ত হচ্ছে।

গ. হ্যাশ পার্টিশনিং (Hash Partitioning)
হ্যাশ পার্টিশনিংয়ের ক্ষেত্রে একটি কলামের মান একটি হ্যাশ ফাংশনের মাধ্যমে বিভক্ত করা হয়। এটি ডেটা সমানভাবে বিতরণ নিশ্চিত করে।

CREATE TABLE sales (
    id INT,
    amount DECIMAL(10, 2)
)
PARTITION BY HASH (id) PARTITIONS 4;

এখানে, id কলামের মানের উপর ভিত্তি করে চারটি পার্টিশনে ডেটা স্বয়ংক্রিয়ভাবে বিভক্ত হবে।

২. উল্লম্ব পার্টিশনিং (Vertical Partitioning)
উল্লম্ব পার্টিশনিং হল ডেটার কলামগুলিকে বিভক্ত করার প্রক্রিয়া। প্রতিটি টেবিলে কিছু কলাম রাখা হয়, এবং অবশিষ্ট কলামগুলি ভিন্ন টেবিলে সংরক্ষণ করা হয়। যেহেতু MySQL উল্লম্ব পার্টিশনিং সমর্থন করে না, এটি ম্যানুয়ালি তৈরি করতে হয়।

উদাহরণস্বরূপ:
একটি বড় টেবিল users-এর সমস্ত কলাম একটি টেবিলে না রেখে, আপনি এটি দুটি টেবিলে বিভক্ত করতে পারেন:

user_personal (নাম, ইমেল, ফোন নম্বর)
user_credentials (ইউজারনেম, পাসওয়ার্ড)

MySQL পার্টিশনিং বড় ডেটাসেট পরিচালনা এবং পারফরম্যান্স অপ্টিমাইজেশনের জন্য অত্যন্ত কার্যকর। তবে এটি ব্যবহার করার আগে ডেটার প্রকৃতি এবং কোয়েরি প্যাটার্ন বোঝা অত্যন্ত গুরুত্বপূর্ণ। সঠিকভাবে পরিকল্পনা এবং বাস্তবায়ন করা হলে, পার্টিশনিং আপনার ডেটাবেজ সিস্টেমকে আরও দ্রুত, কার্যকর এবং সহজে পরিচালনাযোগ্য করে তুলতে পারে।

আরো বিস্তারিত জানতেঃ
https://tinyurl.com/bddj776w
https://tinyurl.com/eueh24j6

React Component Mounting with Rails: Simplifying Dynamic Interfaces

Sabber Hossain — Wed, 22 Jan 2025 02:12:55 +0000

Modern apps often require dynamic interfaces that can handle API calls, dynamic forms, and routing, and React is an excellent choice for this. However, React’s SPA (Single Page Application) approach doesn’t align well with Ruby on Rails, a full-stack framework that renders content server-side. While you can use React with Rails by setting up an API backend or using Webpack integration, this setup can add significant complexity and development time.

The Challenge
In projects like Raive and Dunu506, we needed dynamic features like complex wizards that required real-time interaction. Rails' traditional server-side rendering was cumbersome for these use cases, and React's dynamic nature was a clear fit.

But how could we use React without going full SPA? The solution is simple: we can mount React components in Rails views without abandoning Rails' server-side rendering approach.

The Solution
React components can be mounted on specific elements in a server-rendered view. Here's how we started:

Basic Mounting: In the app/javascript/packs/application.js, we mounted a simple React component:

import React from 'react'
import ReactDOM from 'react-dom'
import Hello from './Hello'

document.addEventListener('DOMContentLoaded', () => {
  const div = document.querySelector('#hello')

  if (div) {
    const props = JSON.parse(div.getAttribute('data-props'))
    ReactDOM.render(
      <Hello {...props} />,
      div
    )
  }
})

Reusability: We then created a reusable function to mount components dynamically:

import MyReactComponent from './MyReactComponent'

function mountComponent(id, Component) {
  document.addEventListener('DOMContentLoaded', () => {
    const div = document.querySelector(id)

    if (div) {
      const props = JSON.parse(div.getAttribute('data-props'))
      ReactDOM.render(
        <Component {...props} />,
        div
      )
    }
  })
}

mountComponent('#my-react-component', MyReactComponent)
Handling Multiple Components: For cases where we wanted to reuse the same component in multiple places, we generalized the approach:

function mountComponent(selector, Component) {
  document.addEventListener('DOMContentLoaded', () => {
    const elements = document.querySelectorAll(selector)

    elements.forEach(element => {
      const props = JSON.parse(element.getAttribute('data-props'))
      ReactDOM.render(
        <Component {...props} />,
        element
      )
    })
  })
}

Avoiding Conflicts: Instead of using id or class, we decided to use a custom data-component attribute to avoid conflicts with other CSS or JS classes:

function mountComponents(components) {
  document.addEventListener('DOMContentLoaded', () => {
    const roots = document.querySelectorAll('[data-component]')

    Array.from(roots).forEach((root) => {
      const props = JSON.parse(root.dataset.props)
      const Component = components[root.dataset.component]

      ReactDOM.render(
        <Component {...props} />,
        root
      )
    })
  })
}

mountComponents({
  MyReactComponent
})

The Result
This solution provided a clean, reusable way to mount React components in Rails views. It allowed us to leverage the dynamic power of React while maintaining the simplicity of Rails server-side rendering. We packaged this approach into a library that can be used in any project, saving development time and streamlining our workflow.

Conclusion
By using a data-component attribute and creating a simple function to mount React components dynamically, we successfully combined the power of React with the traditional server-rendered approach of Rails. This method is flexible, reusable, and clean, making it a great choice for teams needing dynamic interfaces in a Rails app.

Feel free to check out our GitHub repository for more details and to collaborate on this project!

Laravel Tip: whereHas or whereRelation?

Sabber Hossain — Fri, 17 Jan 2025 02:49:42 +0000

Welcome to my Laravel tips and tricks. We are going to learn about eloquent usage and its limitation with strength.

Scenario:
I have user and order table from where i need to pull those user orders which status is “completed”. Before Laravel 8, We used “whereHas” to compare any column value from related tables. But things were getting easier when Laravel 8 introduced “whereRelation” eloquent relation first.

Wow! Pretty shorter and easy syntax! 😯

Facts and Limitations:
Sometimes we think, whereRelation has better performance than whereHas. But we are wrong! While converting eloquent to SQL, I found both execute same query:

/-- whereHas query --/

select * from `users` where exists 
  (
    select * from `orders` 
    where `users`.`id` = `orders`.`created_by` 
    and `status` = ? 
    and `orders`.`deleted_at` is null
  ) 
and `users`.`deleted_at` is null

/-- whereRelation query --/

select * from `users` where exists 
  (
    select * from `orders` 
    where `users`.`id` = `orders`.`created_by` 
    and `status` = ? 
    and `orders`.`deleted_at` is null
  ) 
and `users`.`deleted_at` is null

So, It’s up to you that what you should use in where because whereRelation has limitation. When you want to check more than one condition you have to use “whereHas” because “whereRelation” only used for related single condition. For multiple condition whereHas use iterative condition in one subquery where whereRelation iterative subquery for each condition check in related table which isn’t totally feasible! 😒

So, think before you apply eloquent method for code maintainability. Happy Coding!💻