DEV Community: Vikas Kumar

Unlocking Performance with AsyncJob: Specific Use Cases for I/O-Bound Operations

Vikas Kumar — Tue, 05 Aug 2025 08:44:58 +0000

The Elasticsearch Scaling Nightmare

Picture this: Your Rails application is humming along nicely until suddenly, user growth explodes. Great news, right? Not for our job queue.

In a previous application I worked on, we faced significant challenges scaling ActiveJobs, primarily due to numerous Elasticsearch indexing and other I/O-bound tasks. As our user base grew, thousands of small jobs overwhelmed our queue, creating a perfect storm of bottlenecks despite our best efforts at dynamic worker scaling.

We tried all the usual solutions:

Increased worker counts (which quickly hit diminishing returns)
Added more powerful servers (hello, spiraling AWS bills)
Optimized database connections (still not enough)
Tweaked job priorities and batching strategies (marginal improvements at best)

Yet we still hit hard limits with database connections, memory consumption, and infrastructure costs. The fundamental issue wasn’t our implementation,it was the thread-based job processing paradigm itself, which simply wasn’t optimized for our I/O-heavy workload.

Why AsyncJob for I/O-Bound Operations?

Enter AsyncJob, a gem that fundamentally reimagines how Ruby handles concurrent operations by leveraging Ruby fibers for cooperative multitasking.

The Thread vs. Fiber Difference

To understand why this matters, let’s break down what happens during an Elasticsearch indexing operation:

With traditional thread-based job processors (like SolidQueue):

A thread makes an HTTP request to Elasticsearch
The thread blocks while waiting for a response
The OS must context-switch to another thread
Each thread requires its own memory stack (often 1MB+ per thread)
Thread context switching has significant overhead

With fiber-based AsyncJob:

A fiber makes an HTTP request to Elasticsearch
The fiber voluntarily yields control while waiting
Another fiber can immediately use the same thread
Fibers are lightweight (a few KB each)
Switching between fibers is extremely efficient

This approach is exceptionally efficient for operations that spend most of their time waiting for external resources (I/O-bound), because instead of wasting CPU cycles waiting for responses, the system can process other jobs in the meantime.

Getting Started with AsyncJob

Integrating AsyncJob into your Rails application is surprisingly straightforward. The gem provides an adapter for ActiveJob, allowing you to selectively apply it to jobs that would benefit most from fiber-based processing.

Installation

Add these gems to your Gemfile:

gem 'async-job'
gem 'async-job-adapter-active_job'
gem 'async-job-processor-redis'

Then run:

bundle install

Configuration

For jobs that would benefit from fiber-based processing, simply specify AsyncJob as the queue adapter:

class SearchIndexingJob < ApplicationJob
  self.queue_adapter = :async_job # This job uses fibers
  queue_as :default

  def perform(document)
    # Your I/O-heavy code here
  end
end

You can continue using your existing queue adapter for other jobs:

class CPUIntensiveJob < ApplicationJob
  # This job still uses your default queue adapter
  queue_as :default

  def perform(data)
    # CPU-intensive operations
  end
end

For more detailed setup instructions, check out the AsyncJob Active Job Adapter documentation.

Benchmarking AsyncJob vs. SolidQueue for OpenSearch Operations

To validate my hypothesis about AsyncJob’s benefits for I/O-bound operations, I created a comprehensive benchmarking project comparing AsyncJob (fiber-based) with SolidQueue (thread-based) for OpenSearch indexing operations.

The Experiment Setup

I created two nearly identical jobs:

JobTest1Job - Using SolidQueue with synchronous HTTP calls
JobTest2Job - Using AsyncJob with asynchronous HTTP calls

Both jobs perform the same task: indexing documents in OpenSearch. To simulate real-world conditions with network latency, I added a 3-second artificial delay to each OpenSearch request, results were drastically different. But the results here are without any simulated delay.

The full code and detailed results are available in my GitHub repository.

========== BENCHMARK RESULTS ==========

