Header image

Crawl Website Đơn Giản Với Postman

20/12/2022

2.3k

Mở đầu

Trong kiểm thử API, chúng ta không xa lạ gì với Postman, một tool kiểm thử API rất phổ biến và được sử dụng trong nhiều trường hợp khác nhau. Nếu như bạn chưa rõ API là gì, có thể tham khảo lại bài viết giới thiệu về API cơ bản của mình tại ĐÂY.

Trong bài viết này, mình sẽ hướng dẫn các bạn cách crawl đơn giản một website bằng Postman nhằm kiểm tra xem các link hay hình ảnh có trong website đó có bị die hay lỗi gì không? 

Crawl Website là việc lấy thông tin từ website , trích xuất ra những thông tin người sử dụng cần, đồng thời cũng tìm những link có trong trang web đó và tự động truy cập vào những link đó. Quá trình đó sẽ lặp đi lặp lại đến khi thu thập đủ thông tin người dùng cần. 

Ví dụ dự án của bạn có một website như Landing Page hoặc trang chủ chẳng hạn, và trong trang lại có các hình ảnh, các hyperlink dẫn tới các trang con hoặc các website khác. Sau một thời gian bạn cần kiểm tra lại xem những hyperlink đó có còn hoạt động hay không. Thay vì phải click thủ công từng link một thì Postman có thể giúp bạn đơn giản hoá và tiết kiệm thời gian hơn cho việc này rất nhiều. Trước khi đi sâu vào bài viết, bạn cần có một số kiến thức về các khái niệm dưới đây:

  • Script trong Postman
  • Runner trong Postman
  • Có một ít kiến thức cơ bản về Javascript

Khâu chuẩn bị

Để bắt đầu, máy tính của bạn cần cài đặt Postman, tất nhiên rồi. Sau đó chúng ta sẽ tạo một Collection chứa hai Request với tên bất kỳ và hai biến collection. Trong ví dụ dưới đây, mình sẽ tạo Collection tên Crawl Website cùng 2 request:

  • Input check: Request này dùng để kiểm tra đầu vào trước khi crawl.
  • URL check: Request chính dùng để crawl website.
  • 2 biến collection gồm có: 
    • rootUrl: URL gốc của trang cần check
    • startUrl: URL bắt đầu khi chạy test, ở đây mình sẽ để rootUrl và startUrl chung 1 URL

Input check

Input check

Giờ chúng ta cùng thiết lập cho request đầu tiên. Ở request này, mình sẽ code tại phần Pre-request nhằm kiểm tra các đầu vào trong quá trình crawl website. Dưới đây là danh sách các function mình cần tạo trong request này

  • Kiểm tra danh sách biến có trong collection
  • Kiểm tra giá trị URL gán vào biến có định dạng hợp lệ
  • Tạo biến Global để sử dụng cho request tiếp theo

Như mình đã nói ở phần mở đầu, các bạn cần có kiến thức cơ bản về javascript để có thể hiểu hơn và tuỳ biến lại code phù hợp với nhu cầu của dự án. Mình sẽ có gắng giải thích đơn giản để những bạn ít biết về code vẫn có thể sử dụng được.

Ở request này, URL của request chúng ta sẽ để biến {{startUrl}} với phương thức là GET.

Input check

Kiểm tra danh sách biến có trong collection

Trước khi kiểm tra được danh sách các biến có trong collection, ta sẽ chuyển các biến đó thành object và gán vào biến postmanVariables

<strong>const</strong> postmanVariables = pm.collectionVariables.toObject();

Sau đó ta kiểm tra các biến cần sử dụng đã có trong collection hay chưa

pm.expect(postmanVariables).to.have.all.keys("startUrl", "rootUrl");

Kiểm tra giá trị URL gán vào biến có định dạng hợp lệ

Để kiểm tra giá trị URL gán vào biến có định dạng hợp lệ, ta sẽ sử dụng Regex. Đầu tiên ta sẽ gán định dạng URL viết dưới dạng regex vào biến urlRegex và so sánh các giá trị URL trong 2 biến collection là startURL và rootURL có giống với urlRegex hay không.

const urlRegex = /^https?:\/\//;
pm.expect(postmanVariables.startUrl, 'startUrl does not match URL pattern').to.match(urlRegex);
pm.expect(postmanVariables.rootUrl, 'rootUrl does not match URL pattern').to.match(urlRegex);

