DEV Community: Jack Chen

Optimizing My Code Editor with Flutter Profiling Tools

Jack Chen — Wed, 26 Mar 2025 10:36:02 +0000

This article is the final installment in my series about building a custom code editor. In previous story I talked about how to use TwoWayScroll in a code editor.

In this part, I’ll share how I used Flutter’s profiling tools to identify and resolve performance bottlenecks that were slowing down scrolling in my app. If you’ve been following along, you’ll see how a once sluggish editor demo evolved into a smooth and functional.........demo (lol).

Introduction to Profiling

Profiling sounded intimidating at first—I had never used it seriously before. But once I dove in, I found it surprisingly straightforward and incredibly helpful. Profiling allowed me to pinpoint exactly where my app was struggling and guided me toward effective optimizations.

Enabling Profiling in Flutter

To profile a Flutter desktop app, you don’t need to do anything special—just run the app in debug mode (no need for flutter run --profile). When running in debug mode, the DEBUG CONSOLE displays a line like this:

Connecting to VM Service at ws://127.0.0.1:64769/WcZS3CufaRw=/ws

This address connects your app to Flutter’s profiling tool. In VS Code, search for >Dart: Open DevTools in Browser, paste the VM service address into the "VM service URL" text box, and voilà—you’re connected to DevTools. The Performance tab shows the time taken for each Flutter frame, helping you identify slow or janky behavior.

Enhancing Tracing for Detailed Insights

For a more granular view, enable the following options in the "Enhance Tracing" dropdown:

Track widget builds
Track layouts
Track paints

This generates a detailed performance view (see Flutter’s documentation) that breaks down how long each activity takes and how smaller activities nest within larger ones.

Identifying the Bottleneck

With profiling tools enabled, I focused on identifying which part of my app was causing the slowdown. Slow Flutter frames are marked with a different color in the frame window. Clicking on a specific frame reveals the corresponding timeline, where you can drill down into the exact activities causing delays.

Pro Tip: Press Shift to move horizontally across the timeline, and Ctrl + scroll to zoom in and out.

The Culprit: `LineWidget`

The profiling data revealed that LineWidget was the primary bottleneck. Each LineWidget took a long time during the build phase, as it rendered individual characters or environment variables as RuneWidget or VarWidget. This meant that scrolling through large files required rebuilding hundreds or thousands of widgets, which was far from efficient.

# TODO: Show how slow `LineWidget` is

Optimizing `LineWidget`

To improve performance, I needed to reduce the number of widgets used to render text. Here’s how I approached the optimization:

Handling Lines Without Environment Variables

I noticed that many large files don’t contain environment variables. For such lines, I created a new build function that packs all characters into a single RuneWidget and assigns a color. This drastically reduced the number of widgets and improved scrolling performance.

Cursor and Selection Highlighting

For cursor and selection highlighting, I replaced invisible widgets with floating colored blocks positioned behind and above the text. This approach required only two extra widgets per line and some mathematical calculations, eliminating the need for complex RichText manipulations.

Here’s the optimized build logic:

@override
Widget build(BuildContext context) {
  for (Rune r in runes) {
    if (r.isVar) {
      hasVar = true;
      break;
    }
  }
  if (hasVar) {
    return buildWithVar(context); // Original build process
  }
  return buildPureText(context);  // Optimized build process
}

Widget buildPureText(BuildContext context) {
  double chWidth = chSize.width;
  int blinkCursorIndex = -1;
  if (widget.cursorManager.lineIndex == widget.lineIdx) {
    blinkCursorIndex = widget.cursorManager.runeIndex;
  }

  List<Widget> textRowChildren = [];
  var strBuffer = StringBuffer();
  Rune? prev;
  if (runes.isNotEmpty) {
    prev = runes.first;
  }

  // Separate text into `RuneWidget` based on colors
  for (int i = 0; i < runes.length; i++) {
    Rune r = runes[i];
    if (r.color?.value != prev!.color?.value) {
      var str = strBuffer.toString();
      textRowChildren.add(
        Stack(
          alignment: Alignment.centerLeft,
          children: [
            RuneWidget(
              key: UniqueKey(),
              isSelected: false,
              ch: str,
            ),
          ],
        ),
      );
      strBuffer.clear();
    }
    strBuffer.write(r.ch);
    prev = r;
  }

  if (strBuffer.isNotEmpty) {
    var str = strBuffer.toString();
    textRowChildren.add(
      RuneWidget(
        key: UniqueKey(),
        isSelected: false,
        ch: str,
      ),
    );
    strBuffer.clear();
  }

  // Handle end of line highlight for selection
  bool isLineSelected = widget.cursorManager.isEndOfLineWithinSelection(widget.lineIdx);
  Selection? selection = widget.cursorManager.computeSelectionForLine(widget.lineIdx);
  double selectionStartOffset = 0;
  double selectionWidth = 0;
  if (selection != null) {
    double maxSelectionWidth = chWidth * (runes.length + 0.5) * strangeCoefficient;
    int end = selection.end;
    if (end == -1) {
      end = runes.length;
    }
    selectionStartOffset = chWidth * selection.start * strangeCoefficient;
    selectionWidth = chWidth * (end - selection.start) * strangeCoefficient;
    if (selectionWidth < 0) {
      selectionWidth = 0;
    }
    if (selectionWidth > maxSelectionWidth) {
      selectionWidth = maxSelectionWidth;
    }
  }
  if (isLineSelected) {
    selectionWidth += chWidth / 2;
  }

  Widget textRow = ConstrainedBox(
    constraints: BoxConstraints(
      minWidth: chSize.width,
    ),
    child: Row(
      key: _rowKey,
      mainAxisAlignment: MainAxisAlignment.start,
      mainAxisSize: MainAxisSize.max,
      crossAxisAlignment: CrossAxisAlignment.stretch,
      children: textRowChildren,
    ),
  );

  // Selection color layer and text layer
  List<Widget> stackChildren = [
    Positioned(
      left: selectionStartOffset,
      child: DecoratedBox(
        decoration: const BoxDecoration(color: Configuration.highlightColor),
        child: SizedBox(width: selectionWidth, height: chSize.height),
      )
    ),
    textRow,
  ];

  // If cursor is in this line, add it to the stack
  if (widget.cursorManager.lineIndex == widget.lineIdx) {
    double maxCursorPosition = chWidth * strangeCoefficient * runes.length - Configuration.cursorWidth / 2;
    double cursorPosition = chWidth * blinkCursorIndex * strangeCoefficient - Configuration.cursorWidth / 2;
    if (cursorPosition > maxCursorPosition) {
      cursorPosition = maxCursorPosition;
    }
    if (cursorPosition < 0) {
      cursorPosition = 0;
    }
    stackChildren.add(
      Positioned(
        left: cursorPosition,
        child: CursorSlot(
          key: UniqueKey(),
          events: widget.eventManager,
          controller: cursorControllers[0],
          defaultBlink: blinkCursorIndex > -1
        )
      )
    );
  }

  return Padding(
    padding: const EdgeInsets.only(left: -Configuration.clickOffset),
    child: RepaintBoundary(
      child: Container(
        color: null,
        child: Stack(children: stackChildren),
      ),
    ),
  );
}