----- Batch Size: 10 documents -----
SolidQueue (JobTest1Job):
  Avg Enqueue Time: 0.18s
  Avg Total Time: 1.19s
  Avg Throughput: 8.45 docs/second

AsyncJob (JobTest2Job):
  Avg Enqueue Time: 0.06s
  Avg Total Time: 1.06s
  Avg Throughput: 9.39 docs/second

Result: AsyncJob was 11.6% faster for 10 documents

----- Batch Size: 100 documents -----
SolidQueue (JobTest1Job):
  Avg Enqueue Time: 0.59s
  Avg Total Time: 1.6s
  Avg Throughput: 62.96 docs/second

AsyncJob (JobTest2Job):
  Avg Enqueue Time: 0.24s
  Avg Total Time: 1.25s
  Avg Throughput: 80.12 docs/second

Result: AsyncJob was 27.4% faster for 100 documents

----- Batch Size: 1000 documents -----
SolidQueue (JobTest1Job):
  Avg Enqueue Time: 4.8s
  Avg Total Time: 19.17s
  Avg Throughput: 54.78 docs/second

AsyncJob (JobTest2Job):
  Avg Enqueue Time: 2.25s
  Avg Total Time: 3.25s
  Avg Throughput: 307.48 docs/second

Result: AsyncJob was 489.1% faster for 1000 documents

========================================

========== RESOURCE USAGE METRICS ==========

----- SOLID_QUEUE Resource Usage -----
Memory Usage:
  Average: 128.69 MB
  Maximum: 177.19 MB
CPU Usage:
  Average per job: 28.4549 seconds
  Total CPU time: 74295.6439 seconds

----- ASYNC_JOB Resource Usage -----
Memory Usage:
  Average: 89.42 MB
  Maximum: 118.83 MB
CPU Usage:
  Average per job: 3.128 seconds
  Total CPU time: 5864.9192 seconds

----- Comparison -----
Memory Usage: AsyncJob uses -30.51% less memory than SolidQueue
CPU Usage: AsyncJob uses -92.11% less CPU time than SolidQueue

Note: For solid queue, I have used 1 worker with 3 threads, which is a default configuration for solid queue.

Analyzing the Results

Performance Scaling with Batch Size

The most striking finding from the benchmarks is how AsyncJob’s advantage scales with batch size:

Batch Size	Performance Advantage
10 documents	AsyncJob was 11.6% faster
100 documents	AsyncJob was 27.4% faster
1000 documents	AsyncJob was 489.1% faster

Key Insight: AsyncJob’s performance advantage dramatically increases with the number of I/O operations. For small workloads, the difference is noticeable but modest. For large workloads, the difference is transformative.

Resource Efficiency

Beyond raw speed, the resource efficiency gains are equally impressive:

Memory Usage: AsyncJob uses 30.5% less memory than SolidQueue (89.42 MB vs 128.69 MB)
CPU Usage: AsyncJob uses 92.1% less CPU time than SolidQueue (5,865 seconds vs 74,296 seconds)

This translates to significant infrastructure cost savings at scale.

The Secret Sauce: Async HTTP Client

A key part of my implementation was creating a fiber-aware HTTP client for OpenSearch. Here’s a simplified version:

class AsyncOpenSearchClient
  def index(index:, id: nil, body:)
    # Return an Async task that performs the request asynchronously
    Async do |task|  
      # Make the request asynchronously
      response = Async::HTTP::Internet.post(url, headers, json_body)

      # Process response...
    end
  end
end

This client ensures that while waiting for HTTP responses, other fibers can continue processing, maximizing throughput.

When to Use AsyncJob

Based on my benchmarks and some research (Google and AI), AsyncJob is ideal for:

1. Search Engine Indexing

This was our primary pain point. AsyncJob transforms Elasticsearch/OpenSearch indexing by efficiently switching fibers during network I/O waits, allowing concurrent indexing operations.

class SearchIndexingJob < ApplicationJob
  self.queue_adapter = :async_job
  queue_as :default

  def perform(document)
    # Each index operation is an I/O operation where AsyncJob can yield
    search_client.index(
      index: "content",
      id: document.id,
      body: document.to_indexed_json
    )
  end