Tạo biến Global để sử dụng cho request tiếp theo

Kết thúc script mình sẽ tạo biến 3 biến là link, url, index cho request tiếp theo. Ở đây mình sử dụng biến Global để cho dễ truy cập và lấy giá trị giữa các request, tuỳ thuộc vào tính chất dự án, bạn có thể sửa lại thành biến cho 1 environment cũng không có vấn đề gì nhé. 

  • links: Mảng các link ta lấy được khi crawl một trang
pm.globals.set("links", "[]");
  • url: URL đang test
pm.globals.set("url", postmanVariables.startUrl);
  • index: Số thứ tự của URL cần test trong mảng links ta crawl được
pm.globals.set("index", -1);

URL check

URL check

Sau khi thiết lập xong request Pre-check, ta chuyển sang request URL check, đây sẽ là request chạy chính của mình. 

Ở request này, URL của request chúng ta sẽ để biến {{url}} với phương thức là GET.

URL check

Dưới đây là danh sách các function sẽ sử dụng trong request này:

  • Kiểm tra link lỗi
  • Lấy các hyperlink có trong website
  • Lọc các link không liên và lặp crawl
  • Kết thúc vòng lặp

Trước khi bắt đầu thì ta sẽ gán giá trị URL của 2 biến collection và 3 biến Global thành các biến Local cho dễ sử dụng

const startUrl = pm.collectionVariables.get("startUrl");
const rootUrl = pm.collectionVariables.get("rootUrl");
const links = JSON.parse(pm.globals.get("links"));
const currentUrl = pm.globals.get("url");
const currentIndex = parseInt(pm.globals.get("index"));

Kiểm tra link lỗi

Giờ ta sẽ tạo 1 hàm để kiểm tra xem link mình lấy về có bị lỗi hay không. Hiện tại thì link chúng ta test ban đầu chính là URL bạn gán vào biến startUrl.

pm.test(`Link to "${currentUrl}" works`, function () {
    try {
        pm.response.to.not.be.error;
    }
    catch (error) {
        console.log(`FAILED :: ${currentUrl}`);
        console.log(`FAILED :: status code is ${pm.response.code}`);
        
        throw error;
    }
});

Trong đó hàm try để kiểm tra xem link đó có trả về response lỗi hay không và hàm catch dùng để log lại thông tin lỗi. Tuỳ vào nhu cầu bạn có thể log thêm những thông tin khác bạn muốn kiểm tra nhé.

Lấy các hyperlink có trong webiste

Sau khi ta đã kiểm tra link ban đầu không bị lỗi, ta sẽ chạy hàm lấy các hyperlink có trong URL đó như sau:

if (currentUrl.includes(startUrl)) {
    const $ = cheerio.load(pm.response.text());
    
    $("a").each(function () {
        const newLink = $(this).attr("href");
        
        if (!links.includes(newLink)) {
            links.push(newLink);
        }
    });

    $("img").each(function () {
        const newLink = $(this).attr("src");
        
        if (!links.includes(newLink)) {
            links.push(newLink);
        }
    });
}

Để lấy dữ liệu từ trang web, ta sẽ crawl HTML của web đó và tìm kiếm thông tin ta cần từ các tag có trong HTML lấy về. Trong bài viết này mình sẽ thư viện Cheerio để lấy HTML của website cần test và gán nó vào biến $. Sau khi có được HTML rồi, ta sẽ tạo vòng lặp each để tìm các tag <a> và tag <img>, sau đó  lấy các URL trong attribute “href” ở trong <a> và “src” ở trong <img>. Tiếp đến ta sẽ gán nó vào biến newLink. Ngoài ra tuỳ thuộc vào nhu cầu và tính chất của trang web, các bạn có thể bổ sung thêm các thẻ và attribute có chứa URL cần test như <link> chẳng hạn.

Vì ta chỉ cần check mỗi link 1 lần nên mình sẽ viết thêm 1 hàm if để kiểm tra xem URL lấy được đã được lấy trước đó hay chưa, nếu chưa thì sẽ bỏ link đó vào mảng links. Ở bước này bạn cũng có thể bổ sung thêm các điều kiện khác để check link lấy được tuỳ thuộc vào nhu cầu của bạn như không lấy link ads hay action link,…

Lọc các link không liên quan và lặp crawl