In the buildPureText function, I grouped text by color and calculated the selection box length and cursor position using the character size (since the editor uses a monospace font). The widgets were then stacked using a Stack widget, which renders its children in order.

Results

This optimization significantly reduced the build time for LineWidget. While refreshing the entire line whenever the cursor position updates isn’t ideal, profiling showed that the overall performance improved dramatically.

(Before optimization, scrolling was a bit glichy, heavily depending on your desktop or laptop actually...)

sourceman-editor.github.io

(Almost as smooth as vscode on my testing machine: MacOS air m1 and Dell i5 optiplex)

sourceman-editor.github.io

(Well on my new laptop I actually cannot see any difference...I would not even optimize this if I had better equip...)

Drawbacks and Future Improvements

While the optimization worked well, it came with a few trade-offs:

Font Limitations: The approach only works with monospace fonts, so I mandated the font style in the editor.
Scaling Quirks: A mysterious scaling factor was required to align the selection box with the text. This factor might need adjustment for different font sizes.

Despite these issues, the optimization made the editor usable for browsing large files without performance problems.

Reflections

Looking back, I didn’t have a clear, logically provable path to optimize LineWidget. I experimented with various ideas, chose the easiest ones, and tested them. If they worked, I adopted them. Perhaps with more Flutter expertise, I could have found even better solutions.

If you’ve followed this series, you’ve seen how a poorly performing demo evolved into a functional code editor. The code I shared is simplified, but it reflects the progression from a non-workable prototype to a usable tool. The app isn’t perfectly planned or cleanly implemented—it’s full of historical debts and quick decisions. Yet, I’m proud of it. I had fun building it, experimenting, and gradually improving it. I use it almost daily, and it helps me with my work.

Building something doesn’t require theoretical assurance. It’s an ongoing process of recognizing and solving problems. Over time, your efforts can lead to a level of perfection.

Real-World Use Cases

In my daily work, I’ve found my app particularly useful in the following scenarios:

1. `curl` Commands

This was the original inspiration for the app. I use curl commands to test RESTful APIs, and the ability to mark variables in different profiles allows me to make new requests by simply switching profiles or updating variable values—no more manual replacements.

2. CloudWatch Queries

Debugging customer issues often involves running a routine set of log queries. While CloudWatch saves commonly used queries, they aren’t parameterized. With my app, I can define a customerId variable and update all related queries in one go—no more losing permissions or manually editing queries.

3. `kubectl` Queries

kubectl commands can be long and repetitive, especially when typing pod names or namespaces. My app saves me time by letting me define variables for these values, eliminating the need to type them repeatedly.

4. SQL Queries

Similar to CloudWatch queries, SQL queries can be parameterized to avoid typing long text or replacing values manually. While my app doesn’t handle complex SQL operations like adding or removing WHERE conditions, it’s still a handy tool for simpler tasks.

Take a look if you are interested in the final form of my code editor

Final Thoughts

This journey has been both challenging and rewarding. I started with a simple idea, faced numerous obstacles, and gradually improved the app through experimentation and optimization. While it’s not perfect, it’s a tool I use daily, and it’s made my work easier. I hope to share it with a broader audience and maybe even generate some financial return. But even if that doesn’t happen, I’ve accomplished something valuable.

Building something doesn’t require a perfect plan—it’s about solving problems one step at a time. Over time, those steps add up, and you end up with something you can be proud of.

From Characters to Lines: Refactoring My Code Editor for Better Performance and Two-Way Scrolling

Jack Chen — Mon, 17 Mar 2025 19:35:51 +0000

In this article, I’ll walk you through how my code editor evolved into a more robust and efficient tool. In the previous article, I attempted to handle user input and text rendering at the character level. While this approach worked initially, it quickly became clear that it wasn’t scalable or maintainable. To address these issues, I decided to shift the abstraction level from individual characters to lines and documents. Additionally, I leveraged a new Flutter component (which had just been released at the time) to enable two-way scrolling—a feature I’ll cover in the next section.

Disclaimer

As I reviewed my code, I realized that I had initially focused on developing minor functionalities—like opening files and handling file trees—before addressing the core problem: building a performant and user-friendly code editor. To keep this article focused, I won’t delve into those side features. Instead, I’ll concentrate on the key improvements that transformed my app.

The Need for a Better Widget

The biggest flaw in my initial design was handling user input at the character level. This approach led to performance bottlenecks and made the code difficult to maintain. To fix this, I introduced a new widget called DocumentWidget. This widget would handle all user input, detect where the user clicked, and use math to determine which line and character were being interacted with.