end

2. API Integrations

Jobs that make external API calls are perfect candidates for AsyncJob:

class NotificationJob < ApplicationJob
  self.queue_adapter = :async_job
  queue_as :default

  def perform(user_id, message)
    # Multiple API calls can run concurrently
    push_notification_service.send(user_id, message)
    slack_service.notify(message)
    analytics_service.track("notification_sent", user_id)
  end
end

3. LLM Operations

Large Language Model API calls typically have high latency, making them ideal for AsyncJob:

class AIProcessingJob < ApplicationJob
  self.queue_adapter = :async_job
  queue_as :default

  def perform(documents)
    # Process multiple documents concurrently
    documents.each do |doc|
      summary = llm_client.summarize(doc.content)
      doc.update(ai_summary: summary)
    end
  end
end

When NOT to Use AsyncJob

CPU-Intensive Operations : If your job is CPU-bound (complex calculations, image processing), traditional thread-based queues may perform better.
Very Short-Running Jobs : For jobs that complete in milliseconds with minimal I/O, the overhead of fiber management might not be worth it.
Jobs with Non-Fiber-Aware Dependencies : Some gems and libraries aren’t fiber-aware and may block fibers, negating AsyncJob’s benefits.
Jobs Requiring Robust Error Handling : AsyncJob currently lacks some of the error handling capabilities found in more mature job processors.

Important Considerations: Error Handling with AsyncJob

While AsyncJob offers impressive performance benefits, it’s important to be aware of its current limitations in error handling:

Limited Built-in Error Handling
Manual Error Logging Required
Monitoring Challenges

Conclusion: A Game-Changer for I/O-Heavy Workloads

For applications with significant I/O-bound job processing needs, AsyncJob represents a paradigm shift in performance and efficiency. My benchmarks show that it’s not just marginally better—it can be 5x faster while using 30% less memory and 90% less CPU time.

The best part? You can gradually adopt AsyncJob for specific jobs without changing your entire infrastructure. Start by identifying your most I/O-intensive jobs and convert them first to see immediate benefits.

If your Rails application is struggling with I/O-bound job processing, AsyncJob might just be the solution you’ve been looking for.

(Note: I have not used it extensively in production yet, but the benchmarks show promising results.)

How to Use Tiptap's Collaboration Feature with Rails Action Cable

Vikas Kumar — Tue, 18 Jun 2024 15:25:00 +0000

In this post, we’ll walk through setting up Tiptap’s collaboration feature with Rails Action Cable and ReactJs. Tiptap is a powerful headless editor built on ProseMirror, and when combined with Y.js, it allows for real-time collaborative editing. We’ll use Mantine component libaray, but it’s not mandatory for this setup.

If you prefer to dive directly into the code, check out the example on Github

youtube-nocookie.com

Prerequisites

Ensure you have the following installed:

Ruby on Rails
Redis
Node.js and Yarn
Your preferred mehtod of React Setup with Rails

Step 1: Setting Up Mantine

First, we’ll set up Mantine for styling. Follow the Mantine guide for Vite to install the necessary packages: (Same method worked for me using esbuild in my setup. You can do it you own way or choose not to use Mantine)

yarn add @mantine/core @mantine/hooks @mantine/tiptap @tabler/icons-react @tiptap/react @tiptap/extension-link @tiptap/starter-kit @tiptap/extension-placeholder @tiptap/extension-collaboration-cursor @tiptap/extension-collaboration yjs y-prosemirror
yarn add --dev postcss postcss-preset-mantine postcss-simple-vars

Note: This setup includes both Mantine and Tiptap. If you do not require Mantine, skip installing Mantine-related dependencies.

Step 2: Install Rails Dependencies

bundle add redis y-rb_actioncable y-rb

Here we are installing Y.js adapter for Ruby and Action Cable.

Step 3: Configure Tiptap with Collaboration

In the Tiptap setup, configure the StarterKit with history: false as the Collaboration extension comes with its own history management. Additionally, we’ll add a random color generator for collaboration cursors.

