DEV Community: Meursyphus

I made awesome react apps with transition aniamtion

Meursyphus — Mon, 04 Aug 2025 03:08:08 +0000

you can see it on mobile phone. It makes animation when navigating other pages

🚨 Still Manually Handling Complex Web Graphics?

Meursyphus — Sat, 21 Jun 2025 16:27:06 +0000

Are you still wrestling with manual calculations, text wrapping, drag-and-drop events, and endless revisions when handling complex web graphics? Are hundreds of lines of code driving you crazy every time there's a small change?

Meet Flitter(https://flitter.dev), your game-changing solution!

😫 Everyday Developer Struggles, Familiar?

Imagine the frequent scenario at a startup meeting:

"We need a workflow editor, something like Figma—nodes you can drag and connect."

Developers panic:

"Using D3.js, that's easily three weeks of work..."
"SVG? Canvas? How will we handle automatic text wrapping?"

Say goodbye to these headaches with Flitter!

🥳 Flitter Magic: Just a Few Lines of Code

Long text wrapping and centering seamlessly:

Here's the only code you need:

Center({
  child: Container({
    width: 200,
    child: Text("Long text automatically wraps and centers", {
      textAlign: TextAlign.center,
    })
  })
})

Declarative code—clear and intuitive
Automatic cursor handling and drag interactions

No more coordinate calculations!

🔥 Unique Advantages of Flitter

🚀 Dual Rendering System (SVG + Canvas)

SVG: SEO-friendly, selectable text
Canvas: High performance, smooth interactions

💡 Server-side Rendering + Canvas Hydration

Rapid initial load with smooth interactions right from the start.

<Widget
  renderer="canvas"
  ssr={{ size: { width: 800, height: 600 } }}
  widget={...}
/>

❌ Still Using Other Libraries?

Library	Issues
D3.js	Manual calculations (coordinates, dimensions…)
Konva.js	Difficult complex layouts
Fabric.js	Limited UI capabilities
Paper.js	Only suitable for vector graphics
Three.js	Overkill for 2D UI

🎯 Flitter Simplifies Everything!

Column({
  children: [
    Text("Title", { style: headerStyle }),
    Container({
      padding: EdgeInsets.all(20),
      decoration: new BoxDecoration({
        color: '#F3F4F6',
        borderRadius: BorderRadius.circular(8)
      }),
      child: Row({
        mainAxisAlignment: MainAxisAlignment.spaceBetween,
        children: [/* Easily implemented layouts */]
      })
    })
  ]
})

👨‍💻 Flutter Developers, You're Already Experts!

Flitter shares nearly identical syntax with Flutter—instant onboarding!

// Flutter code
Container(
  padding: EdgeInsets.all(16),
  child: Text("Hello Flutter"),
)

// Flitter code
Container({
  padding: EdgeInsets.all(16),
  child: Text("Hello Flitter")
})

🎖️ Proven in Real-world Projects

📌 EasyRD – ERD Diagram Editor

Seamlessly handle over 100 nodes.

Visit on GitHub

📌 Headless Chart – Customizable Charts

Easier than D3.js, more flexible than Chart.js.

🚩 Who Should Use Flitter?

SaaS teams regularly developing complex UIs
Teams frequently building node editors and workflows
Data visualization teams needing custom charts
Teams tired of complexity in existing graphic libraries
Teams with Flutter developers

🚀 Get Started Right Now!

npm install @meursyphus/flitter

Just one command to start!

Check out the next page for detailed usage and examples.

"Performance Has Improved!" Can You Really Prove It?

Meursyphus — Tue, 10 Dec 2024 12:25:31 +0000

Every frontend developer has experienced this situation:
"I optimized this part, and it definitely feels faster!"
"Hmm... I don't really notice much difference in my environment."

When you open Chrome DevTools and try to measure performance:

The hassle of opening the tools and clicking Record every time
Measurement environments vary with browser cache, CPU state, network conditions
Sharing performance improvement results with colleagues through screenshots
Difficulty tracking whether performance degrades over time

As a result, we end up saying performance has improved based on "feeling."
However, true performance optimization should be provable with objective metrics.

In this article, we'll explore automated performance measurement methods to:

Collect objective performance data in a consistent environment
Track performance changes over time
Establish performance metrics that the entire team can share

💡 Pro Tip: While Chrome DevTools' Performance panel is a powerful tool, it has limitations with manual measurement. Through automation, we can overcome these limitations while still utilizing DevTools' analysis capabilities.

Scientific Experimentation: Reliable Performance Measurement Methods

Did you know you can control Chrome DevTools' Performance panel programmatically?
Using Playwright, you can automate performance measurements through browser automation.

Getting Started with Automated Performance Measurement Using Playwright

test('Capture performance traces', async ({ page, browser }) => {
    // Start Chrome trace recording
    await browser.startTracing(page, {
        path: `./traces/${formatDate(new Date())}.json`
    });

    // Load page and perform actions
    await page.goto('http://localhost:4173/performance-test');
    await page.click('button#start');

    // Record performance measurement points
    await page.evaluate(() => {
        window.performance.mark('Perf:Started');
        window.performance.mark('Perf:Ended');
        window.performance.measure('overall', 'Perf:Started', 'Perf:Ended');
    });

    // End measurement and save results
    await browser.stopTracing();
});

However, measuring just once isn't enough.

💡 A Habit from Physics Lab Days
"Remember, everyone! One measurement is no measurement!"

This is a habit ingrained from writing physics lab reports. 😄
I still vividly remember that measurement error is inversely proportional
to the square root of the number of repeated measurements.

Scientific Approach to Performance Measurement

Applying principles learned from physics experiments to web performance measurement:

Importance of Repeated Measurements
- Standard error decreases by 1/√n as the number of measurements (n) increases
- With 50 repetitions, error rate reduces to about 1/7 compared to a single measurement
Strict Control of Variables
- Just like controlling temperature and humidity in a lab
- Essential to control browser cache, memory state, CPU load
- Must consider V8 engine's JIT compiler optimizations

Complete Code for Reliable Measurements

test('Scientifically measure performance', async () => {
    const results = [];
    const REPEAT_COUNT = 50;  // Sufficient repetitions for reliability

    for(let i = 0; i < REPEAT_COUNT; i++) {
        // Control variables: fresh browser environment each time
        const browser = await chromium.launch({
            args: ['--no-sandbox', '--disable-dev-shm-usage']
        });
        const page = await browser.newPage();

        await browser.startTracing(page, {
            path: `./traces/trace_${i}.json`
        });

        // Performance measurement
        const result = await measurePerformance(page);
        results.push(result);

        await browser.stopTracing();
        await browser.close();  // Reset browser state
    }

    // Statistical analysis of results
    const stats = calculateStats(results);
    console.log(`
        Average: ${stats.mean}ms
        Standard Deviation: ${stats.stdDev}ms
        95% Confidence Interval: ${stats.confidenceInterval}ms
    `);
});

The Pitfall of JIT Compiler: Code Gets Faster with Execution

Here's an interesting case I encountered:

// ❌ Incorrect measurement method: repeated measurements without browser restart
test('Without browser restart', async ({ page }) => {
    const results = [];
    for(let i = 0; i < 50; i++) {
        const startTime = performance.now();
        await runPerformanceTest(page);
        results.push(performance.now() - startTime);
    }
    console.log('Execution time changes:', results);
});

The results showed:

First 10 runs average: 450ms
Middle 10 runs average: 380ms
Last 10 runs average: 320ms

Why does this happen?
It's because the V8 engine's JIT compiler learns execution patterns and optimizes the code. In other words, the same code gets faster with repeated execution.

// ✅ Correct measurement method: restart browser each time
test('With browser restart', async () => {
    const results = [];
    for(let i = 0; i < 50; i++) {
        const browser = await chromium.launch();
        const page = await browser.newPage();

        const startTime = performance.now();
        await runPerformanceTest(page);
        results.push(performance.now() - startTime);

        await browser.close();
    }
    console.log('Execution time changes:', results);
});

The results showed:

First 10 runs average: 445ms
Middle 10 runs average: 442ms
Last 10 runs average: 448ms

💡 Pro Tip:
JIT compiler optimizations do occur in production environments.
However, the goal of performance measurement is to obtain a baseline value,
so we should measure in an environment without these optimizations.

A physics major turned frontend developer applying experimental methodology...
Who would have thought? 😄 Now, let's dive deeper into analyzing Chrome Trace Reports.

Analyzing Chrome Trace Reports

The Challenge: Flitter's Performance Optimization

I was developing the Flitter visualization framework and felt the need for performance optimization. Flitter uses SVG and Canvas to visualize dynamic data, providing various animations and interactions. While these features enrich data representation, they also cause performance overhead.

For example, when data changes, requestFrameAnimation is repeatedly called to redraw SVG elements. Although we optimized the callback function to trigger only once, we didn't realize that calling requestFrameAnimation itself has a cost. This wasn't noticeable in normal cases but caused performance degradation when rendering complex UI repeatedly (e.g., mouse dragging).

To solve this issue, we initially tried to track the execution time of specific functions and optimize animation routines. However, we couldn't confidently prove the effectiveness of performance improvements based on subjective feelings.

"We need a systematic way to record JavaScript execution time and scientifically verify optimization results!"

This conclusion led us to adopt automated performance measurement using Chrome Trace and Playwright.

Collecting Performance Data with Chrome Trace Reports

Chrome Trace Reports record all major events that occur while the browser executes JavaScript code, allowing us to see how much CPU and memory each event consumes. This is particularly useful for analyzing JavaScript function calls and execution times.

Why Use Chrome Trace Reports?

The biggest advantage of Chrome Trace Reports is being able to see the entire function call stack and execution time of each function at a glance. This allows quick identification of specific functions or repetitive code that burden performance. Especially in visualization frameworks like Flitter that interact with multiple elements, finding specific routines that cause performance load is crucial, and Chrome Trace is very helpful in solving these issues.

Automating Chrome Trace with Playwright

Playwright is a useful tool for automating performance measurements in browser environments and can collect performance data in conjunction with Chrome Trace Reports. With Playwright, you can easily save Trace Reports that track events occurring in the browser. The example code below shows how to record performance data from a specific point and save it as a JSON file.

test('Capture performance traces and save JSON file when diagram is rendered', async ({ page, browser }) => {
    // Start Chrome trace recording
    await browser.startTracing(page, {
        path: `./performance-history/${formatDate(new Date())}.json`
    });

    // Navigate to the page to measure performance
    await page.goto('http://localhost:4173/performance/diagram');

    // Mark the start of performance measurement
    await page.evaluate(() => window.performance.mark('Perf:Started'));
    await page.click('button');
    await page.waitForSelector('svg');
    await page.evaluate(() => window.performance.mark('Perf:Ended'));
    await page.evaluate(() => window.performance.measure('overall', 'Perf:Started', 'Perf:Ended'));

    // End measurement and save results
    await browser.stopTracing();
});

Analyzing CpuProfile Events

Although we can generate a JSON-formatted Trace Report using Playwright and Chrome Trace, analyzing this file directly is challenging. The report contains all events that occurred during execution, but it's difficult to intuitively understand each function's execution time or call count. We need to preprocess the data to extract meaningful information.

CpuProfile Events and Preprocessing

CpuProfile events are recorded in the disabled-by-default-v8.cpu_profiler category and track JavaScript function CPU usage. Each event is recorded with a time interval and includes samples and timeDeltas fields, which can be used to infer each function's execution time.

To calculate each function's total execution time, we need to preprocess the data by:

Iterating through samples and timeDeltas to calculate each node's total execution time
Constructing a node hierarchy based on parent-child relationships and aggregating child node execution times to their parents
Extracting function-level execution times and visualizing or identifying optimization points

This preprocessing step provides a clear understanding of each function's resource usage and helps identify performance bottlenecks.

Implementing the ChromeTraceAnalyzer Class

To automate the analysis of Trace Reports, we'll implement the ChromeTraceAnalyzer class. This class will take Trace data as input, calculate each function's execution time, and provide performance metrics.

ChromeTraceAnalyzer Class

class ChromeTraceAnalyzer {
    nodes: any[];

    constructor(trace) {
        this.setConfig(trace);
    }

    // Return the execution time of a specific function (in ms)
    getDurationMs(name: string): number {
        if (!this.nodes) throw new Error('nodes is not initialized');
        const result = this.nodes.find((node) => node.callFrame.functionName === name);
        return result ? result.duration / 1000 : 0; // Convert to milliseconds
    }

    // Set up Trace data and calculate function execution times
    setConfig(trace: any) {
        const { traceEvents } = trace;

        // Filter 'ProfileChunk' events
        const profileChunks = traceEvents.filter((entry) => entry.name === 'ProfileChunk');

        // Extract CpuProfile nodes and sample data
        const nodes = profileChunks.map((entry) => entry.args.data.cpuProfile.nodes).flat();
        const sampleTimes = {};

        // Aggregate sample execution times
        profileChunks.forEach((chunk) => {
            const { cpuProfile: { samples }, timeDeltas } = chunk.args.data;

            samples.forEach((id, index) => {
                const delta = timeDeltas[index];
                sampleTimes[id] = (sampleTimes[id] || 0) + delta;
            });
        });

        // Construct node hierarchy and aggregate child node execution times
        this.nodes = nodes.map((node) => ({
            id: node.id,
            parent: node.parent,
            callFrame: node.callFrame,
            children: [],
            duration: sampleTimes[node.id] || 0
        }));

        // Establish parent-child relationships and aggregate execution times
        const nodesMap = new Map();
        this.nodes.forEach((node) => {
            nodesMap.set(node.id, node);
        });

        this.nodes
            .sort((a, b) => b.id - a.id)
            .forEach((node) => {
                if (!node.parent) return;
                const parentNode = nodesMap.get(node.parent);
                if (parentNode) {
                    parentNode.children.push(node);
                    parentNode.duration += node.duration;
                }
            });
    }
}

Repeated Measurements for Reliability

Although we can analyze Trace data using ChromeTraceAnalyzer, a single measurement is not enough to evaluate performance. JavaScript execution performance can vary due to environmental changes, so we need to repeat measurements multiple times to obtain reliable data.

Repeated Measurement Code Example

test('Capture analyzed trace when diagram is rendered with multiple runs', async () => {
    const COUNT = 10;
    const duration = {
        timestamp: Date.now(),
        runApp: 0,
        mount: 0,
        draw: 0,
        layout: 0,
        paint: 0,
    };

    for (let i = 0; i < COUNT; i++) {
        const browser = await chromium.launch({ headless: true });
        const page = await browser.newPage();
        await page.goto('http://localhost:4173/performance/diagram');

        // Start tracing
        await browser.startTracing(page, {});
        await page.evaluate(() => window.performance.mark('Perf:Started'));
        await page.click('button');
        await page.waitForSelector('svg');
        await page.evaluate(() => window.performance.mark('Perf:Ended'));
        await page.evaluate(() => window.performance.measure('overall', 'Perf:Started', 'Perf:Ended'));

        // Extract Trace data and analyze
        const trace = JSON.parse((await browser.stopTracing()).toString('utf8'));
        const analyzer = new ChromeTraceAnalyzer(trace);
        duration.runApp += analyzer.getDurationMs('runApp') / COUNT;
        duration.mount += analyzer.getDurationMs('mount') / COUNT;
        duration.draw += analyzer.getDurationMs('draw') / COUNT;
        duration.layout += analyzer.getDurationMs('layout') / COUNT;
        duration.paint += analyzer.getDurationMs('paint') / COUNT;

        await browser.close();
    }

    console.log('**** Average Execution Time ****');
    console.log(`runApp: ${duration.runApp}ms`);
    console.log(`mount: ${duration.mount}ms`);
    console.log(`draw: ${duration.draw}ms`);
    console.log(`layout: ${duration.layout}ms`);
    console.log(`paint: ${duration.paint}ms`);
    console.log('********************************');
});

Visualizing Performance Data

By repeating measurements and analyzing Trace data, we can obtain reliable performance metrics. To better understand performance changes over time, we can visualize the data using Flitter.

Flitter-Based Stacked Bar Chart

We created a stacked bar chart using Flitter to display the average execution time of each function over multiple runs. This chart helps us identify performance bottlenecks and track changes in execution time.

Chart Configuration

X-axis: Measurement dates (track performance changes over time)
Y-axis: Average execution time (ms)
Stacked bars: Each function's execution time (color-coded)

Performance Changes Over Time

By analyzing the chart, we can see how performance changes over time:

Date-based performance changes: We can track how performance changes on each measurement date.
Function-level execution time: We can identify which functions consume the most resources and optimize them accordingly.

The current Flitter library can be used as an efficient visualization solution in situations where performance optimization is important. You can check the related code on GitHub, and if you found this helpful, please give it a Star and thumbs up on GitHub! If you show interest in this project, we plan to continue developing and sharing performance improvements and various features.

GitHub: https://github.com/meursyphus/flitter/blob/latest/packages/test/tests/tracking-performance.test.ts

Docs: Flitter Docs

Thank you for reading!

Portfolio of a 4-Year Frontend Developer

Meursyphus — Tue, 10 Dec 2024 12:19:07 +0000

Hello! In this post, I'd like to introduce the frontend projects I've been working on. Instead of just showing my work, I'll focus on the thought process behind the interactions and UX choices, and how I solved the challenges I faced.

Ultimately, I'll be sharing the choices I made to improve the user experience and the insights I've gained from real-world practice. If you've been curious about my work, I think you'll find this interesting. So, shall we get started?

Project 1: Improving Search UX – Smooth Page Transitions and Slide Interactions

If page transitions in a search interface aren't smooth, users can easily get confused. Especially when browsing through multiple pages of search results, abrupt page changes can make it difficult to understand where they are or what they’ll see next. To address this, I implemented slide interactions for the search results pages.

When moving to the next page, the content slides to the left, and when returning to the previous page, it slides to the right. Maintaining a consistent transition speed was key. For instance, moving directly from page 1 to page 3 required a longer slide duration since the distance covered was greater. This helped create smooth, natural transitions between pages.

Another crucial aspect of UX is maintaining context. Rather than simply refreshing the page, showing the transition visually allows users to better understand where they are and what they'll see next. I also ensured a smooth flow between pages by connecting the last row of the previous page with the first row of the next page.

Technically, managing the DOM was a significant challenge. Preloading all the content during page transitions would overload both the browser and server, so I handled this by removing unnecessary DOM elements as the animation ended. Additionally, I added a fade-out effect for the disappearing page's content to make the transition feel even more seamless. This effect was a designer's request, and though it was challenging to implement, the visual satisfaction was worth it.

As a result, page transitions became smooth and natural, allowing users to explore search results without losing context.

Project 2: Improving Search UX – Analyzing and Applying Naver's Search Interface

Next, I want to talk about search UX. The search bar is one of the key interfaces that provide a search experience, and its usability greatly depends on how quickly and intuitively it delivers search results. So, I analyzed Naver's search UX and applied it to my own search component.

Naver's search bar shows search results in real time as users type and highlights matching terms with color. This structure helps users quickly find what they're looking for by providing rapid visual feedback while typing. This makes the search results clearer and more intuitive.

I also paid attention to the triggers for showing and hiding the search results panel. Naver's search bar opens the results panel when the user starts typing or presses the arrow key, and closes it when they clear the input or click outside. These subtle interactions make the user experience smoother. UX that responds to multiple triggers like this helps users stay immersed in the search task.

Applied Interactions and UX Improvements

Based on this analysis, I incorporated similar UX elements into my search component. I designed it to display search results in real time while typing, highlighting the parts that match the search term to provide feedback to the user. Additionally, users could navigate the results using keyboard arrow keys, which improves usability by enabling navigation without the mouse.

I also handled the triggers for automatically opening and closing the search results panel more meticulously. When the user starts typing, the results panel opens automatically, and when the input is cleared, the panel closes. While the search bar is open, users can also use various keyboard actions (e.g., arrow keys, enter key) to select results, allowing them to check the results more quickly and intuitively.

Project 3: Scroll Animation – Code Typing Effect on Page Scroll

Next, I’d like to discuss scroll animation. Scroll animations are a key element in enhancing the user experience by adding visual effects to a webpage, making the experience more engaging. In particular, I wanted to provide a more lively experience for users of the Flitter.dev project through scroll animations.

Adding scroll animations helps draw users' attention and increases the time they spend on the page. From the user's perspective, it can feel like the page comes alive as they scroll. The scroll animation I applied to Flitter.dev makes it look like code is being typed in real time, giving the impression that the code is actually being written on the screen.

Implementation Method

To implement this animation, I used Lottie animations. The process was as follows:

Write the complete code and then undo it line by line: After completing the entire code, I used the undo function to erase lines one by one, making it look like typing.
Screen recording: I saved this process as a screen recording and converted it to MP4 format.
Lottie conversion: I then converted the MP4 video to a Lottie file, allowing the typing animation to progress as the user scrolls.

Thanks to this approach, I was able to implement a smooth, natural animation without affecting the page loading speed.

UX Impact

The biggest advantage of this scroll animation is that it provides intuitive feedback to users. The real-time typing animation keeps users engaged with the content and draws their attention as they scroll through the page.

Visit https://flitter.dev to check out the animation for yourself! 🌟

Conclusion

I've introduced a few of the projects I've worked on so far. Though they're not perfect, I believe I’m growing step by step through these experiences. I'm constantly realizing how important user experience (UX) is, and I'll keep striving to create better interactions and UI in the future.

Thank you for reading, and I hope these projects might serve as a small reference for your own work. 😄

Can't Ask GPT Properly? Congratulations! You're Growing as a Developer

Meursyphus — Tue, 10 Dec 2024 12:16:13 +0000

"I asked GPT but the answer was weird..."

This is a common message in developer chat rooms. Usually followed by a lengthy error log dump, without context or any explanation of what they tried to do.

"Sorry, but how do I fix this?"

"This isn't working, and GPT doesn't understand what I'm saying 😢"

Even senior developers from prestigious companies like Toss, Musinsa, and Naver can't understand these questions. But this isn't their fault. The questions are simply too vague.

GPT Doesn't Understand You? Congratulations!

Sound strange? But I mean it. If GPT can't understand your questions, it's evidence that you're experiencing growing pains.

Think about it. How can AI understand questions that even senior developers can't comprehend? While GPT is certainly a powerful tool, it's not a magic wand. Without clear context and accurate information, even the world's smartest AI can't provide a proper answer.

Difficulty with GPT Usage is a Sign of Growth

Junior developer A had this concern:
"Infinite scroll isn't working in React. I asked GPT but the answer was weird."

Six months later, A asks like this:
"I'm implementing infinite scroll with React Query, using Intersection Observer. I want to store the scroll position in sessionStorage to restore it on back navigation, but I'm seeing unnecessary re-renders. Should I apply memoization?"

See the difference?

Paradoxically, finding it difficult to use GPT is a signal that you're growing. As you understand technology more deeply, your questions become more specific and clear. And that's when GPT truly becomes your pair programmer.

Prerequisites for Clear Questions

Here's what you need to properly utilize GPT:

Accurate understanding of the problem situation
- What you're trying to achieve
- Current state
- What errors are occurring
Basic knowledge of your technology stack
- Role of each library or framework
- Core concepts and how they work
- Common problem-solving patterns
Solutions you've attempted
- What approaches you've tried
- Results from each attempt

With these preparations, GPT can provide much more useful answers.

How Growing Developers Use GPT

Stop asking GPT questions. Instead, give it commands.

Not "What should I do about this error?"

But "Here's what I tried. Looking at the logs, the problem seems to be here. Suggest how I should modify this part."

Not "How do I build this feature?"

But "Here are the requirements, and this is my tech stack. Analyze the best implementation approach considering performance and maintainability."

This approach leads to remarkable changes:

Deeper understanding of problems
Better control over solutions
Improved technical specification writing skills
Enhanced communication with colleagues

This is Just the Beginning

Still finding it difficult to ask GPT questions? Don't worry. That's evidence you're growing.

As questions become more challenging, you learn more, and as you learn more, questions become clearer. And through this process, you'll find yourself growing from a junior to a mid-level developer.

Start today. Stop asking GPT questions, and start giving it commands. Your real growth begins now.

Think 'use client' Means CSR? Master This Next.js Interview Question

Meursyphus — Tue, 10 Dec 2024 12:15:45 +0000

If you're a junior developer who has worked with Next.js, you've probably encountered this question in technical interviews:

"Is use client exclusively for Client-Side Rendering (CSR)?"

If you can confidently answer "No, components with use client can also utilize SSR (Server-Side Rendering)!", you'll leave a strong impression on your interviewer.

In this article, we'll focus on SSR and Server Components to clearly understand what use client really means and what the Hydration process entails. We'll also explore how all React components were client components before Server Components came along, and examine the performance benefits of Server Components to help you prepare thoroughly for Next.js interviews.

Understanding SSR, CSR, and Hydration

Traditionally, React applications often operated with CSR (Client-Side Rendering). The browser receives basic HTML and JS bundles from the server, but the initial screen only contains an empty <div id="root"></div>, leaving users staring at a blank screen until JS loads and rendering completes. This delays initial loading times and negatively impacts SEO.

One solution to this problem is SSR (Server-Side Rendering). With SSR, React components are rendered to HTML on the server before being sent to the client, allowing users to see actual content instead of a blank screen during initial load. However, this HTML is still in a "dry (Markup-only)" state without interactivity, and only becomes fully interactive after the browser loads JavaScript and React completes its hydration process by registering event handlers.

What is Hydration?

Hydration is the process where static HTML rendered on the server is matched with React's virtual DOM on the client side, and event handlers are attached to create an interactive UI. In other words, after receiving "structure-only" HTML through SSR, once JavaScript loads and hydrate() executes, event and state management logic becomes active on top of this HTML structure.

[Server: SSR] --(HTML)--> [Browser: Initial Display] 
                                      | 
                                      v 
                          (JS Load, hydrate()) 
                                      |
                                      v
                    [Browser: Event Handlers Attached, VDOM Sync]

Now users can see content immediately upon page load, with interactivity becoming available as soon as JS is ready.

Distinguishing Server Components from Client Components

Server Components, introduced after React 18, presented a new paradigm of "components that only run on the server." In Next.js, all components are Server Components by default, and only components that need to run on the client explicitly declare use client.

Server Components are delivered to the client as HTML snippets and are excluded from hydration. This means the HTML returned by Server Components is simply inserted into the browser "as is," without event handlers or state being injected on the client side. As a result, Server Components consume minimal JavaScript bundle size, significantly helping with performance optimization.

On the other hand, components declaring use client behave like traditional React components. They generate initial HTML through SSR, then go through the hydration process to activate interactivity. Therefore, use client components can utilize SSR and support the hydration process that combines SSR + CSR.

Before Server Components: All Components Were Client Components

Before Server Components existed, all React components had to go through hydration on the client side. Even with SSR, all components ultimately needed to have their logic re-injected with JavaScript on the client. This led to large bundle sizes and longer initial loading times in large applications.

After the introduction of Server Components, we can now handle "static parts that only need to be displayed" as Server Components without any declaration, while parts requiring interactivity can be marked with use client. This clear separation enables more efficient bundle optimization and better performance.

How Server Components Work: Slot Insertion and HTML Combination

Server Components render HTML snippets on the server and provide them to the client, while React's render tree leaves a "hole" for these snippets. The final HTML is created by inserting these snippets into the corresponding holes. Here's a simple ASCII diagram illustrating this process:

[Server: RSC(Render)] --> [HTML snippet] 
                                | 
                                v 
                [React Render Tree]: "hole" creation
                                | 
                                v 
                    Combined HTML --> Client transmission 
                    (Server Components excluded from hydration)

In this process, Server Components do not include JavaScript bundles. As a result, they cannot register event handlers or state, but this is actually beneficial for parts that only require static HTML. The reduced JavaScript bundle size leads to faster initial screen display.

Acing Your Interview: Confidently Answering "Is 'use client' Only for CSR?"

For example, you might encounter this question in an interview:

Interviewer: "Do components with use client only support CSR?"

Model Answer:

"No, in Next.js, all components are Server Components by default, and only components that need to run on the client explicitly declare use client. These client components generate initial HTML through SSR and then go through the hydration process to activate interactivity on the client side. Therefore, use client components can also utilize SSR. On the other hand, Server Components are excluded from hydration and only provide static HTML, reducing JavaScript bundle size and improving performance."

If you can clearly explain this, the interviewer will recognize that you have a solid grasp of Server Components, SSR, and hydration concepts.

Server-Side Rendering and Server Components Are Not Mutually Exclusive

Finally, it's essential to note that Server Components do not replace SSR. SSR focuses on displaying content to users immediately during initial load, while Server Components provide an additional layer for optimizing bundle size and data fetching. These two technologies complement each other, and using them together enables you to create a better user experience and improve performance.

Bonus: What Is 'use server'?

'use server' is a different concept from Server Components, used to define Server Actions. Server Actions allow clients to directly call server functions, making them useful for handling server-side tasks like form submissions or data updates.

Recap

All Next.js components are Server Components by default
Client components require explicit use client declaration
Client components can utilize SSR: server-side HTML rendering followed by hydration
Server Components provide static HTML without hydration, reducing JavaScript bundle size and improving performance
'use server' is a separate feature for defining Server Actions
Server Components complement SSR, not replace it: together, they provide optimal user experience and performance

Armed with this knowledge, confidently answer interview questions. Emphasize that "use client components also support SSR" and explain how Server Components lead to bundle optimization and performance improvements. Highlighting that all components are Server Components by default and only client components need the 'use client' directive will demonstrate your deep understanding of Next.js architecture.

If you're a front-end developer, you should at least know how to handle page transitions, right? Can't do it? 😱

Meursyphus — Wed, 09 Oct 2024 07:53:51 +0000

When we use smartphone apps, smooth screen transitions are an expected part of the experience. But on the web, it’s a different story. If developers don’t pay attention to page transitions, websites can feel jarring, with sudden screen changes every time you click, leaving users confused or, worse, making them leave the site.

An experience where the screen suddenly switches, like “teleportation,” places a significant cognitive load on users. Ultimately, good UX should minimize this burden and create a natural flow. So, why are so many websites still overlooking this crucial aspect?

Now, mastering this will give you a competitive edge! By learning page transition techniques, you’ll not only enhance your web development skills but also gain an edge in app development. Thanks to technologies like WebView, web front-end developers can easily start developing apps. If you can handle page transitions on the web, you can pretty much call yourself an app developer, right? 😎

Is your website still outdated?

As a web developer, I’ve always been dissatisfied with how page transitions are handled on websites. Especially when transitioning between pages, the abrupt change of screen often makes users lose track of where they are or what they just clicked. I’ve always thought that such sudden shifts severely degrade the user experience. While smooth transitions are standard in apps, the web often still feels like “teleportation” when changing pages.

To solve this, I initially tried simple CSS tricks to add smoother transitions. However, I quickly realized their limitations. While the transitions themselves became smoother, the issue of completely new screens appearing with every page load remained. I thought that to reduce users’ cognitive fatigue on the web, we needed transitions that not only flowed smoothly but also preserved the overall context.

So, I present to you, SSGOI!!

As I became more frustrated with page transitions, I naturally began thinking about solutions. Abrupt transitions are too common on the web. When the screen changes suddenly, users often find it hard to orient themselves, leading to a loss of focus. This experience made me realize the need for smoother, more intuitive transitions on the web as well.

That’s when I decided to create SSGOI, a library designed to provide seamless, app-like page transitions for the web. SSGOI offers various animation effects and ensures users can clearly understand where they’re navigating.

The biggest advantages of this library are:

Various transition effects: With several built-in animation options, developers can easily implement smooth page transitions.
Customizable transitions: Dynamic transitions based on runtime conditions allow for a tailored user experience.
Browser compatibility: Designed to work consistently across different browsers, SSGOI leverages the latest browser APIs while still supporting smooth transitions in browsers with limitations.

Want to know the secret to smooth transitions like Pinterest?

Implementing Pinterest-like transitions with SSGOI wasn’t just about visual delight; it was about offering a more intuitive user experience. In image-centric layouts like Pinterest, it’s crucial that when a user clicks on an image, the context is maintained while the screen transitions smoothly.

My goal was to have the clicked image smoothly enlarge to the center of the screen, while the rest of the elements naturally fade away. This ensures that users stay focused on their selected content, and the page transitions without the common “disconnect” often felt on the web. It was also vital to ensure that during the image’s resizing, context is maintained, so users clearly understand where they’re navigating.

However, implementing this transition was no easy task. I had to carefully calculate how the image’s size and position would change across various screen sizes during the transition. Especially when the URL actually changes between pages, there was a lot of mathematical work involved in maintaining a smooth transition.

In the end, I was able to overcome the complex calculations and deliver a seamless experience, as if using an app right on the web.

My vision for the future.

There are clear limitations in today’s web UX, especially with browser API restrictions and cross-browser compatibility. While smooth, intuitive page transitions are expected in apps, on the web, we still experience sudden screen changes and loss of context. This is because web browsers don’t yet provide all the necessary APIs to handle transitions smoothly. This makes it difficult for developers to easily implement a variety of page transition effects, and cross-browser compatibility adds to the challenge.

This is where libraries like SSGOI come in. SSGOI bridges the gap, helping to provide an app-like, smooth user experience even on the web. By maintaining context and handling transitions smoothly, it reduces the cognitive load on users during page navigation. This allows developers to offer a better user experience without writing complex code.

The future of web UX will only improve. With new browser APIs and standards emerging, implementing page transitions will become much easier. Furthermore, as technologies like AI become more integrated into the development process, complex tasks will be handled by AI, allowing developers to focus more on the creative aspects.

Want to implement smooth transitions on the web? Check out SSGOI!

Creating smooth, app-like transitions on the web is now a crucial task. Since user experience has a significant impact on the success of a website, it’s important not to overlook even small details like page transitions.

The SSGOI library was designed to address these issues. With this library, you can implement smooth and natural page transitions without writing complex code. Built with cross-browser compatibility in mind, it ensures a consistent user experience across various environments.

If you’re interested, visit the SSGOI GitHub repository! 😄 If you find it useful, don’t forget to leave a Star! ⭐ Your feedback and participation will help improve web UX for everyone.

12 Best ER Diagram Tools to Use in 2024

Meursyphus — Wed, 17 Jul 2024 15:05:37 +0000

ER (Entity-Relationship) diagrams are essential tools for database design. In this article, we'll introduce the best ER diagram tools available in 2024.

1. Lucidchart

Lucidchart allows you to create various types of diagrams, including ER diagrams. It can be integrated with MS Office and G Suite.

Key features:

Real-time collaboration
Automated diagramming
Enhanced security

Price: Starting from $7.95/month for a single user account

2. DeZign for Databases

DeZign for Databases is a tool that helps visualize database structures. It can create new databases as well as reverse engineer existing ones.

Key features:

Drag and drop interface
Various display modes
Industry-standard design notation

Price: €19/month for Standard Edition, €59/month for Professional Version

3. Gleek.io

Gleek.io is a fast diagramming and flowchart application that works through keyboard commands and code.

Key features:

Keyboard-based user interface
Fast diagramming
Version control

Price: Basic app is free, Premium version is €9.95/month

4. EasyRd

EasyRd is a recently emerged innovative ER diagram tool. It operates based on code and utilizes DBML (Database Markup Language), a well-known open-source syntax.

Key features:

Easy generation through GPT with DBML syntax support
Code-based diagram creation
Completely free to use

The biggest advantage of EasyRd is that it can easily generate ER diagrams through AI tools like GPT using DBML syntax. It provides a code-based interface familiar to developers while enabling intuitive visualization. Additionally, it's completely free to use, removing any cost burden.

This tool will be particularly attractive to developers interested in rapid prototyping or AI-based database design.

5. DbDesigner

DbDesigner is suitable for teams that need to create different user classes for projects.

Key features:

Advanced export options
Project and team management
Export and import to SQL

Price: $6/month for basic package, $15/month for unlimited package

6. SmartDraw

SmartDraw is a web-based tool for diagramming and schema creation.

Key features:

Intelligent formatting
Professional results
Visio import and export

Price: Starting from $9.95/month for a single user account

7. Visual Paradigm

Visual Paradigm comes with several ERD templates and can create various types of diagrams.

Key features:

UML diagrams
ER diagrams
BPMN diagrams

Price: Starting from $6/month, perpetual licenses start at $99 for a single user

8. dbdiagram.io

dbdiagram.io allows power users to easily create ER diagrams.

Key features:

SQL statement generation
Export to image and PDF
One-click sharing

Price: Basic plan is free, Pro version is $9/month

9. dBForge Studio for SQL Server

dBForge Studio for SQL Server is an SQL management tool that can also create ER diagrams.

Key features:

SQL coding support
Index manager
Schema comparison

Price: Starting from $249.95

10. Navicat Data Modeler

Navicat Data Modeler creates diagrams for MySQL, Oracle, MariaDB, PostgreSQL, and SQLite.

Key features:

Database objects
Reverse engineering
SQL code generation

Price: Enterprise version $22.99/month or $229.99/year (per user)

11. Creately

Creately claims to be "your visual workspace" and enables remote collaboration.

Key features:

Smart shapes
Easy drawing shortcuts
Real-time collaboration

Price: Team version $6/month (per user)

12. Gliffy

Gliffy is a diagramming tool that can be easily used by non-developers as well.

Key features:

Process flowcharts
Workflow diagrams
Data flow charts

Price: Pro version $7.99/month (per user)

Conclusion

In 2024, there are various ER diagram tools available, allowing you to choose the one that best fits your project requirements. New tools like EasyRd are making the database design process even more efficient through integration with AI. Given that it's provided for free, why not consider EasyRd for your next project?

Flitter vs D3.js: Revolutionizing Data Visualization for the Web

Meursyphus — Sun, 14 Jul 2024 07:33:46 +0000

In the world of web-based data visualization, D3.js has long been the go-to library for developers. However, Flitter is changing the game, offering a fresh approach that addresses many of the challenges developers face with D3. Let's explore why Flitter is becoming the preferred choice for modern data visualization projects.

1. Ease of Use: Simplifying the Complex

D3.js Approach:

const svg = d3.select("body").append("svg")
    .attr("width", 400)
    .attr("height", 300);

svg.selectAll("circle")
    .data([32, 57, 112])
    .enter().append("circle")
    .attr("cy", 60)
    .attr("cx", (d, i) => i * 100 + 50)
    .attr("r", d => Math.sqrt(d));

Flitter Approach:

import { Container, CustomPaint } from "@meursyphus/flitter";

const BubbleChart = ({ data }) => {
  return Container({
    width: 400,
    height: 300,
    child: CustomPaint({
      painter: {
        paint({canvas}, size) {
          data.forEach((d, i) => {
            canvas.beginPath();
            canvas.arc(i * 100 + 50, 60, Math.sqrt(d), 0, 2 * Math.PI);
            canvas.fill();
          });
        },
      },
    }),
  });
};

Flitter Advantage: Flitter's declarative approach and widget-based architecture make it significantly easier to create and understand visualizations, especially for developers already familiar with modern UI frameworks.

2. Performance: Handling Large Datasets with Ease

While D3.js can struggle with large datasets due to its direct DOM manipulation, Flitter's efficient rendering pipeline shines with big data.

Flitter's Optimized Rendering:

import { ... } from '@meursyphus/flitter';
import Widget from '@meursyphus/flitter-react';

const App = () => {
  return(
    <Widget
      width="100vw"
      height="100vh"
      child={
        ...// your widget here
      }

      /**
       * you can choose between "canvas" and "svg". 
       * canvas is faster, while svg is useful for server side rendering
       */
      renderer="canvas"
    />
  )
}

Flitter Advantage: Flitter's rendering approach allows for smooth handling of thousands of data points, maintaining high frame rates even with dynamic updates.

3. Integration with UI: Seamless Component Integration

D3.js often requires additional work to integrate with modern UI frameworks. Flitter, on the other hand, is designed for seamless integration.

Flitter's Unified Approach:

import { Column, Text } from "@meursyphus/flitter";
import { BarChart } from "@meursyphus/flitter-chart";
import Widget from '@meursyphus/flitter-react';

export function Dashboard() {
  return (
    <Widget
      width="100vw"
      height="100vh"
      child={
        Column({
          children: [
            Text("Sales Dashboard"),
            BarChart({ /* chart properties */ }),
            // Other UI components
          ],
        })
      }
    />
  )
}

Flitter Advantage: Create entire applications with a consistent architecture, mixing visualizations and UI components effortlessly.

4. Responsive Design: Adapt to Any Screen

While D3.js requires manual work for responsiveness, Flitter makes it straightforward:

import { Container } from "@meursyphus/flitter";
import Widget from '@meursyphus/flitter-react';

const YourWidget = () => {
  return ... // your widget implementation here
};

const App = () => {
  return (
    <Widget
      width="100%"
      height="100%"
      child={Center({
        child: YourWidget() // your widget will be centered whenever the screen size changes
      })}
    />
  )
}

Flitter Advantage: Built-in responsiveness features make it easy to create visualizations that look great on any device.

5. Learning Curve: Familiarity for Modern Developers

D3.js has a steep learning curve, especially for developers used to modern framework paradigms. Flitter leverages familiar concepts:

class InteractiveChart extends StatefulWidget {
  createState() {
    return new InteractiveChartState();
  }
}

class InteractiveChartState extends State<InteractiveChart> {
  private selectedData = null;

  onDataPointSelected(data) {
    this.setState(() => {
      this.selectedData = data;
    });
  }

  build() {
    return Column({
      children: [
        Chart({
          data: this.props.data,
          onDataPointClick: this.onDataPointSelected,
        }),
        Text(`Selected: ${this.selectedData}`),
      ],
    });
  }
}

Flitter Advantage: Developers familiar with modern UI frameworks can quickly become productive with Flitter, leveraging concepts they already know.




**Flitter Advantage:** Create smooth, performant animations with a simpler, more intuitive API.

## Conclusion: Why Choose Flitter Over D3.js?

1. **Easier Learning Curve:** Familiar concepts for modern developers.
2. **Better Performance:** Efficient handling of large datasets.
3. **Seamless UI Integration:** Build entire applications with a consistent architecture.
4. **Built-in Responsiveness:** Easily create adaptive visualizations.
5. **Simplified Animations:** Create complex animations with less code.

While D3.js remains a powerful tool, Flitter represents the future of web-based data visualization. It combines the flexibility and power needed for complex visualizations with the ease of use and integration capabilities that modern developers expect.

Ready to take your data visualization projects to the next level? Choose Flitter and experience the future of web development today.

Visit here: [Flitter](https://flitter.dev) to get started.

The Complete Guide to CSS object-fit Property

Meursyphus — Sun, 14 Jul 2024 00:05:53 +0000

The Complete Guide to CSS object-fit: Key to Handling Images on the Web

Introduction: Why You Need to Know object-fit

Dealing with images in web development has always been a challenging task. How can we consistently display images of various sizes and ratios? This is where the CSS object-fit property plays a crucial role.

Understanding object-fit means more than just displaying images correctly. Recently, many cloud services that automatically adjust the size of user-uploaded images have been offering object-fit as an option. Therefore, if you don't understand the exact behavior of object-fit, you might unintentionally provide a negative user experience during the image optimization process.

Basic Concepts of object-fit

The object-fit property determines how an image will be cropped or scaled to fit within the specified size (container size) of an <img> or <video> tag, in relation to the original image size.

An important point to note is that when only width or height is specified, the other dimension is automatically determined based on the original image ratio. In this case, for all object-fit values except scale-down and none, the image will fill the container size while maintaining its aspect ratio. However, with scale-down and none, if the container size is larger than the image size, the image will maintain its original size without stretching.

object-fit Values and Their Effects

1. contain

      Container
+--------------------+
|        Image       |
|:------------------:|
|:                  :|
|:                  :|
|:                  :|
|:                  :|
|:------------------:|
|                    |
+--------------------+

Adjusts the image to be fully visible
Maintains image aspect ratio
May result in empty space within the container

2. cover

         Image
:######################:
:#                    #:
:#     Container      #:
:#  +------------+    #:
:#  |            |    #:
:#  |            |    #:
:#  |            |    #:
:#  +------------+    #:
:#                    #:
:######################:

Completely fills the container
Maintains image aspect ratio
May crop parts of the image

3. fill

Completely fills the container
Ignores image aspect ratio (may distort the image)

4. none

Maintains original image size
Ignores container size (image may be clipped)

5. scale-down

Displays the image at the smaller size between none and contain
Prevents the image from stretching

Image Widget in Flitter

The Flitter library also provides an Image widget that implements the behavior of object-fit. Flitter's Image widget is designed to behave as similarly as possible to the native HTML <img> tag and supports various object-fit options.

Image({
  src: 'https://flitter.dev/examples/object-fit/profile.jpg',
  width: 750,
  height: 250,
  objectFit: 'none'
})

If you want to see various examples of object-fit, visit the following URL: https://flitter.dev/examples/object-fit

Conclusion

The object-fit property is a powerful tool for handling images on the web. By properly understanding and using it, developers can effectively manage images of various sizes and ratios, providing users with a consistent visual experience. Understanding object-fit becomes even more important when using image optimization services. We hope this guide helps you handle images more effectively in your web projects.

You must know about principle of z-index

Meursyphus — Wed, 10 Jul 2024 16:46:23 +0000

Introduction

Hi, I'm (flitter)[https://flitter.dev] maintainer and recently I provide z-index widget.

This article explores the workings of the z-index property and how to implement it within SVGs.

Intended Audience

Those struggling with z-index not applying as expected.
Anyone unfamiliar with the concept of stacking context.
Individuals looking to implement z-index directly in SVG.
People interested in adding z-index behavior to charts or diagrams.

Keywords

What is Z-Index?

The z-index is a CSS property that adjusts the vertical stacking order of elements. Its default value is auto, equivalent to z-index: 0. However, z-index: 0 creates a new stacking context, altering the precedence for child elements differently from z-index: auto. A stacking context will be explained further below.

Typical Z Order

In the absence of a specified z-index, the vertical order of stack elements matches the order in which DOM nodes are rendered. This ordering is consistent with a Depth-First Search (DFS), where elements rendered later take precedence over those rendered earlier. For example, a pink box drawn over an orange box is higher in the stack..

Adding Z Elements

Assigning a z-index of 9999 to a purple circle places it at the top, as shown in the illustration. Despite the pink box being the last reach in a depth-first search, the z-index rearrangement prioritizes the purple circle to be drawn last.

What is a Stacking Context?

Stacking context, along with an element's z-index, determines its vertical stack priority. Simply put, think of a stacking context as an array of a parent's z-index values. Even if a child element has a high z-index, it can still be placed lower in priority due to its stacking context.

As shown in the illustration above, despite the purple circle having a z-index of 9999, it is obscured by the pink box below because it belongs to a new stacking context created by its parent's z-index of 0.

Situations Creating Stacking Context

Stacking context can form not only when a parent element's z-index is specified but also under the following conditions:
- Root element of the document (<html>).
- Element with a position value absolute or relative and z-index value other than auto.
- Element with a position value fixed or sticky (sticky for all mobile browsers, but not older desktop browsers).
- Element with a container-type value size or inline-size set, intended for container queries.
- Element that is a child of a flex container, with z-index value other than auto.
- Element that is a child of a grid container, with z-index value other than auto.
- Element with an opacity value less than 1 (See the specification for opacity).
- Element with a mix-blend-mode value other than normal.
- Element with any of the following properties with value other than none:
- Element with an isolation value isolate.
- Element with a will-change value specifying any property that would create a stacking context on non-initial value (see this post).
- Element with a contain value of layout, or paint, or a composite value that includes either of them (i.e. contain: strict, contain: content).
- Element placed into the top layer and its corresponding ::backdrop. Examples include fullscreen and popover elements.

Stacking Context Operational Rules

Let's delve into how stacking contexts are formed and influence the order in which nodes are drawn, explained step by step. For those interested in directly jumping to the implementation logic of z-index, please proceed to the next section titled "Z-Index Implementation Logic."

The illustration above represents a schematic of the DOM structure. The numbers on each node denote the order they are visited in a preorder traversal. Nodes 2 and 4 possess distinct stacking contexts. Node 3 inherits the stacking context from node 2.

Comparing nodes 2 and 4, even though node 4 has the same z-index, its higher node number grants it priority in the stacking order. Since node 3 inherits the stacking context from node 2, no matter how high its z-index, it will be ranked lower in the stacking order compared to node 4.

Example: Complicated Stacking Context

In the illustration, nodes 3 and 4 are situated below node 2, and node 7 is located beneath node 6. Notably, there exists a stacking context with a z-index of -1, as seen with node 6, and there are nodes, like node 5, that do not belong to any stacking context. Nodes without a separate stacking context are considered to have a z-index of 0.

The nodes can be divided according to the drawing order as shown above. Node 1 takes precedence over nodes 6 and 7 in the vertical layer, and node 5 is superior to nodes 2, 3, and 4 in the vertical layer. Since nodes 3 and 4 are both below node 2, node 3 with the higher z-index takes precedence over node 4 in the vertical layer.
Therefore, the drawing order is as follows:ㅋ

Z-Index Implementation Logic

Implementing z-index equates to creating a logic for arranging DOM drawing order, considering the stacking contexts. A stacking context can be identified through a pre-order traversal of the DOM tree. First, let's define a Stacking Context.

type StackingContext = {
  zIndex: number //stacking context를 형성한 dom의 z-index
  domOrder: number //stacking context를 형성한 dom의 전위순회 순서
}

type CollectedDom = {
   contexts: StackingContext[] //dom이 물려받은 stacking context
   domOrder: number //dom의 전위순회 순서
   dom: HTMLELEMENT 
}

A StackingContext is formed by a DOM element that has a z-index. It collects the zIndex and domOrder of the formed DOM into the stacking context. A child inherits the StackingContext from its parent. If the child has a new z-index, it adds a new context to the Stacking context inherited from the parent. Then, the CollectedDom information corresponding to node 7 would be as follows:

const 7Node = {
  contexts: [{zIndex: -1, domOrder: 6}] //6번 노드로부터 물려받음
  domOrder: 7
  dom: div태그
}

If you have collected const collectedDoms: CollectedDom[] while traversing the DOM, you can sort them in the correct order by considering the stacking context. There are three points to note:

If they are in the same stacking context, the order is determined by the DOM order.
If there is no stacking context, the z-index is considered to be 0.
In a stacking context, the parent element is drawn first regardless of the z-index of the child elements. (In vertical layer priority, it gives way to its children).

정렬로직

function sort(a: CollectedDom, b: CollectedDom) {
   const limit = Math.min(a.contexts.length, b.contexts.length)

   /*
     stacking context를 순회하며 비교합니다.
   */
     for(let i = 0; i < limit; ++i) {
     const aContext = a.contexts[i]
         const bContext = b.contexts[i]

     /*
      * stacking context가 서로 다른 경우의 노드는 context의 
            * zIndex를 먼저 비교하고, 그 다음의 dom 순서를 비교합니다.
     */
     if(aContext.zIndex !== bContext.zIndex) {
             return aContext.zIndex - bContext.zIndex
     } else if(aContext.domOrder - bContext.domOrder) {
       return aContext.domOrder - bContext.domOrder
     }
   }



     /* 
    * 이 아래부터는 a,b는 동일한 stacking context 있음을 의미한다.
    * a와 b의 관계는 아래 둘 중 하나이다. 
    *   1. 부모 - 자식
    *   2. 형제
   */

   // 1. 부모-자식인 경우
   if(limit > 0) {
     const lastContext = a.contexts[limit-1] // 값이 같기 때문에 a,b 둘 중 어느것이여도 상관없다.
     //둘 중 하나가 부모임
     if(lastContext.domOrder === a.domOrder || lastContext.domOrder === b.domOrder {
       return a.domOrder - b.domOrder
     }
   }

   // 2. 형제인 경우 
   if(a.contexts.length !== b.contexts.length) {
     const aContext = a.contexts[limit] || { zIndex:0, domOrder: a.domOrder }
     const bContext = b.contexts[limit] || { zIndex:0, domOrder: b.domOrder }

     /*
      * stacking context가 서로 다른 경우의 노드는 context의 
            * zIndex를 먼저 비교하고, 그 다음의 dom 순서를 비교합니다.
     */
     if(aContext.zIndex !== bContext.zIndex) {
             return aContext.zIndex - bContext.zIndex
     } else if(aContext.domOrder - bContext.domOrder) {
       return aContext.domOrder - bContext.domOrder
     }

   }

   // 그 외는 돔 순서로 결정한다.
   return a.domOrder - b.domOrder
}

The above code expresses the logic for sorting by z-index. First, it checks if the stacking contexts are different. If they are different, it prioritizes comparing the zIndex, followed by comparing the DOM order. The length of the stacking contexts can be different. It compares them sequentially based on the shortest context. If the compared stacking contexts are all the same, it proceeds to the next step.

If the compared stacking contexts have the same value, it checks if the two DOMs have a parent-child relationship. If they are in the same stacking context, regardless of the child's z-index value, the child takes precedence over the parent in the vertical layer.

In the diagram, despite the red circle having a lower z-index value of -1 than its parent, it's clear that it has a higher priority in the vertical layering. If the parent's z-index: 0 were to be removed, then the red circle would be positioned under the blue box.

The stacking context for the blue box is [{zIndex: 0, domOrder: 2}], and for the red circle, it is [{zIndex: 0, domOrder: 2}, {zIndex: -1, domOrder: 3}]. Let's consider adding a purple circle as a child of the blue box.

The stacking context for the purple circle, similar to the blue box, is [{zIndex: 0, domOrder: 2}]. However, because its own domOrder is 3, it does not create a stacking context. As can be seen in the diagram above, the purple circle has a higher priority in the vertical layering than the red circle. Since an unspecified z-index is considered as 0, the red circle with a z-index of -1 is consequently lower in priority.

Implementing in SVG

SVG does not support the z-index property. Instead, elements positioned later in the DOM are given higher priority in the vertical stack. To apply z-index in SVG, one must manually manipulate the order of DOM elements. This is similar in canvas.

Using the flutterjs library, which creates an SVG tree analogous to the DOM tree, I leveraged the Visitor pattern and Stacking Contexts to implement z-index.

Conclusion

This article has provided insights into the z-index property and its practical application within SVG. Writing this piece also allowed me to correct misunderstandings about the stacking context's operational rules and improve drag behavior in an ERD diagram I'm developing.

References

The Hidden Power of the Box Model: What Every Frontend Dev Must Know

Meursyphus — Tue, 09 Jul 2024 14:51:34 +0000

As the developer of flitter.dev, a rendering engine framework, I often find myself explaining the intricacies of how browsers and rendering engines work. This article aims to provide a comprehensive overview of the box model, its implementation in browsers, and how similar concepts are used in other frameworks.

The Box Model and Browser Rendering

Browser rendering engines use the Box Model as the foundation for constructing web page layouts. When we write HTML tags, the browser parses them to create a Render Tree. Examining the class inheritance relationships of the instances that make up this tree, we find that the superclass is named RenderBox. Most HTML elements are parsed into instances of classes that inherit from RenderBox.

Key characteristics of the Box Model include:

Area Distinction: Elements are separated into box units.
Spacing Control: Margins and padding allow for adjustment of space between content.
Layout Alignment: Elements are aligned either horizontally or vertically.
Tree Structure: Boxes can contain other boxes, resulting in an overall tree structure.

The Box Model is particularly useful for displaying content. Books, magazines, newspapers, and websites primarily arrange content horizontally or vertically, and parent-child paragraph structures are easily represented. However, games and 2D/3D graphic images are challenging to resolve with the Box Model. These elements are difficult to divide into box shapes, requiring separate definitions for interaction units.

Browsers leverage the Box Model to help position elements as desired using only HTML and CSS. Consider the scenario of creating a desktop application without a browser engine. You would need to construct the Render Tree yourself, calculate coordinates for element layouts based on the hierarchical structure, determine which element was triggered by an event at (x, y) coordinates, and implement a hitTest() method for each Render Tree element to decide whether to activate event handlers.

For mobile apps that don't use browsers, frameworks perform these tasks. For instance, Google's cross-platform framework Flutter generates RenderObject instances (which inherit from RenderBox) for each widget. When the root object calls for layout, it calculates the positions of its children and passes coordinate information to the graphics engine for painting on the screen.

Data Visualization and the Box Model

Data visualization content like charts and diagrams often contains many elements that can be represented by the Box Model. Bar graphs, in particular, can be fully expressed using just the Box Model. However, certain graphic elements (e.g., curved or bent lines) are challenging to represent in HTML. Consequently, chart and diagram libraries typically use SVG or Canvas instead of HTML. This means that these libraries must perform the role of the browser, which is why creating charts and diagrams can be complex.

Conclusion

Understanding the Box Model and how rendering engines work is crucial for web developers and those working on rendering frameworks. While the Box Model is powerful and widely applicable, it's important to recognize its limitations and know when alternative approaches are necessary. As we continue to develop flitter.dev and other rendering solutions, these foundational concepts remain at the core of our work.