Here’s the new structure:

DocumentWidget: Handles user input and manages the overall document.
LineWidget: Represents a single line of text.
RuneWidget: Now a StatelessWidget, representing a single character.
VarWidget: A StatefulWidget for environment variables.
CursorSlot: A dedicated widget for handling cursor blinking.

By moving the abstraction level up to lines and documents, I could simplify the logic and improve performance.

Improvements in Widget Design

The refactored design separates concerns more clearly:

RuneWidget is now a StatelessWidget, making it lightweight and focused solely on rendering characters.
VarWidget remains a StatefulWidget to handle dynamic updates for environment variables.
CursorSlot encapsulates the logic for cursor blinking, ensuring that only one cursor blinks at a time.

Here’s how a LineWidget is structured:

A CursorSlot at the beginning.
A series of RuneWidgets or VarWidgets.
Another CursorSlot at the end.

When the user clicks on a character, the corresponding CursorSlot starts blinking, and the previously active one stops. This is achieved using a StreamController:

When a CursorSlot (let’s call it A) starts blinking, it emits a CursorClickEvent and subscribes to the same event with a callback to stop blinking.
If another CursorSlot (B) starts blinking, it emits its own CursorClickEvent, causing A to stop blinking and unsubscribe.
This ensures that only one CursorSlot is active at any time, preventing performance issues as the document grows.

The Better Implementation: Controller Pattern

To manage communication between DocumentWidget and LineWidget, I initially considered using events. However, this approach would have required defining numerous event types or creating a single event class with multiple payloads, leading to messy and hard-to-maintain code. Instead, I adopted the controller pattern.

Here’s how it works:

LineController: A class that exposes methods for tasks like triggering cursor blinking, highlighting text, and updating content.
LineWidget: Accepts a LineController as a parameter and initializes it in the initState method.

class LineController {
  bool ready = false;
  late Function triggerCursorBlink;
  late Function cancelCursorBlink;
  late Function highlightText;
  // Add more functions as needed...
}

class LineWidget extends StatefulWidget {
  final LineController controller;
  const LineWidget({
    required this.controller,
    super.key
  });

  @override
  State<LineWidget> createState() => _LineWidgetState();
}

class _LineWidgetState extends State<LineWidget> {
  @override
  void initState() {
    _initController();
    super.initState();
  }

  void _initController() {
    if (widget.controller.ready) return;

    widget.controller.triggerCursorBlink = () {
      // Logic to start cursor blinking
    };

    widget.controller.cancelCursorBlink = () {
      // Logic to stop cursor blinking
    };

    widget.controller.ready = true;
  }

  @override
  Widget build(BuildContext context) {
    _initController();
    // Build the widget tree
  }
}

Pitfalls of the Controller Pattern

While the controller pattern simplified communication, it introduced its own challenges:

Initialization Issues: The parent widget might invoke functions before the child widget initializes them.
Widget Disposal: If the child widget is disposed, calling its functions could lead to errors.
Redundant Checks: To avoid these issues, I added a ready flag and numerous mounted checks, which made the code feel repetitive.

Despite these drawbacks, the controller pattern made the code easier to trace and debug compared to an event-driven approach.

Testing the New Design

To validate the new design, I added basic text manipulation features like inserting and deleting characters. While these features worked well, I realized that LineWidget was becoming overly complex. To keep the code clean, I decided to move text manipulation logic into a separate module. This way, LineWidget could focus solely on rendering and user interaction.

Reflections on the Refactoring Process

This refactoring journey taught me an important lesson: it’s okay to make mistakes. As a junior developer (despite my “senior” title), I was used to working with well-defined abstractions and rarely encountered major design flaws. But when I started building my own app, I made plenty of mistakes—and that’s okay. Refactoring didn’t erase all my previous work; instead, it helped me evolve the app into a better version.

While the final implementation isn’t perfect, it’s a significant improvement over the initial design. And most importantly, it works!

This is a fantastic continuation of your journey! You’ve done a great job explaining the technical challenges and your thought process as you tackled two-way scrolling and performance optimization. Below, I’ve refined and polished this section to make it more engaging and easier to follow. I’ve also suggested a title for this part of your article.

Two-Way Scrolling and Its Optimization**

In this section, I’ll dive into how I implemented two-way scrolling in my code editor and the performance challenges I faced along the way. While the initial implementation worked, it wasn’t scalable—opening large files revealed significant performance bottlenecks. Here’s how I tackled these issues and what I learned in the process.

The Inspiration for Two-Way Scrolling

I was inspired by this Flutter code editor tutorial. However, one problem the tutorial didn’t address was two-way scrolling. In the tutorial, lines of code wrap instead of overflowing and being hidden. Initially, I thought using two SingleChildScrollViews (one for horizontal scrolling and one for vertical scrolling) would solve the problem. Unfortunately, this approach had a major flaw: the scrollbars were rendered at the end of their parent widget, meaning users had to scroll all the way to the bottom to see the horizontal scrollbar or all the way to the right to see the vertical scrollbar. This was far from ideal.

Enter `TwoDimensionalScrollView`

Fortunately, the Flutter team released TwoDimensionalScrollView, a widget designed specifically for two-way scrolling. This widget supports virtual rendering, meaning only the visible portion of the content is rendered on the screen. While this sounded perfect, there was a catch: no one had posted a tutorial on how to use TwoDimensionalScrollView for rendering text. The official example (DartPad link) only demonstrated rendering fixed-size blocks, which didn’t help with variable-width text lines.

A Naive First Attempt

My initial approach was to treat the entire editor space as a single block. This meant there was only one vicinity (the visible area), and it worked—sort of. While this solved the two-way scrolling problem, it wasn’t scalable. Rendering the entire document at once caused significant performance issues, especially with large files.