function getRandomColor() {
    const colors = ["#ff901f", "#ff2975", "#f222ff", "#8c1eff"];

    const selectedIndex = Math.floor(Math.random() * (colors.length - 1));
    return colors[selectedIndex];
}


const editor = useEditor({
        extensions: [
            StarterKit.configure({ history: false }),
            Underline,
            Link,
            Superscript,
            SubScript,
            Highlight,
            TextAlign.configure({ types: ['heading', 'paragraph'] }),
            Placeholder.configure({ placeholder: 'This is placeholder' }),
            Collaboration.configure({
                document: doc // Configure Y.Doc for collaboration
            }),
            CollaborationCursor.configure({
                provider,
                user: {
                    name: "Vikas",
                    color: getRandomColor()
                }
            })
        ]
    });

Code to connect with websocket provided by ActionCable. Don’t worry about the channel creation now, we will create it later. Assuming channel name will be SyncChannel we will add following code. (Here id is hardcoded, as this is just a demo. we won’t be using proper auth in backend as well to keep things simple)

// ... other imports
import { createConsumer } from "@rails/actioncable"
import { WebsocketProvider } from "@y-rb/actioncable";

const consumer = createConsumer();
const doc = new Y.Doc()

const provider = new WebsocketProvider(
    doc,
    consumer,
    "SyncChannel",
    {
        id: 1
    }
);

// ... other codes

You can see full frontend code in App.jsx. This contains everything in a single file which is not great but good enough for this case.

Step 4: Set Up Rails Action Cable

Create a new channel name SyncChannel at app/channels/sync_channel.rb.

# frozen_string_literal: true
class SyncChannel < ApplicationCable::Channel
  include Y::Actioncable::Sync

  def subscribed
    # initiate sync & subscribe to updates, with optional persistence mechanism
    sync_for(session) { |id, update| save_doc(id, update) }
  end

  def receive(message)
    # broadcast update to all connected clients on all servers
    sync_to(session, message)
  end

  def doc
    @doc ||= load { |id| load_doc(id) }
  end

  private

  def session
    @session ||= Session.new(params[:id])
  end

  def load_doc(id)
    data = REDIS.get(id)
    data = data.unpack("C*") unless data.nil?
    data
  end

  def save_doc(id, state)
    REDIS.set(id, state.pack("C*"))
  end
end

This has Redis initialized as REDIS, replace it with your Redis variable name. We also created a Session model for sync_for mehtod. You can check documentation for sync_for here.

# frozen_string_literal: true

class Session
  attr_reader :id

  def initialize(id)
    @id = id
  end

  def to_s
    "sessions:#{id}"
  end
end

And finally ApplicationCable::Connection will be as follows

module ApplicationCable
  class Connection < ActionCable::Connection::Base
    identified_by :id

    def connect
      self.id = SecureRandom.uuid
    end
  end
end

Step 6: Add Styles for Collaboration Cursor (Option)

Everything should be working by now. In this step the cursor was looking odd, so some CSS can be add to make it look good.

Finally you can run your rails server and it should be good to go once we add all missing piecies specially authorisation.

Conclusion

By following these steps, you should have a real-time collaborative editor up and running using Tiptap, Y.js, and Rails Action Cable. While we used Mantine for styling in this demo, you can customize the styling as per your requirements. This setup provides a robust foundation for building collaborative applications with rich text editing capabilities.

Seamless Remote Development with Any IDE Using Unison for Bidirectional SSH Sync

Vikas Kumar — Wed, 15 May 2024 06:21:00 +0000

If your development environment is on a remote server, you might need to code on the remote machine itself to see the effects of your changes in real time. This scenario is fairly common these days as applications become more complex, and setting up a local development environment requires extensive configuration or mocking of the resources used in the app.

In this case, you are left with very few options for code editors. Either you have to use CLI-based editors such as Vim, or you can use VSCode with the Remote SSH extension. Even with the extension, there are some issues related to code analysis and code completion. These processes have to happen on the remote machine, making your powerful local PC underutilized. And if you want to use Zed or Xcode, you are out of luck.