Chúng ta đã đi được hơn nữa quãng đường rồi. Sau khi lấy được các link có trong web và bỏ vào mảng links, giờ ta sẽ viết 1 function để trích xuất các link đó và chạy tiếp cũng như lọc những link không liên quan.

const [nextUrl, nextIndex] = getNextUrlAndIndex(links, currentIndex);
function getNextUrlAndIndex (links = [], index = 0) {
    const nextIndex = index + 1;
    
    if (links.length - 1 === nextIndex) {
        return [];
    }
    
    const linkUrl = links[nextIndex];
    
    if (!linkUrl) {
        // Skip null links
        console.log('Encountered a null link.');
        
        // Try to get the next link
        return getNextUrlAndIndex(links, nextIndex);
    }
    
    if (/^https?:\/\//.test(linkUrl)) {
        // Return if not a relative link
        return [linkUrl, nextIndex];
    }
    
    // If the link is relative, prepend with rootUrl
    const cleanedRoot = rootUrl.replace(/\/$/, '');
    const cleanedPath = linkUrl.replace(/^[\.\/]+/, '');
    
    return [[cleanedRoot, cleanedPath].join('/'), nextIndex];
}

Function này ta sẽ sử dụng biến links chứa mảng link đã lấy và biến index nhằm trích xuất vị trí link ta muốn chạy tiếp.

Hàm if đầu tiên sẽ check nếu như ta chạy xong hết mảng link thì sẽ trả về mảng rỗng.

Hàm if thứ 2 sẽ kiểm tra loại trừ các loại link mà bạn không muốn test, ở đây mình sẽ loại trừ null link, ngoài ra bạn có thể bổ sung thêm các loại link khác như link download chẳng hạn.

Hàm if tiếp theo sẽ dùng regex để kiểm tra xem link đó có nằm trong các trang con của mình hay không. Mình sẽ check bằng logic nếu như đầu URL đó giống với biến rootUrl thì sẽ truy cập tiếp vào trang đó và lấy tiếp các URL có trong trang con và lặp lại đến khi nào không còn tìm thấy nữa thì thôi.

Kết thúc vòng lặp

Cuối cùng chúng ta sẽ chạy 1 hàm if để kết thúc vòng lặp crawl này

if (nextUrl) {
    // Update global variables
    pm.globals.set("links", JSON.stringify(links));
    pm.globals.set("url", nextUrl);
    pm.globals.set("index", nextIndex);

    postman.setNextRequest("Check URL");
}
else {
    console.log("No more links to check!");
    
    // Clear global variables
    pm.globals.clear("links");
    pm.globals.clear("url");
    pm.globals.clear("index");
    
    // End the loop
    postman.setNextRequest(null);
}

Trong hàm if này nếu như vẫn còn get được link từ website thì sẽ tiếp tục gán vào biến Local để chạy tiếp bằng hàm postman.setNextRequest(“Check URL”);. Nếu như hết link thì mình sẽ đặt lệnh clear biến global để cho gọn phần biến tránh ảnh hưởng cho những lần chạy sau và set Next Request về null để kết thúc vòng lặp.

Kết

Vậy là chúng ta đã hoàn thành một collection crawl website đơn giản bằng Postman. Hi vọng các bạn có thể áp dụng được vào trong dự án của mình và hẹn gặp các bạn ở những bài viết tiếp theo.

Reference

Crawl Website

Regex

Postman Collection

Related Blog

How-to

Knowledge