The Performance Problem

After months of adding features like a file explorer, keyboard controls, and a terminal (thanks to TerminalStudio’s open-source code), my app started to take shape. However, when I tested it with a 1,000-line file, the performance issues became glaringly obvious:

Slow Scrolling: Scrolling through large files was sluggish.
Delayed Line Insertions: Inserting a new line in a large file took noticeable time because the entire document had to be re-rendered.

This was unacceptable. My app wasn’t yet usable for real-world tasks, and I needed to find a better solution.

(This example shows insertion is a bit slow, but if your computer is very good, you might not be able to notice anything)

sourceman-editor.github.io

Optimizing with Virtual Rendering

The root cause of the performance issues was clear: rendering the entire document in a single TwoDimensionalScrollView vicinity was inefficient. To fix this, I needed to implement virtual rendering for individual lines. Here’s how I approached it:

Dynamic Line Height and Width:
- Unlike the fixed-size blocks in the official example, text lines have variable widths.
- I used Flutter’s RenderBox API to dynamically calculate the width of each line using getMaxIntrinsicWidth. While the documentation warns that this method is expensive, it was necessary for accurate rendering.
Rendering Only Visible Lines:
- I calculated the visible range of lines based on the scroll position and viewport dimensions.
- Only the lines within this range were rendered, significantly reducing the workload.
Refactoring the Code:
- I refactored the layoutChildSequence method to handle dynamic line heights and widths.
- This involved calculating the layout offset for each line and ensuring the scroll extents were updated correctly.

Here’s a simplified version of the key logic:

@override
void layoutChildSequence() {
  final double verticalPixels = verticalOffset.pixels;
  final double viewportHeight = viewportDimension.height + cacheExtent;

  // Calculate line height (fixed for all lines)
  ChildVicinity firstRune = const ChildVicinity(xIndex: 1, yIndex: 0);
  final RenderBox firstRuneRB = buildOrObtainChildFor(firstRune)!;
  double lineHeight = firstRuneRB.getMaxIntrinsicHeight(double.maxFinite);
  double width = firstRuneRB.getMaxIntrinsicWidth(double.maxFinite);
  firstRuneRB.layout(BoxConstraints(minHeight: lineHeight, maxHeight: lineHeight, minWidth: width, maxWidth: width));
  parentDataOf(firstRuneRB).layoutOffset = Offset(lineNumberWidth, -verticalOffset.pixels);

  // Determine visible lines
  int leadingRow = math.max((verticalPixels / lineHeight).floor(), 0);
  int tailingRow = math.min(((verticalPixels + viewportHeight) / lineHeight).ceil(), maxRowIndex);
  if (tailingRow <= leadingRow) {
    tailingRow = leadingRow + 1;
  }

  // Render visible lines
  double yLayoutOffset = (leadingRow * lineHeight) - verticalOffset.pixels;
  for (int i = leadingRow; i < tailingRow; i++) {
    final ChildVicinity vicinity = ChildVicinity(xIndex: 1, yIndex: i);
    final RenderBox child = (i == 0) ? firstRuneRB : buildOrObtainChildFor(vicinity)!; // the same renderbox cannot be 'built' more than once.
    double width = child.getMaxIntrinsicWidth(double.maxFinite) + 100;
    child.layout(BoxConstraints(minHeight: lineHeight, maxHeight: lineHeight, minWidth: width, maxWidth: width));
    parentDataOf(child).layoutOffset = Offset(-horizontalOffset.pixels, yLayoutOffset); // this is actually the result of trial and error...never wrapped my head around any offset numbers...
    yLayoutOffset += lineHeight;
  }

  // Update scroll extents, these make sure scrollbar behave correctly
  final double verticalExtent = lineHeight * (maxRowIndex + 1);
  verticalOffset.applyContentDimensions(0.0, clampDouble(verticalExtent - viewportDimension.height, 0.0, double.infinity));
  horizontalOffset.applyContentDimensions(0.0, clampDouble(maxWidth - viewportDimension.width, 0.0, double.infinity));
}

(This version is much more responsive, at least on my MacOS m2...)

sourceman-editor.github.io

The Results

After implementing these optimizations, the performance improved significantly:

Faster Line Insertions: Inserting a new line in a large file no longer caused noticeable delays.
Smoother Scrolling: Scrolling through large files became much more responsive.

However, there was still room for improvement. Scrolling quickly sometimes caused glitches, and the app still couldn’t match the smoothness of editors like VSCode.

The Final Challenge: Profiling

Despite the optimizations, the app wasn’t yet perfect. To identify the remaining bottlenecks, I knew I needed to dive into profiling. This would help me pinpoint the exact causes of the performance issues and optimize further.

Next Steps

In the next article, I’ll share how I used Flutter’s profiling tools to diagnose and fix the remaining performance issues. Stay tuned for the final chapter in this journey!

In case anyone is interested, github links are available:

before optimization
after optimization

The final product I made is SourcemanEditor, allows you to switch workspace environment profiles in a simple click, making multi-regional work easier. I personally used it for saving my debug queries, hopefully it can help you and make your daily routines a bit easier as well!

How I Created a Small Tool That Made My Work Easier

Jack Chen — Mon, 03 Mar 2025 12:55:05 +0000

As a Node.js backend API developer, my primary responsibility is building RESTful APIs for our system. These APIs serve various teams within my company and assist colleagues who handle customer-reported bugs. When I’m not developing APIs, I’m often using them to troubleshoot issues—querying or modifying data in the backend. While there are countless API testing tools available, and most are user-friendly, my specific needs led me down a unique path.

My company operates globally, with services deployed across multiple regions. However, our data isn’t centralized, meaning the same server code runs in different regions worldwide. Whenever I need to investigate an issue, I have to adjust the parameters of my query collections to match the region I’m targeting. Free API testing tools work well enough for this, but they come with limitations.