So, the solution is to have a local copy that is synced with the remote SSH directory. You can use several tools for this:

Rsync:
- Unidirectional sync, which might be fine for development as you will use the local machine's copy to manage changes on the SSH server.
- Does not support file deletion.
SSHFS:
- Limited support on macOS.
- Requires kernel changes, making it impractical for use on some machines.
Unison:
- Supports bidirectional sync.
- Handles file deletions.
- Fault-tolerant: even if the connection breaks, you can restart it, and it will continue syncing from the last known point.

This leaves Unison as the ideal choice for me.

Unison has fairly good documentation; you can go ahead and check their documents and explore on your own.

Installing Unison

You need to install Unison on both the host and remote machine. If you don't have sudo access on the remote machine, don't worry; you can download the binary and keep it anywhere.

Installing Unison on Mac local machine:
- brew install unison
- brew install autozimu/homebrew-formulas/unison-fsmonitor
For Linux, you can follow the official guide.
Make sure to create a local folder to sync code from the remote machine.
Run a test connection:
- Example command: unison -testServer ssh://user@remotehostname/path/to/folder /path/to/folder
- If you get an error that Unison is not found on the remote server, specify the exact path to Unison using -servercmd. For example: unison -testServer ssh://user@remotehostname/path/to/folder /path/to/folder -servercmd /home/path/to/unison/bin/unison.
Final command for syncing:
- Once the connection test is successful, start syncing with the final command:
```
  unison ssh://user@remotehostname/path/to/folder /path/to/folder -servercmd /home/path/to/unison/bin/unison -ignore "BelowPath node_modules" -ignore "BelowPath .git" -force newer -repeat watch
```
- This command will sync all files and continue monitoring for further changes in the background while you develop. If you want to know the meaning of flags used here like ignore, force etc, you can check Unison user mannual.

You can use any code editor to modify the local copy, and Unison will automatically sync the changes.

Stop using serverless-webpack for AWS Lambda

Vikas Kumar — Thu, 06 Oct 2022 10:08:00 +0000

I see that nodejs lambda projects are built using serverless and often include serverless-webpack. It is used to implement babel and get the latest javascript syntaxes, especially module and top-level awaits.

But as per this blog post, the AWS lambda environment already supports these features, so we should no longer need to use serverless-webpack.

There are some cons that I face while using webpack in serverless.

Code is transpiled (and optionally minified), making it challenging to debug from logs, as line numbers and function names may not be the same per your development environment.
Using ESM only module is not straightforward. Such as node-fetch and d3, and the ESM-only module list is growing daily.
There could also be a performance impact as the code will be converted to commonJS, and this benchmark test shows that commonsJS could perform 43% worse than ESM.

There are other benefits of babel and webpack besides transpiling to commonJS. But these are mostly catered towards browsers and not serverside usage.

How to use ESM in serverless? Just add "type": "module" in pacakge.json in it will work in node 14.x and node 16.x.

Journey of building a game using the Flutter

Vikas Kumar — Sat, 19 Feb 2022 03:47:00 +0000

For the last few weeks, I have been working on a React Native project for work. So this was my first experience writing “real” mobile apps. Before that, I only wrapped PWA’s as APK and called myself a mobile developer 😎.

React-Native came naturally to me after climbing some learning curves as a React Developer. So, now I wanted to check out the buzz around Flutter.

So last weekend was a fine sunny day which is quite pleasing in the late winter season. It might not be winter from many people’s standard. I opened the Flutter documentation getting started page. The installation file was quite big compared to react-native and it made my expectations high.

At this point, I knew nothing about dart and Flutter, how it works and how to write code. But the Flutter had an excellent write-up comparing React-Native to Dart and Flutter. It helped me directly dive into building things without learning anything. I got pumped up to create something; I thought of a real simple application/game that is just sorting a list of cities so that traversing through all cities in order will be optimal. It’s not a fair game from the graphics standard, 😥 but good enough for me.