+0

    Level Up Your Code: Transitioning to Validated Environment Variables

    Validated Environment variables play a critical role in software projects of all sizes. As projects grow, so does the number of environment variables—API keys, custom configurations, feature flags, and more. Managing these variables effectively becomes increasingly complex. If mismanaged, they can lead to severe bugs, server crashes, and even security vulnerabilities.  While there’s no one-size-fits-all solution, having some structure in how we manage environment variables can really help reduce mistakes and confusion down the road. In this article, I’ll share how I’ve been handling them in my own projects and what’s worked well for me so far. My Personal Story When I first started programming, environment variables were a constant source of headaches. I often ran into problems like: Misspelled variable names.Failure to retrieve variable values, even though I was sure they were set.Forgetting to define variables entirely, leading to runtime errors. These issues were tricky to detect. Typically, I wouldn’t notice anything was wrong until the application misbehaved or crashed. Debugging these errors was tedious—tracing back through the code to find that the root cause was a missing or misconfigured environment variable. For a long time, I struggled with managing environment variables. Eventually, I discovered a more effective approach: validating all required variables before running the application. This process has saved me countless hours of debugging and has become a core part of my workflow. Today, I want to share this approach with you. A Common Trap in Real Projects Beyond personal hiccups, I’ve also seen issues arise in real-world projects due to manual environment handling. One particular pitfall involves relying on if/else conditions to set or interpret environment variables like NODE_ENV. For example: if (process.env.NODE_ENV === "production") { // do something } else { // assume development } This type of conditional logic can seem harmless during development, but it often leads to incomplete coverage during testing. Developers typically test in development mode and may forget or assume things will "just work" in production. As a result, issues are only discovered after the application is deployed — when it's too late. In one of our team’s past projects, this exact scenario caused a production bug that slipped through all local tests. The root cause? A missing environment variable that was only required in production, and the conditional logic silently skipped it in development. This highlights the importance of failing fast and loudly—ideally before the application even starts. And that’s exactly what environment variable validation helps with. The Solution: Validating Environment Variables The secret to managing environment variables efficiently lies in validation. Instead of assuming all necessary variables are correctly set, validate them at the application’s startup. This prevents the application from running in an incomplete or misconfigured state, minimizing runtime errors and improving overall reliability. Benefits of Validating Environment Variables Error Prevention: Catch missing or misconfigured variables early.Improved Debugging: Clear error messages make it easier to trace issues.Security: Ensures sensitive variables like API keys are set correctly.Consistency: Establishes a standard for how environment variables are managed across your team. Implementation Here’s a simple and structured way to validate environment variables in a TypeScript project. Step 1: Define an Interface Define the expected environment variables using a TypeScript interface to enforce type safety. export interface Config { NODE_ENV: "development" | "production" | "test"; SLACK_SIGNING_SECRET: string; SLACK_BOT_TOKEN: string; SLACK_APP_TOKEN: string; PORT: number; } Step 2: Create a Config Loader Write a function to load and validate environment variables. This loader ensures that each variable is present and meets the expected type or format. Step 3: Export the Configuration Use the config loader to create a centralized configuration object that can be imported throughout your project. import { loadConfig } from "./loader"; export const config = loadConfig(); Conclusion Transitioning to validated environment variables is a straightforward yet powerful step toward building more reliable and secure applications. By validating variables during startup, you can catch misconfigurations early, save hours of debugging, and ensure your application is always running with the correct settings.

    09/07/2025

    7

    Bao Dang D. Q.

    How-to

    +1

    • Knowledge

    Level Up Your Code: Transitioning to Validated Environment Variables

    09/07/2025

    7

    Bao Dang D. Q.

    How-to

    Knowledge

    +0

      Build Smarter: Best Practices for Creating Optimized Dockerfile

      If you’ve been using Docker in your projects, you probably know how powerful it is for shipping consistent environments across teams and systems. It's time to learn how to optimize dockerfile. But here’s the thing: a poorly written Dockerfile can quickly become a hidden performance bottleneck. Making your images unnecessarily large, your build time painfully slow, or even causing unexpected behavior in production. I’ve seen this firsthand—from early projects where we just “made it work” with whatever Dockerfile we had, to larger systems where the cost of a bad image multiplied across services. My name is Bao. After working on several real-world projects and going through lots of trial and error. I’ve gathered a handful of practical best practices to optimize Dockerfile that I’d love to share with you. Whether you’re refining a production-grade image or just curious about what you might be missing. Let me walk you through how I approach Docker optimization. Hopefully it’ll save you time, headaches, and a few docker build rage moments 😅. Identifying Inefficiencies in Dockerfile: A Case Study Below is the Dockerfile we’ll analyze: Key Observations: 1. Base Image: The Dockerfile uses ubuntu:latest, which is a general-purpose image. While versatile, it is significantly larger compared to minimal images like ubuntu:slim or Node.js-specific images like node:20-slim, node:20-alpine. 2. Redundant Package Installation: Tools like vim, wget, and git are installed but may not be necessary for building or running the application. 3. Global npm Packages: Pages like nodemon, ESLint, and prettier are installed globally. These are typically used for development and are not required in a production image. 4. Caching Issues: COPY . . is placed before npm install, invalidating the cache whenever any application file changes, even if the dependencies remain the same. 5. Shell Customization: Setting up a custom shell prompt (PS1) is irrelevant for production environments, adding unnecessary steps. 6. Development Tool in Production: The CMD uses nodemon, which is a development tool, to run the application Optimized your Docker Image Here’s how we can optimize the Dockerfile step by step. Showing the before and after for each section with the result to clearly distinguish the improvements. 1. Change the Base Image Before: FROM ubuntu:latest RUN apt-get update && apt-get install -y curl && curl -fsSL https://deb.nodesource.com/setup_20.x | bash - && \ apt-get install -y nodejs Use ubuntu:latest, a general-purpose image that is large and includes many unnecessary tools. After: FROM node:20-alpine Switches to node:20-alpine, a lightweight image specifically tailored for Node.js applications. Result: With the first change being applied, the image size is drastically reduced by about ~200MB.  2. Simplify Installed Packages Before: RUN apt-get update && apt-get install -y \ curl \ wget \ git \ vim \ python3 \ make \ g++ && \ curl -fsSL https://deb.nodesource.com/setup_20.x | bash - && \ apt-get install -y nodejs Installs multiple tools (curl, wget, vim, git) and Node.js manually, increasing the image size and complexity. After: RUN apk add --no-cache python3 make g++ Uses apk (Alpine’s package manager) to install only essential build tools (python3, make, g++). Result: The image should be cleaner and smaller after removing the unnecessary tools, packages. (~250MB vs ~400MB with the older version) 3. Leverage Dependency Caching Before: COPY . . RUN npm install Copies all files before installing dependencies, causing cache invalidation whenever any file changes, even if dependencies remain unchanged. After: COPY package*.json ./ RUN npm install --only=production COPY . . Copies only package.json and package-lock.json first, ensuring that dependency installation is only re-run when these files change.Installs only production dependencies (--only=production) to exclude devDependencies. Result: Faster rebuilds and a smaller image by excluding unnecessary files and dependencies. 4. Remove Global npm Installations Before: RUN npm install -g nodemon eslint pm2 typescript prettier Installs global npm packages (nodemon, eslint, pm2, ect.) that are not needed in production, increasing image size. After: Remove Entirely: Global tools are omitted because they are unnecessary in production. Result: Reduced image size and eliminated unnecessary layers. 5. Use a Production-Ready CMD Before: CMD ["nodemon", "/app/bin/www"] Uses nodemon, which is meant for development, not production. Result: A streamlined and efficient startup command. 6. Remove Unnecessary Shell Customization Before: ENV PS1A="💻\[\e[33m\]\u\[\e[m\]@ubuntu-node\[\e[36m\][\[\e[m\]\[\e[36m\]\w\[\e[m\]\[\e[36m\]]\[\e[m\]: " RUN echo 'PS1=$PS1A' >> ~/.bashrc Sets and applies a custom shell prompt that has no practical use in production After: Remove Entirely: Shell customization is unnecessary and is removed. Result: Cleaner image with no redundant configurations or layers. Final Optimized Dockerfile FROM node:20-alpine WORKDIR /app RUN apk add --no-cache python3 make g++ COPY package*.json ./ RUN npm install --only=production COPY . . EXPOSE 3000 CMD ["node", "/app/bin/www"] 7. Leverage Multi-Stage Builds to Separate Build and Runtime In many Node.js projects, you might need tools like TypeScript or linters during the build phase—but they’re unnecessary in the final production image. That’s where multi-stage builds come in handy. Before: Everything—from installation to build to running—happens in a single image, meaning all build-time tools get carried into production. After: You separate the "build" and "run" stages, keeping only what’s strictly needed at runtime. Result: Smaller, cleaner production imageBuild-time dependencies are excludedFaster and safer deployments Final Optimized Dockerfile # Stage 1 - Builder FROM node:20-alpine AS builder WORKDIR /app RUN apk add --no-cache python3 make g++ COPY package*.json ./ RUN npm install --only=production COPY . . # Stage 2 - Production FROM node:20-alpine WORKDIR /app COPY --from=builder /app/node_modules ./node_modules COPY --from=builder /app ./ EXPOSE 3000 CMD ["node", "/app/bin/www"] Bonus. Don’t Forget .dockerignore Just like .gitignore, the .dockerignore file excludes unnecessary files and folders from the Docker build context (like node_modules, .git, logs, environment files, etc.). Recommended .dockerignore: node_modules .git *.log .env Dockerfile.dev tests/ Why it matters: Faster builds (Docker doesn’t copy irrelevant files)Smaller and cleaner imagesLower risk of leaking sensitive or unnecessary files Results of Optimization 1. Smaller Image Size: The switch to node:20-alpine and removal of unnecessary packages reduced the image size from 1.36GB, down to 862MB. 2. Faster Build Times: Leveraging caching for dependency installation speeds up rebuilds significantly.Build No Cache:Ubuntu (Old Dockerfile): ~126.2sNode 20 Alpine (New Dockerfile): 78.4sRebuild With Cache (After file changes):Ubuntu: 37.1s (Re-run: npm install)Node 20 Alpine: 8.7s (All Cached) 3. Production-Ready Setup: The image now includes only essential build tools and runtime dependencies, making it secure and efficient for production. By following these changes, your Dockerfile is now lighter, faster, and better suited for production environments. Let me know if you’d like further refinements! Conclusion Optimizing your Dockerfile is a crucial step in building smarter, faster, and more efficient containers. By adopting best practices: such as choosing the right base image, simplifying installed packages, leveraging caching, and using production-ready configurations, you can significantly enhance your build process and runtime performance. In this article, we explored how small, deliberate changes—like switching to node:20-alpine, removing unnecessary tools, and refining dependency management—can lead to.

      08/07/2025

      15

      Bao Dang D. Q.

      How-to

      +1

      • Knowledge

      Build Smarter: Best Practices for Creating Optimized Dockerfile

      08/07/2025

      15

      Bao Dang D. Q.

      View Transitions API

      Knowledge

      Software Development

      +0

        How to Create Smooth Navigation Transitions with View Transitions API and React Router?

        Normally, when users move between pages in a web app, they see a white flash or maybe a skeleton loader. That’s okay, but it doesn’t feel smooth. Try View Transitions API! Imagine you have a homepage showing a list of movie cards. When you click one, it takes you to a detail page with a big banner of the same movie. Right now, there’s no animation between these two screens, so the connection between them feels broken. With the View Transitions API, we can make that connection smoother. It creates animations between pages, helping users feel like they’re staying in the same app instead of jumping from one screen to another. Smooth and connected transition using View Transitions API In this blog, you’ll learn how to create these nice transitions using the View Transitions API and React Router v7. Basic Setup The easiest way to use view transitions is by adding the viewTransition prop to your React Router links: import { NavLink } from 'react-router'; <NavLink to='/movies/avengers-age-of-ultron' viewTransition> Avengers: Age of Ultron </NavLink> Only cross-fade animation without element linking It works — but it still feels a bit plain. The whole page fades, but nothing stands out or feels connected. Animating Specific Elements In the previous example, the entire page takes part in the transition. But sometimes, you want just one specific element — like an image — to animate smoothly from one page to another. Let’s say you want the movie image on the homepage to smoothly turn into the banner on the detail page. We can do that by giving both images the same view-transition-name. // app/routes/home.tsx export default function Home() { return ( <NavLink to='/movies/avengers-age-of-ultron' viewTransition> <img className='card-image' src='/assets/avengers-age-of-ultron.webp' alt='Avengers: Age of Ultron' /> <span>Avengers: Age of Ultron</span> </NavLink> ); } // app/routes/movie.tsx export default function Movie() { return ( <img className='movie-image' src='/assets/avengers-age-of-ultron.webp' alt='Avengers: Age of Ultron' /> ); } // app.css ... /* This class assign to the image of the movie card in the home page */ .card-image { view-transition-name: movie-image; } /* This class assign to the image of the movie in the movie details page */ .movie-image { view-transition-name: movie-image; } ... Now, when you click a movie card, the image will smoothly grow into the banner image on the next page. It feels much more connected and polished. Animating a single element with view-transition-name Handling Dynamic Data  This works great for a single element, but what happens if you have a list of items, like multiple movies? If you assign the same view-transition-name to all items, the browser won’t know which one to animate. Each transition name must be unique per element — but hardcoding different class names for every item is not scalable, especially when the data is dynamic. Incorrect setup – Same view-transition-name used for all items in a list. The Solution: Assign view-transition-name during navigation Instead of setting the view-transition-name upfront, a more flexible approach is to add it dynamically when navigation starts — that is, when the user clicks a link. // app/routes/home.tsx export default function Home({ loaderData: movies }: Route.ComponentProps) { return ( <ul> {movies.map((movie) => ( <li key={movie.id}> <NavLink to={`/movies/${movie.id}`} viewTransition> <img className='card-image' src={movie.image} alt={movie.title} /> <span>{movie.title}</span> </NavLink> </li> ))} </ul> ); } // app/routes/movie.tsx export default function Movie({ loaderData: movie }: Route.ComponentProps) { return ( <img className='movie-image' src={movie.image} alt={movie.title} /> ); } // app.css ... /* Assign transition names to elements during navigation */ a.transitioning .card-image { view-transition-name: movie-image; } .movie-image { view-transition-name: movie-image; } ... Final output – Smooth transition with dynamic list items Here’s what happens: When a user clicks a link, React Router adds a transitioning class to it.That class tells the browser which image should animate.On the detail page, the image already has view-transition-name: movie-image, so it matches. This way, you can reuse the same CSS for all items without worrying about assigning unique class names ahead of time. You can explore the full source code below: Live DemoSource on GitHub Browser Support The View Transitions API is still relatively new, and browser support is limited:  Chrome (from version 111)Edge (Chromium-based)Firefox & Safari: Not supported yet (as of May 2025) You should always check for support before using it in production. Conclusion The View Transitions API gives us a powerful tool to deliver smooth, native-feeling page transitions in our web apps. By combining it with React Router, you can: Enable basic transitions with minimal setupAnimate specific elements using view-transition-nameHandle dynamic content gracefully by assigning transition names at runtime Hope this guide helps you create more fluid and polished navigation experiences in your React projects!

        08/07/2025

        20

        Knowledge

        +1

        • Software Development

        How to Create Smooth Navigation Transitions with View Transitions API and React Router?

        08/07/2025

        20

        The journey of Anh Duong

        Our culture

        +0

          Anh Duong – A Journey of Rising Above to Shine Bright

          At SupremeTech, we often meet during meetings, rush through deadlines together, and celebrate when our products are released. But behind those intense work hours, there are powerful stories of personal transformation & growth that we don’t always get to hear. ST is not only a witness to these journeys but also a part of them. In May, during our ST WOW section—a time where we honor people who make others say “WOW,” not only in work but also in life—we recognized Anh Duong. Duong has been with SupremeTech for four years and has gone through an impressive personal transformation. Let’s explore his story together! From a Shy Boy to the Confident Anh Duong Today Just over two years ago, Duong often felt insecure, especially about his appearance. He was skinny and had trouble even carrying water bottles around the office. He often felt tired and weak due to poor health. These little moments slowly pushed him to make a change, not to impress others, but to take control of his life. He started going to the gym in April 2023. At first, it was just something to try out. When the numbers on the scale didn’t move, he felt discouraged. But instead of giving up, that became a turning point. He chose discipline. He chose daily habits. He set long-term goals. Day by day, these choices built into something bigger—not just in how he looked, but in how he felt. No Trainer, No Showing Off – Just Self-Understanding Duong didn’t have a personal trainer. There was no magic solution. He studied on his own to learn what worked for his body—what foods, exercises, and routines suited him best. He designed his own meals, workouts, and rest schedule. Not to meet someone else’s standards, but to fit what he truly needed. Now that he’s “in shape,” his training is no longer a challenge—it’s just part of a healthy lifestyle. Success Measured by Spirit, Not Muscles After one year, Duong said his energy had improved significantly. He rarely feels drained now. People around him notice he’s more cheerful and full of life. And after two years? He says it’s a turning point—he truly feels proud of what he has achieved with his body. Now, he’s more confident. He’s in a relationship. His family is proud. And most importantly, he inspires others who once felt the same way. “You won’t know until you try. Don’t work out to show off—do it to change yourself.”Nguyen Van Anh Duong That’s Duong's message to anyone who feels unsure, insecure, or not strong enough to start. At ST, we’re proud to have people like Anh Duong—not just skilled at work, but also strong in their personal lives. We believe going far takes not only skills but also willpower. It’s not just about working together, but also living and growing together. Thank you, Anh Duong, for your personal transformation effort and for being a warm and strong light in our ST family. Related articles: From Unpaid Trial to the Top: The Inspiring Rise to Vice PresidentFrom Seeking The Path to Leading The Way: Phuoc’s Journey at SupremeTech

          27/06/2025

          79

          Our culture

          +0

            Anh Duong – A Journey of Rising Above to Shine Bright

            27/06/2025

            79

            Customize software background

            Want to customize a software for your business?

            Meet with us! Schedule a meeting with us!