One day, disaster struck. I was prompted to upgrade my API testing tool, and the update completely corrupted my saved work. Even reinstalling the old version didn’t help — my query collections were gone forever. Frustrated and determined to avoid a repeat, I decided to create my own tool.

The Problem with Existing Tools

Making API requests isn’t inherently complicated. Modern GUI-based tools let you send requests with a simple click of a “POST” button. In the past, we relied on curl commands in the terminal, specifying parameters manually. While functional, this approach lacked flexibility. I needed a way to parameterize my curl commands to work seamlessly across different regions.

For example, to test a server in the US, I’d use:

curl -X GET https://us.company.com/test

For Europe, the command would be:

curl -X GET https://eu.company.com/test

In my previous testing tool, I parameterized the hostname. This was straightforward: I wrote a Python script to substitute placeholders in my curl commands with actual values. For instance, the script would take a command like curl -X GET {{hostname}}/test and replace {{hostname}} with the appropriate value from an environment file.

Here’s how it worked:

I stored the curl command in a file called curl.txt.
I created environment files like env.us (with hostname=https://us.company.com) and env.eu (with hostname=https://eu.company.com).
Running python generate.py curl.txt env.us would generate the correct command, which I could then copy and execute in the terminal.

This approach allowed me to save and organize as many files as I needed. At first, I was satisfied with this solution.

The Limitations of My Initial Solution

However, I quickly grew tired of typing python generate.py every time I needed a curl command. As the number of command files grew, organizing them into folders became cumbersome. I often found myself switching between running the Python script and executing the generated commands, sometimes accidentally re-running an old query because I forgot to copy the new one.

API testing tools have one undeniable advantage: clicking is simpler. At least, it is for me.

I wondered if there was a smarter way to handle this process. In Linux, the source command can change the execution environment of a script. I considered turning my command files into shell scripts and replacing {{hostname}} with $hostname. Then, I could use source us.env to switch environments and run the script directly.

While this was a viable solution, it didn’t eliminate the need to type out the correct shell script to execute. It was still cumbersome compared to the simplicity of clicking buttons in a GUI.

The Birth of My App Idea

I wanted a tool that would let me click and get results. I was willing to spend time setting things up initially, but I didn’t want to type anything afterward. Sure, I could have searched for another tool that wouldn’t delete my data, but I saw an opportunity to solve a problem I cared about. Isn’t that the essence of being a software developer?

So, I decided to build my own app.

As a developer, I wanted this tool to be versatile. I asked myself, “What if, in the future, I work in another multi-regional company where I need to create templating scripts for tasks beyond curl commands?” I didn’t want just an API testing tool; I needed something that could handle parameter substitution with a simple click and execute commands seamlessly.

The idea came naturally: everything is a file. Whether you’re working with code, scripts, or configurations, you’re always dealing with files. So, I envisioned a text editor that could switch parameter values with a single click.

Here’s how I imagined it:

The curl.txt file would still contain curl -X GET {{hostname}}/test.
The text editor would recognize {{hostname}} as a placeholder and render it as editable text.
The name and value of {{hostname}} would be displayed in a side panel alongside other environment variables.

(Since the app is already developed, here is what it looks like...)

demo.sourcemaneditor.com

I wanted the app to resemble VSCode because I’m familiar with it and often ran my generate.py script there. The right-side panel would display all environment files—essentially a list of profiles with variables that could be substituted into any file being edited.

Choosing the Right Technology

First, I needed to learn how to build a code editor. While I could have used JavaScript, I didn’t want to deal with Electron or WebView. Plus, side projects are a great way to learn new languages. So, I chose Flutter.

Flutter uses Dart, which is easy to pick up, and it offers multi-platform support. This meant my app could run on macOS and Windows with minimal changes, and it could even be adapted for the web.

Thanks to this tutorial, I learned the basics of creating a code editor. Before diving in, I assumed there were complex algorithms or data structures for reading, displaying, and storing file content. However, the tutorial revealed that characters are simply read, displayed, and written one by one. Even when syntax highlighting is involved, each character is processed individually. While there might be more efficient algorithms for handling large files, I didn’t explore them further at this stage.

First Attempt to Write a Code Editor

Writing a code editor felt intimidating at first. Of course, I didn’t expect to create something as sophisticated as VSCode right away, so I decided to borrow some ideas from the tutorial I mentioned earlier. While directly copying the tutorial might have been a more efficient engineering choice, it would have taken away the fun of building something from scratch!

The main difference in my code editor was how I wanted to handle environment variables. I envisioned treating them like special characters that could display their corresponding values based on the selected environment profile. This meant that reading a file character by character wouldn’t suffice—I needed a way to distinguish between normal characters and environment variables.

To achieve this, I implemented a simple rule: any text pattern matching $<10 random characters> would be recognized as an environment variable. When a file is opened, its content is read character by character. If the special pattern is encountered, it’s decoded as the key for the environment variable. I called each character a Rune, which could either represent a normal character or an environment variable.

Here’s the code for the Rune class and the parsing logic:

class Rune {
  bool isVar;
  String? ch;
  String? varKey;

  Rune({required this.isVar, this.ch, this.varKey});
}

List<Rune> parseline(String line) {
  List<Rune> parsed = [];
  ParseMode mode = ParseMode.text;
  List<int> varCodes = [];
  line.runes.forEach((r) {
    if (mode == ParseMode.text) {
      if (r == magicCharacter) {
        mode = ParseMode.variable;
        return;
      }
      String ch = String.fromCharCode(r);
      Rune rune = Rune(isVar: false, ch: ch);
      parsed.add(rune);
    } else if (mode == ParseMode.variable) {
      bool discardFlag = false;
      if (varCodes.length >= magicVarLength) {
        if (r != magicCharacter) {
          discardFlag = true;
        }
      } else {
        varCodes.add(r);
        return;
      }
      if (discardFlag) {
        String ch = String.fromCharCode(magicCharacter);
        Rune firstRune = Rune(isVar: false, ch: ch);
        parsed.add(firstRune);
        for (int v in varCodes) {
          ch = String.fromCharCode(v);
          Rune rune = Rune(isVar: false, ch: ch);
          parsed.add(rune);
        }
        ch = String.fromCharCode(r);
        Rune rune = Rune(isVar: false, ch: ch);
        parsed.add(rune);
      } else {
        print("found var");
        String key = String.fromCharCodes(varCodes);
        Rune rune = Rune(isVar: true, varKey: key);
        parsed.add(rune);
      }
      mode = ParseMode.text;
    }
  });
  return parsed;
}

Managing Profiles and Environment Variables

Another key feature of my code editor was the right-hand-side panel, which displays all environment profiles. Each profile contains a list of environment variables, and when a profile is selected, the currently opened file should update all its variables to reflect the corresponding values.

To manage the relationship between profiles and environment variables, I created two classes: ProfileManager and EnvVarManager. These classes handle loading, reading, writing, and saving profiles and environment variables. Each manager operates as a singleton during the app’s runtime, acting like an in-memory key-value store for all profiles and environment variables. Each profile and environment variable has a unique key, which can be retrieved from these managers.

Event-Driven Communication

In Flutter, there are several ways to handle message passing between widgets and components. Most tutorials recommend using Provider for shared context, but Provider is hierarchical, and I wasn’t sure if it would be sufficient for a code editor. Instead, I opted for a more generic (albeit slightly dirtier) approach: event-driven communication.

I created an EventManager using StreamController to broadcast messages. Here’s the implementation:

class EventManager {
  final _controllers = <int, dynamic>{};

  StreamController<T> _getStreamController<T> () {
    int typeCode = T.hashCode;
    if (_controllers.containsKey(typeCode)) {
      return _controllers[typeCode];
    }
    StreamController<T> streamController = StreamController<T>.broadcast();
    _controllers[typeCode] = streamController;
    return streamController;
  }

  emit<T> (T event) {
    _getStreamController<T>().add(event);
  }

  StreamSubscription listen<T> (Function callback) {
    var streamController = _getStreamController<T>();
    var subscription = streamController.stream.listen((T event) {
      Function.apply(callback, [event]);
    });
    return subscription;
  }
}

With this setup, I could define any events I needed. Widgets or components that required messages from elsewhere could listen to specific event types. The EventManager instance was passed down to child widgets as a parameter, enabling seamless communication across the app.

Rendering a `Rune`

With the logic for handling data in place, the next step was to figure out how to render each Rune and enable dynamic updates for environment variable values.

Observing Code Editor Behavior

I started by observing the behavior of a typical code editor. At its core, a code editor has two fundamental features:

A blinking cursor.
The ability to select text, with selected text highlighted.

Of course, code editors have many more advanced features, but I wanted to start with the basics and evolve the design over time. For example, syntax highlighting is an important feature, but I decided to address it later since it wasn’t critical to my core idea.

Building the `RuneWidget`

To get something visible quickly, I implemented these basic requirements in a StatefulWidget called RuneWidget. Each RuneWidget represents either a character or an environment variable. It needed to be stateful to handle the blinking cursor animation.

Each character is essentially a box containing a string. If the cursor is on a character, the left border of the box blinks, creating the illusion of a cursor. The RuneWidget can also be individually styled with different background and text colors. When an environment variable is present, the RuneWidget displays the variable’s value, which can be modified in the right sidebar.

Here’s the implementation of the RuneWidget:

class RuneWidget extends StatefulWidget {
  final EventManager eventManager;
  final bool isEnvVariable;
  final String text; // if isEnvVariable is true, text is the key of env variable
  const RuneWidget({
    required this.eventManager,
    required this.isEnvVariable,
    required this.text,
    super.key
  });

  @override
  State<RuneWidget> createState() => _RuneWidgetState();
}

class _RuneWidgetState extends State<RuneWidget> {
  // I was too lazy to define another class...
  static Color highlightColor = const Color.fromARGB(255, 110, 147, 226);
  static TextStyle defaultStyle = const TextStyle(fontFamily: 'FiraCode', fontSize: 18, color: Color(0xff272822));
  static Border cursorBorder = const Border(left: BorderSide(width: 0.8, color: Colors.black,));
  static Border defaultBorder = const Border(left: BorderSide(width: 0.8, color: Colors.white,));
  static Border highlightBorder = const Border(left: BorderSide(width: 0.8, style: BorderStyle.none,));
  static BoxShadow highlightBoxShadow = const BoxShadow(color: Color.fromARGB(255, 110, 147, 226), offset: Offset(1, 0));
  static BoxDecoration defaultDecoration = const BoxDecoration();
  static BoxDecoration cursorDecoration = const BoxDecoration(
    border: Border(
      left: BorderSide(width: 1, color: Colors.yellow,)
    )
  );

  static bool cursorDragging = false;

  Widget? boxText;
  List<BoxShadow> boxShadows = [];
  TextStyle? currStyle;
  Decoration? currDecoration;
  Border? currBorder;
  Color? currHighlightColor;

  @override
  void initState() {
    currStyle = defaultStyle;
    currBorder = defaultBorder;
    boxText = RichText(
      text: TextSpan(
        text: widget.text,
        style: currStyle,
      )
    );
    if (widget.isEnvVariable) {
      boxText = ... // text now becomes key of env variable, query EnvVarManager for its value
    }
    super.initState();
  }

  @override
  Widget build(BuildContext context) {
    return GestureDetector(
      child: MouseRegion(
        cursor: WidgetStateMouseCursor.textable,
        child: Container(
          decoration: BoxDecoration(
            border: currBorder,
            boxShadow: boxShadows,
            color: currHighlightColor,
          ),
          child: boxText,
        ),
      ),
      onPanDown() {

      }
    );
  }
}

Handling Dynamic Updates

The implementation is a bit messy, but the idea was to parameterize everything that contributes to the four key features. Parameters in BoxDecoration could change when the RuneWidget is selected or when the cursor is on it. The boxText could have different text styles based on the text colorizer.

To dynamically update these parameters based on user input, I used an event-driven approach. All widgets subscribe to an EventManager and listen for specific events. For example:

When a click event occurs.
When a selection event is triggered.
When an environment variable’s value changes.

When these events occur, the RuneWidget updates itself accordingly.

Moving Forward

With these setups in place, I began tackling the features one by one. The goal was to build a functional and intuitive code editor that could handle environment variables seamlessly, all while providing a smooth user experience.

Implementing the Three Key Features

With the basic structure of the RuneWidget in place, I focused on implementing the three core features: the blinking cursor, text selection, and dynamic updates for environment variable values.

1. Cursor and Its Blinking

The blinking cursor was relatively straightforward to implement. I set up a periodic job in the RuneWidget to alternate the appearance of the left border, creating the blinking effect. The _showCursor method is triggered when the GestureDetector detects a click (onPanDown callback). This method emits a CursorClickEvent to notify other RuneWidgets that they should hide their cursors. The clicked RuneWidget subscribes to CursorClickEvent and uses _hideCursor as the callback, ensuring that only one cursor is visible at a time.

Here’s the implementation:

Timer? cursorTimer;
StreamSubscription? cursorEventSubscription;

void _blinkCursor() {
  cursorTimer ??= Timer.periodic(const Duration(milliseconds: 500), (timer) {
    setState(() {
      currBorder = (currBorder == defaultBorder) ? cursorBorder : defaultBorder;
    });
  });
}

void _hideCursor(CursorClickEvent e) {
  cursorEventSubscription?.cancel();
  cursorTimer?.cancel();
  cursorTimer = null;
  if (currBorder != highlightBorder) {
    setState(() {
      currBorder = defaultBorder;
    });
  }
}

void _showCursor() {
  cursorEventSubscription?.cancel();
  widget.eventManager.emit<CursorClickEvent>(CursorClickEvent());
  cursorEventSubscription = widget.eventManager.listen<CursorClickEvent>(_hideCursor);
  if (currBorder != highlightBorder) {
    setState(() {
      currBorder = cursorBorder;
    });
    _blinkCursor();
  }
}

@override
Widget build(BuildContext context) {
  return GestureDetector(
    ...
    onPanDown: (DragDownDetails details) {
      widget.eventManager.emit<SelectionCancelEvent>(SelectionCancelEvent());
      setState(() {
        ...
      });
      _showCursor();
    },
    onPanEnd: (DragEndDetails details) {
      setState(() {
        ...
      });
    },
    ...
  );
}

2. Text Selection

Handling text selection was a bit more complex. Instead of calculating cursor positions based on mouse coordinates (as done in the tutorial), I opted for a simpler approach: each RuneWidget detects user input individually. Here’s how it works:

Any RuneWidget can determine which character is being clicked.
If the mouse click isn’t released, the user is selecting text.
As the mouse moves, any RuneWidget it passes through is highlighted as part of the selection.

While this approach avoids complex math, it has limitations. For example, if the mouse moves vertically, entire lines should be selected, but this isn’t handled well. Additionally, MouseRegion may miss enter and exit events if the mouse moves too quickly.

3. Environment Variable Value Change

This feature was the easiest to implement, thanks to the event-based design. Whenever a profile is clicked, it broadcasts an event containing the profile’s identity. Each RuneWidget representing an environment variable listens to this event during initialization and updates its displayed value accordingly.

Addressing the Drawbacks

As a careful reader, you might have noticed some issues with this implementation. If you’ve tried the example, you’ll see that text selection doesn’t work as expected. For instance:

When selecting text vertically, the mouse doesn’t necessarily pass through all the text that should be selected.
MouseRegion may fail to detect enter and exit events if the mouse moves too quickly.

To mitigate these issues, I introduced a CursorDraggingEvent that reports the mouse’s position. Each RuneWidget listens to this event and determines whether it should be highlighted based on the reported coordinates.

Here’s the implementation:

class CursorDraggingEvent {
  int posX;
  int posY;
  CursorDraggingEvent({required this.posX, required this.posY});
}

StreamSubscription? highlightSelectionSubscription;
cursorDraggingSubscription = widget.eventManager.listen<CursorDraggingEvent>(_selectionHandler);

void _selectionHandler(CursorDraggingEvent e) {
  // Check if this widget is inside the selection
  int smallerY = min(selectionStartY, e.posY);
  int largerY = max(selectionStartY, e.posY);
  int smallerX = selectionStartX;
  int largerX = e.posX;

  if (smallerY == e.posY) {
    smallerX = e.posX;
    largerX = selectionStartX;
  }
  if (smallerY == largerY) {
    smallerX = min(selectionStartX, e.posX);
    largerX = max(selectionStartX, e.posX);
  }

  // Single-line selection
  if (smallerY == largerY && widget.posY == smallerY) {
    if (smallerX <= widget.posX && widget.posX <= largerX) {
      _highlightSelection(widget.eventManager);
    }
  }
  // Multi-line selection
  else if (widget.posY > smallerY && widget.posY < largerY) {
    _highlightSelection(widget.eventManager);
  } 
  else if (widget.posY == smallerY && widget.posX >= smallerX) {
    _highlightSelection(widget.eventManager);
  }
  else if (widget.posY == largerY && widget.posX <= largerX) {
    _highlightSelection(widget.eventManager);
  }
  else if (currBorder == highlightBorder) {
    _cancelSelection(widget.eventManager);
  }
}

void _highlightSelection() {
  if (widget.isPlaceHolder) {
    return;
  }
  highlightSelectionSubscription ??= widget.eventManager.listen<SelectionCancelEvent>(_cancelSelection);
  setState(() {
    boxShadows.add(highlightBoxShadow);
    currHighlightColor = highlightColor;
    currBorder = highlightBorder;
  });
}

void _cancelSelection(event) {
  setState(() {
    boxShadows.remove(highlightBoxShadow);
    currHighlightColor = null;
    currBorder = defaultBorder;
  });
  highlightSelectionSubscription?.cancel();
  highlightSelectionSubscription = null;
}

@override
Widget build(BuildContext context) {
  return GestureDetector(
    child: MouseRegion(
      onEnter: (PointerEnterEvent e) {
        if (cursorDragging) {
          _showCursor();
          widget.eventManager.emit<CursorDraggingEvent>(
            CursorDraggingEvent(posX: widget.posX, posY: widget.posY)
          );
        }
      },
      onExit: (PointerExitEvent e) {
        if (cursorDragging) {
          _highlightSelection();
        }
      }
    ),
    onPanDown: (DragDownDetails details) {
      widget.eventManager.emit<SelectionCancelEvent>(
        SelectionCancelEvent(posX: widget.posX, posY: widget.posY)
      );
      ...
    },
    onTapUp: (TapUpDetails details) {
      ...
      widget.eventManager.emit<SelectionCancelEvent>(
        SelectionCancelEvent(posX: widget.posX, posY: widget.posY)
      );
    }
  );
}

And this is what it looks like after everything is done:

sourceman-editor.github.io

I made this demo repo public in case anyone is interested.

Lessons Learned

While this approach improved text selection, it still had significant drawbacks:

Performance Degradation: Input performance worsened as the number of text entries increased.
Cursor Placement: When the mouse isn’t clicking on any character, the cursor should appear at the end of the line or file. This required additional logic to implement.
Selection Issues: Some RuneWidgets failed to revert to an unselected state when CancelSelection was triggered.
Reverse Selection: Selecting text in reverse (moving the mouse toward already selected content) didn’t work as expected.

This implementation taught me that skipping the math for cursor and selection positions wasn’t the right approach. A better solution would involve calculating the cursor’s position based on user input and rendering it accordingly.

The good news is that the environment-changing feature worked as expected. However, I realized that RuneWidget might not be the right level to handle user input. A more optimized approach would involve fewer components handling input, which I’ll explore in the next iteration.

Conclusion

In the end, I created a demo that, while functional, wasn’t particularly impressive. Building a code editor turned out to be far more challenging than I initially imagined. The tutorial I followed was right about many things: if the code looks complicated, there’s usually a good reason for it.

In the next article, I’ll explain a better approach (though still not the best one) and dive into how the code editor works in its improved form.

Reflections

As I wrote this article, I documented what I remembered from my journey. I eventually abandoned the RuneWidget idea when I realized it might become too complicated to scale. However, I’m not entirely convinced that this is a fundamentally bad approach. It’s possible that my own limitations—my skill level and imagination—prevented me from fully realizing its potential. For me, though, it wasn’t the best path forward, as I couldn’t envision how to extend the idea further.

From a technical perspective, I should probably dive deeper into Flutter to understand why certain strange behaviors occurred. However, from an app developer’s perspective, my priority should be to get things done quickly and choose a reliable approach that delivers results. As an ordinary developer, I don’t have a strict discipline guiding my decisions. In the end, coding something new is an art. It involves making countless implementation decisions—some good, some bad—as long as they work the way you want. I can only choose one path, share my experience, and let you decide what the best approach might be for your own projects.

P.S. I’m genuinely happy that everything ended up working, and I’m extremely satisfied that this tool has made my daily work easier by reducing the number of clicks and minimizing the mental effort required for routine tasks. If you’re interested, don’t hesitate to download the app and give it a try!

DEV Community: Jack Chen

Optimizing My Code Editor with Flutter Profiling Tools

Introduction to Profiling

Enabling Profiling in Flutter

Enhancing Tracing for Detailed Insights

Identifying the Bottleneck

The Culprit: LineWidget

Optimizing LineWidget

Handling Lines Without Environment Variables

Cursor and Selection Highlighting

Results

Drawbacks and Future Improvements

Reflections

Real-World Use Cases

1. curl Commands

2. CloudWatch Queries

3. kubectl Queries

4. SQL Queries

Final Thoughts

From Characters to Lines: Refactoring My Code Editor for Better Performance and Two-Way Scrolling

Disclaimer

The Need for a Better Widget

Improvements in Widget Design

The Better Implementation: Controller Pattern

Pitfalls of the Controller Pattern

Testing the New Design

Reflections on the Refactoring Process

Two-Way Scrolling and Its Optimization**

The Inspiration for Two-Way Scrolling

Enter TwoDimensionalScrollView

A Naive First Attempt

The Performance Problem

Optimizing with Virtual Rendering

The Results

The Final Challenge: Profiling

Next Steps

In case anyone is interested, github links are available:

How I Created a Small Tool That Made My Work Easier

The Problem with Existing Tools

The Limitations of My Initial Solution

The Birth of My App Idea

Choosing the Right Technology

First Attempt to Write a Code Editor

Managing Profiles and Environment Variables

Event-Driven Communication

Rendering a Rune

Observing Code Editor Behavior

Building the RuneWidget

Handling Dynamic Updates

Moving Forward

Implementing the Three Key Features

1. Cursor and Its Blinking

2. Text Selection

3. Environment Variable Value Change

Addressing the Drawbacks

Lessons Learned

Conclusion

Reflections

The Culprit: `LineWidget`

Optimizing `LineWidget`

1. `curl` Commands

3. `kubectl` Queries

Enter `TwoDimensionalScrollView`

Rendering a `Rune`

Building the `RuneWidget`