The app uses a list of cities downloaded from simplemaps.com and used a geometry formula to calculate the distance. After a day of playing out, I was able to finish it with the help of a lot of google, stack overflow, and 3rd party packages.

It almost feels like magic that I still don’t know dart language correctly, but my app is running. Flutter dev tools are excellent compared to React-Native, which helped me identify and fix issues more quickly.

I published my app just for fun ☺️ on the PlayStore, and if you are interested, you can also check out the code.

Animate SVG in React Native

Vikas Kumar — Sun, 06 Feb 2022 08:00:00 +0000

Here, by animating SVG, I mean to change the property of SVG elements dynamically, which will look live-like.

In react native, we can generate/render an SVG using the react-native-svg library. A complex SVG comprises many more minor elements that could be animated individually. But here, for example, we will take only one piece, a circle.

The following code will draw a circle with a radius of 50 units.

<Svg width={200} height={200}>
  <Circle cx="55" cy="55" r="50" stroke="black" strokeWidth={5} />
</Svg>

Suppose we want to animate it to become large and small. To achieve this, I will use React Native Reanimated. To learn more about it, you can check out its documentation.

Logically, I am trying to increase or decrease the radius.

Since the radius value is a prop, I will use useAnimatedProps. But, first of all, convert Circle to an animated component.

const AnimatedCircle = Animated.createAnimatedComponent(Circle);

Now, I can re-write component as

<Svg width={200} height={200}>
  <AnimatedCircle cx="55" cy="55" r="50" stroke="black" strokeWidth={5} />
</Svg>

Next step is to store the stroke width and radius. width can be stored in a simple constat, but for the radius we will use useSharedValue, so that it can be used by woklet to animate.

export default ()=>{
  const radius = useSharedValue(50);
  const strokeWidth = 5;

  return (
    <Svg width={200} height={200}>
      <AnimatedCircle
        cx={`${radius.value + strokeWidth}`}
        cy={`${radius.value + strokeWidth}`}
        r={`${radius.value}`}
        stroke="black"
        strokeWidth={strokeWidth}
      />
    </Svg>
  )
}

Here, I need some event or action to trigger the radius change. I’ll use a button press. (withSpring is default provided animation which is not necessary to use but this looks cool 🤞)

<Button mode="contained" onPress={() => {
  if(radius.value < 80) {
  radius.value = withSpring(80)
  }else{
    radius.value = withSpring(50)
  }
}}>
  Press
</Button>

You’ll notice that even after pressing the button, nothing happens. It is because change of sharedValue doesn’t trigger re-render of the react component. finally animated props comes into the picture. Instead of passing prop directly, we will pass it using animated prop.

const animatedProps = useAnimatedProps(() => ({
  cx: `${radius.value + strokeWidth}`,
  cy: `${radius.value + strokeWidth}`,
  r:`${radius.value}`
}));


<Svg width={200} height={200}>
  <AnimatedCircle
    animatedProps={animatedProps}
    stroke="black"
    strokeWidth={strokeWidth}
  />
</Svg>

Result, is something like this.

This is a relatively simple example, but I hope I successfully demonstrated the possibilities. Here is the link of complete code of the result if you are interested.

Handling multiple stores in a React-Redux application

Vikas Kumar — Mon, 11 Oct 2021 18:57:00 +0000

In a react-redux application, it is a good practice to have only one redux store. But if for some weird/“special” reason if you have to have more than one store, you will face some problems.

The most common problem is that if we wrap a component with a provider and then wrap a child component with another provider, it’s not easy to subscribe to the store of top-level provider.

const Component1 = () => {
  return (
    <Provider store={store1}>
      <Provider store={store2}>
        <Component2 />
      </Provider>
    </Provider>
  );
};

It’s so confusing that within a few iterations of development, you’ll find yourself using providers on each component, and not being able to read values from both the stores in a single component will frustrate you.

To manage this elegantly, we can do some setup which will ease the things.

For this, we will need react-redux 7 or greater. Because versions older than it doesn’t use react’s context API. And we will be using contexts to access multiple stores without wrapping with the providers again and again.

Create a context for each store. You can also import ReactReduxContext from react-redux and use it for one of the stores, which you want to make default.

const store1Context = React.createContext();
const store2Context = React.createContext();

Now wrap the root component of the react application with a provider for each store, passing the contexts as props.

<Provider store={store1} context={store1Context}>
  <Provider store={store2} context={store2Context}>
    <App/>
  </Provider>
</Provider>

We also need to create custom dispatch and selector hooks. If you use the default hooks (useSelector, useDispatch), it will use the store with default context, if any.

export const useStore1Dispatch = createDispatchHook(store1Context);
export const useStore1Selector = createSelectorHook(store1Context);

export const useStore2Dispatch = createDispatchHook(store2Context);
export const useStore2Selector = createSelectorHook(store2Context);

From further development, you can use these custom selector and dispatch hooks to use the preferred store in any of the components throughout the application.

If you prefer to connect HOC, then you can do

connect(mapStateToProps, mapDispatchtoProps,mergeProps, {context: store1Context})(Component)

Let me know if you have any suggestions or questions. Thanks

Difference between 'useEffect' and calling function directly inside a component.

Vikas Kumar — Sun, 09 May 2021 12:32:00 +0000

In React, the useEffect hook is pretty straightforward. But its simplicity sometimes makes me forget its actual function. I remembered useEffect simply as something which takes a callback and a dependency array as arguments, and it will execute the callback whenever the dependency array is changed. And in case of no dependency array, it will run the callback each time the component renders.

But then what will be the difference between the following two cases.

To find out, I have created a small React application with a couple of props and states of type number and four buttons to increment those numbers.

App.js

import { useState } from 'react';
import TestComponent from './TestComponent'

function App() {

  const [prop1, setProp1] = useState(0);
  const [prop2, setProp2] = useState(0);

  return (
    <div>
      <button onClick={()=>setProp1(prev=> prev+1)}>Prop 1</button>
      <button onClick={()=>setProp2(prev=> prev+1)}>Prop 2</button>
      <TestComponent prop1={prop1} prop2={prop2}/>
    </div>
  );
}

export default App;

TestComponent.js

import { useEffect, useState } from 'react';

function TestComponent({prop1, prop2}) {
    const [state1, setState1] = useState(0);
    const [state2, setState2] = useState(0);

    useEffect(()=>{
        console.log('rendered - useEffect', state1, state2, prop1, prop2);
    });

    const someImportantWork = ()=>{
        console.log('rendered - functionCall', state1, state2, prop1, prop2);
    }
    someImportantWork();

    return (
      <div>
        <button onClick={()=>setState1(prev=> prev+1)}>State 1</button>
        <button onClick={()=>setState2(prev=> prev+1)}>State 2</button>
        <p>Prop 1: {prop1}</p>
        <p>Prop 2: {prop2}</p>
        <p>State 1: {state1}</p>
        <p>State 2: {state2}</p>
      </div>
    );
  }

  export default TestComponent;

We can see in following that both console.log statement runs whenever we update state or prop.

But I think we are missing something because both seems to be same. So let’s slow down the rendering.

To slow down the rendering I added a very long loopin inside return.

import { useEffect, useState } from 'react';

const x = new Array(10999999);

function TestComponent({prop1, prop2}) {

    return (
      <div>
        <button onClick={()=>setState1(prev=> prev+1)}>State 1</button>
        <button onClick={()=>setState2(prev=> prev+1)}>State 2</button>
        {x.map(i=> null)}
        <p>Prop 1: {prop1}</p>

After the delay we can clearly see that expression inside useEffect is always excuted after expression in the fucntion.

It is because the definition of useEffect stated at the beginning of this post is incomplete. useEffect not only executes the callback on each render (depending upon the dependency array) but also ensures that rendering has been completed. That’s why useEffect’s console.log is delayed.

This should not be a problem if you are doing some small calculation or, as in this example, logging. But if you are using ref to access the element, you must ensure that render has happened; else, you may get the wrong reference.