DEV Community: Nikhil Verma

Agents should be able to time travel

Nikhil Verma — Tue, 06 Jan 2026 00:00:00 +0000

When I work on a tricky problem I often go down random directions. I explore, learn what I can, and bring the learnings back. And I remember not to go down there again. This exploration in my mind is similar to Age of Empires fog of war or slime mold exploring its surroundings and then finding the right path.

AI agents could learn to benefit from doing the same, and they do for the most part, but they've got a bottleneck. They can't forget useless things. It's all appended in their context, or compacted when the context window is about to be reached. This doesn't help and can be improved.

Right now there are a few ways agents deal with long context

Summarization Compress old messages into a summary. But summaries are lossy. You lose the reasoning chain the failed attempts, the "why" behind decisions
Stores Store stuff externally and retrieve when needed. But this is passive. The agent doesn't control what's stored or when it's retrieved.
Just... keep everything Until you hit the context limit and things get weird.

There's also some cool research happening here. The Reflexion framework lets agents reset their environment and try again, keeping self-reflections in memory. Tree of Thoughts explores multiple reasoning paths. And there's recent work like "Memory as Action" and "Git Context Controller" that treat context management as something the agent should actively control.

But they're either architectural changes (you need to rebuild your whole system) or they're too drastic (reset everything and start over).

history.go(-10, "Bruh this path was a dead end")

What if we gave the agent a tool? Something dead simple:

Ok I've learned enough here. Take this message as my learning, drop the last 20 messages, and let's continue.

That's it. The agent decides when to use it. The agent decides what to keep, decides how far back to go.

The important bit here is that the agent initiates this, not some external system watching token counts. The agent realizes "I've been spinning my wheels" or "I found what I needed" and actively chooses to clean up after itself. I think the smarter models like Opus 4.5 and GPT-5.2 will be able to do this well.

I'm imagining a tool like:

time_travel(
  learning: "The API doesn't support batch operations, need to loop instead",
  steps_back: 15 // or go_to: "message_id_12345"
)

The agent calls this. The system:

Takes the learning and injects it back as context (system prompt or user message)
Drops the last N messages from the conversation
Continues from there

There's this thing called Physarum polycephalum. It's a slime mold. It doesn't have a brain, but it can solve mazes and find optimal paths between food sources. Researchers even used it to recreate the Tokyo rail network. Here is a cool video of it in action:

How does it do this? It explores everywhere at first. Then it withdraws from dead ends while reinforcing successful paths. It doesn't keep track of every failed path — it just stops going there.

That's what I want for agents. Explore, learn, withdraw, reinforce. Not "append everything forever and hope the model figures it out."

LLMs as Unreliable Narrators: Dealing with UUID Hallucination

Nikhil Verma — Fri, 14 Nov 2025 00:00:00 +0000

TL;DR

Problem: LLMs make up identifiers (UUIDs) that don't exist in your data, which breaks your retrieval flow
Solution 1: Use enum constraints with readable identifiers when you control the workflow
Solution 2: Map UUIDs to simple tokens (ITEM-1, ITEM-2) for longer agent conversations
Result: Way fewer hallucinations and more reliable ID references

You've spent weeks building a neat RAG (Retrieval-Augmented Generation) system. Your embeddings are sharp, your retrieval is fast, and you've got the LLM hooked up to search through your data. You test it out, and then... the model returns a UUID that doesn't exist in your system.

This is one of those problems that catches you off guard because the LLM sounds confident. It's not hedging or saying "I'm not sure." It's just making up an identifier like a7f3c9e2-1b4d-4e8f-9c5d-2a8f7b9e3d1c with complete conviction.

Smaller models (like mini/fast variants) tend to do this more often. They'll invent IDs to sound authoritative.

The Core Problem

LLMs are pattern-matching machines. When you ask them to pick from a list of items using UUIDs, they see the format - that alphanumeric pattern with hyphens - and they try to reproduce it. But they're not really "remembering" your specific IDs. They're just generating something that looks like a UUID, and half the time, it's completely made up.

This creates problems downstream: you can't match outputs to stored objects, logging gets messy, and audit trails break. You end up with a bunch of "ID not found" errors.

Solution 1: Enums for Controlled Flows

If you're building a structured, agentic workflow where you control the entire decision path, you have a powerful tool: structured outputs with enums.

The idea is simple: instead of letting the LLM generate IDs freely, you constrain its response to only pick from valid options. Here's how it works:

// Helper to normalize titles and avoid duplicates
function normalizeTitle(t: string) {
  return t.trim().toLowerCase();
}

// Build a list of valid choices from your data
const seen = new Map<string, number>();
const validChoices = items.map((item) => {
  const norm = normalizeTitle(item.title);
  const count = (seen.get(norm) ?? 0) + 1;
  seen.set(norm, count);
  // Handle duplicate titles by adding a suffix
  return count === 1 ? item.title : `${item.title} (${count})`;
});

// Create a schema where the model must pick from an enum
const schema = z.object({
  selectedTitle: z.enum(validChoices as [string, ...string[]]),
  reasoning: z.string().max(240), // Cap verbosity
  confidence: z.number(),
});

// Use your LLM's structured output feature
const response = await llm.parse({
  schema,
  messages,
});

When you pass an enum constraint to the LLM, it can't hallucinate. The model knows it must pick one of the valid options. If it tries to return something outside the enum, the parsing will fail and you can retry.

The key trick: Use simple, human-readable identifiers (like titles) in your enum, not UUIDs. UUIDs are harder for models to reproduce accurately because they're random. Titles are memorable patterns.

Then verify the match server-side:

const selectedTitle = response.selectedTitle;

// Find the actual item by matching the normalized title
const actualItem = items.find(
  (item) => normalizeTitle(item.title) === normalizeTitle(selectedTitle),
);

if (!actualItem) {
  // Invalid selection - add feedback and retry
  messages.push({
    role: "user",
    content: `That title wasn't in the list. Please pick from: ${validChoices.join(", ")}`,
  });
  // Retry with feedback (consider exponential backoff)
}

When to use this: Controlled flows where you're calling the LLM as part of a defined process. Think: multi-step decision trees, validation agents, classification pipelines.

Limitations: Watch out for enum size - OpenAI caps schemas at 1000 total enum values, with character length limits for larger enums. If you're dealing with hundreds of items, you might want to do some top-N prefiltering or break it into chunks.

Solution 2: Deterministic Alias Tokens for Multi-Turn Flows

But what if your LLM is having a longer conversation where you're not controlling every single prompt? The agent is exploring, reasoning, making its own calls. Enums get awkward here because the agent might reference the same ID across multiple turns, and rebuilding your enum every time is messy.

That's where token mapping comes in.

The idea: create a simple mapping from tricky identifiers (like UUIDs) to easy ones (like ITEM-1, ITEM-2).

// Create token maps at the start of your agent run
const idToToken = new Map<string, string>();
const tokenToId = new Map<string, string>();
let tokenCounter = 1;

// When the agent needs to search or reference items,
// return tokens instead of real IDs
function mapItemsToTokens(items) {
  return items.map((item) => {
    // Reuse existing token if we've seen this item before
    let token = idToToken.get(item.id);
    if (!token) {
      token = `ITEM-${tokenCounter++}`;
      idToToken.set(item.id, token);
      tokenToId.set(token, item.id);
    }

    return {
      id: token, // Return the token, not the real UUID
      title: item.title,
      description: item.description,
    };
  });
}

Now when the agent works with items, it's dealing with ITEM-1, ITEM-2, etc. These are way harder to make up because they're simple and predictable. The agent picks them up quickly and usually sticks with them.

At the end, just decode the tokens back to real IDs:

// Helper for safer decoding
function decodeTokenOrThrow(token: string): string {
  const id = tokenToId.get(token);
  if (!id) throw new Error(`Unknown token: ${token}`);
  return id;
}

const decodedMatches = agentResponse.matches
  .map((match) => {
    const realId = tokenToId.get(match.itemId);
    if (!realId) {
      logger.error(`Agent returned unknown token: ${match.itemId}`);
      return null;
    }
    return {
      itemId: realId,
      confidence: match.confidence,
    };
  })
  .filter((m) => m !== null);

Why this works: Tokens are simple and sequential. The model picks them up easily and reuses them instead of making up new IDs. You've basically given the agent a clean vocabulary to work with.

When to use this: Multi-turn conversations, exploratory agents, any flow where the LLM is doing its own thing and needs to reference items consistently.

Pro tip: Every few turns, remind the model what tokens are active ("Active items: ITEM-1:titleA, ITEM-2:titleB...") to keep things fresh in longer chats.

Comparing the Approaches

Aspect	Enum Constraints	Token Aliasing
Setup Cost	Low (list mapping)	Medium (bidirectional maps)
Prompt Size Impact	High for large lists	Low (small tokens)
Multi-Turn Stability	Requires rebuild each turn	Naturally consistent
Hallucination Prevention	Complete (hard constraint)	Very high (simple patterns)
Best For	Single-shot decisions	Long conversations
Failure Mode	Parse error (retryable)	Unknown token (logged)

Combining Both Strategies

If you're building something more involved, you can mix both approaches:

Use tokens as your main interface to keep hallucinations low
Add enum validation for critical decisions as an extra safety net
Verify everything server-side before you commit the data

This gives you layered protection: the LLM rarely makes mistakes (tokens are simple), and when it does, you catch it.

The Takeaway

LLMs love to make up identifiers. They see the UUID pattern and just run with it. But you've got options:

For structured flows: Use enums to lock them into valid choices
For exploratory flows: Give them simple tokens to work with instead of UUIDs

Either approach cuts down hallucinations significantly. Pick whichever fits your setup better, and you'll save yourself a lot of debugging headaches.

Moving from React to Vue? Here's what to expect

Nikhil Verma — Mon, 21 Aug 2023 14:33:26 +0000

I moved from a React to a Vue project two years ago from a company change. If you are about to undergo a similar journey, this post will help.

I will not cover the basic differences between them. I will instead attempt to explain the conceptual differences that I found when switching.

Embrace Vue's reactivity

My favourite part about Vue is that you can simply modify state. Vue will track the changes and update the computed properties and UI automatically. In React this is done explicitly via setters or using libraries which internally do the same.

Before joining the Vue project I had read how mutating state is bad because you can't track where the changes are coming from. While this is a valid point, in practice a reasonable data organisation and development discipline makes it a non issue.

The productivity gains from modifying a state property and knowing that the UI will update automatically are incredible.

This also integrates well with effects and computed properties. You don't need to pass dependencies in your effects/computed properties, it "just works".

Here is an example code that works in Vue out of the box.

/* state.js */
import { ref } from "vue";
export const count = ref(0);

/* App.vue */
<script setup lang="ts">
import { count } from "./state";
</script>

<template>
    <div>The count is {{ count }}</div>
    <button @click="count++">count++</button>
</template>

Doing something similar in React will need a state management library.

Know your Vue version

There is a big difference between Vue 2 and 3 experiences. With the latter being more polished and better supported in the modern web development experience.

I have written about the pain we went through when migrating from Vue 2 to 3.

In React, you wouldn't have to worry about this as there haven't been major breaking API changes between version updates.

Vue 2 will reach end of life support on December 31st, 2023. My advice would be to plan a migration to Vue 3 as soon as possible.

Understand the core difference between Vue templates and JSX

API differences aside, you must have a basic understanding of how Vue templates operate internally and how they differ from JSX.

Vue templates are closer to HTML, JSX is closer to Javascript. (You might have heard the phrase "JSX is Javascript").

In JSX you can refer to local variables, use Javascript expressions and use JSX inline with other JS code.

In Vue you must define them inside a template block. They can only refer to values you have either provided in your component definition (options API) or present in your setup scope (composition API).

You also can't easily split Vue templates into inline code like JSX. They must be defined in a separate SFC file or a string template inside a render function (which needs runtime compilation).

An example of what I am talking about. Let's take two bits of Vue and React code. They basically behave in the same way. And let's compare their code (as you would write it) and their compiled output.

React

import HelloWorld from "./components/HelloWorld";
import Header from "./components/Header";
import HeaderAlt from "./components/HeaderAlt";

const App = () => {
  const isAlternateHeader = Math.random() > 0.5;
  const items = [1, 2, 3];

  return (
    <HelloWorld
      msg="Vite + React"
      header={isAlternateHeader ? <HeaderAlt /> : <Header />}
    >
      {items.map((item) => (
        <div {...{ [isAlternateHeader ? "alt-header" : "header"]: true }}>
          {item}
        </div>
      ))}

      {isAlternateHeader ? "Alt header" : "Header"}
    </HelloWorld>
  );
};

export default App;

React (as compiled by Babel)

import HelloWorld from "./components/HelloWorld";
import Header from "./components/Header";
import HeaderAlt from "./components/HeaderAlt";
import { jsx as _jsx } from "react/jsx-runtime";
import { jsxs as _jsxs } from "react/jsx-runtime";

const App = () => {
  const isAlternateHeader = Math.random() > 0.5;
  const items = [1, 2, 3];
  return /*#__PURE__*/_jsxs(HelloWorld, {
    msg: "Vite + React",
    header: isAlternateHeader ? /*#__PURE__*/_jsx(HeaderAlt, {}) : /*#__PURE__*/_jsx(Header, {}),
    children: [items.map(item => /*#__PURE__*/_jsx("div", {
      [isAlternateHeader ? "alt-header" : "header"]: true,
      children: item
    })), isAlternateHeader ? "Alt header" : "Header"]
  });
};

export default App;

Now let's look at a similar Vue code

Vue

<script setup lang="ts">
import HelloWorld from "./components/HelloWorld.vue";
import Header from "./components/Header.vue";
import HeaderAlt from "./components/HeaderAlt.vue";

const isAlternateHeader = Math.random() > 0.5;
const items = [1, 2, 3];
const dynamicAttribute = isAlternateHeader ? 'alt-header' : 'header';
</script>

<template>
  <HelloWorld msg="Vite + Vue">
    <template #header>
      <HeaderAlt v-if="isAlternateHeader" />
      <Header v-else />
    </template>

    <div :[dynamicAttribute]="true" v-for="item in items" :key="item">
      {{ item }}
    </div>

    {{ isAlternateHeader ? 'Alt header' : 'Header' }}
  </HelloWorld>
</template>

Vue (compiled by Vue SFC Playground)

import { defineComponent as _defineComponent } from "vue";
import {
  openBlock as _openBlock,
  createBlock as _createBlock,
  renderList as _renderList,
  Fragment as _Fragment,
  createElementBlock as _createElementBlock,
  unref as _unref,
  toDisplayString as _toDisplayString,
  normalizeProps as _normalizeProps,
  createElementVNode as _createElementVNode,
  createTextVNode as _createTextVNode,
  withCtx as _withCtx,
} from "vue";

import HelloWorld from "./components/HelloWorld.vue";
import Header from "./components/Header.vue";
import HeaderAlt from "./components/HeaderAlt.vue";

const __sfc__ = _defineComponent({
  __name: "App",
  setup(__props) {
    const isAlternateHeader = Math.random() > 0.5;
    const items = [1, 2, 3];
    const dynamicAttribute = isAlternateHeader ? "alt-header" : "header";

    return (_ctx, _cache) => {
      return (
        _openBlock(),
        _createBlock(
          HelloWorld,
          { msg: "Vite + Vue" },
          {
            header: _withCtx(() => [
              isAlternateHeader
                ? (_openBlock(), _createBlock(HeaderAlt, { key: 0 }))
                : (_openBlock(), _createBlock(Header, { key: 1 })),
            ]),
            default: _withCtx(() => [
              (_openBlock(),
              _createElementBlock(
                _Fragment,
                null,
                _renderList(items, (item) => {
                  return _createElementVNode(
                    "div",
                    _normalizeProps({
                      [_unref(dynamicAttribute) || ""]: true,
                      key: item,
                    }),
                    _toDisplayString(item),
                    17 /* TEXT, FULL_PROPS */
                  );
                }),
                64 /* STABLE_FRAGMENT */
              )),
              _createTextVNode(
                " " +
                  _toDisplayString(isAlternateHeader ? "Alt header" : "Header"),
                1 /* TEXT */
              ),
            ]),
            _: 1 /* STABLE */,
          }
        )
      );
    };
  },
});
__sfc__.__file = "src/App.vue";
export default __sfc__;

The translation from JSX to JS is simple because tags map to function calls and props map to object properties.

Vue has a more custom DSL where more code is needed to translate it to an executable Javascript code. This also comes into play when using it with Typescript.

Vue's Typescript support is... fine

If you are on a < Vue 2.7 project, you will have a bad experience with Typescript. You might even have to use other libraries to rewrite your Vue components using classes.

Even with a modern Vue 3 project, the Typescript support can be described as "fine". Since Vue templates don’t easily translate to Javascript, it has to do complex compilation to get the types working. Even then, certain things like context (provide/inject) and event arguments need typing manually.

Do you remember the earlier app example? Here is the internal Typescript representation of it's code using Volar (gist.github.com). I had to use a gist because the generated code is huge to allow proper type inference to work.

This is the outcome of using a custom DSL in Vue, it has it's tradeoffs.

Scoped styles out of the box

Vue also provides scoped styles out of the box. This means the following code will not leak CSS.

<style scoped>
.example {
  color: red;
}
</style>

<template>
  <div class="example">hi</div>
</template>

Final thoughts

I still prefer JSX over Vue templates but I vastly prefer the ref/reactive/computed systems of Vue.

My ideal UI library will offer first class template syntax of JSX and reactivity of Vue. Vue does support JSX but it has it's own set of gotchas.

Vue was designed with a certain set of tradeoffs, and it does them really well. If you have a Vue 3 codebase you will not find it too difficult to switch from React.

If you have a Vue 2 codebase however... Read my post here.

Why are you testing?

Nikhil Verma — Fri, 18 Aug 2023 04:55:32 +0000

You might already have some quick answers in mind for this question. I totally get it — I do too.

I'm not here to talk you out of testing or the usual testing processes. I just want to nudge you to think about why you're testing in the first place. Figuring out and questioning the "why" can really steer you towards the right testing methods and tools.

Here are a few questions you need to ask yourself.

Your project

What's the baseline quality that's expected for a project like yours?
Is uniform quality necessary across all interactions? For example, consider the user experience of your sign-up process. Is it worthwhile to channel efforts into refining that experience rather than testing a section that only a few users might visit?

Your audience

If you are building something which has yet to see the light of the day. Would you rather have it

Launch early but in a rough shape but risk a lukewarm reception from initial users?
Launch it later in a polished state but risk finding out that no one's interested?
Which user paths will be the most traveled? Consider interactions like visits to the settings page, are they frequent?

Your team

How big is your team?
Is everyone aligned on what the goal is?
What skill set and experience does your team possess?
What budget are you operating under? How long can you afford to develop before you need to generate revenue.

Considering the context that you are in will help you truly answer the question of "Why are you testing?".

Testing is not a one-size-fits-all approach. It requires thoughtful consideration of your audience, team, and project context.

By asking these questions and reflecting on your unique circumstances, you can shape your testing strategy to deliver a project that truly meets the needs of your users.

From Vue 2 to 3: A long journey

Nikhil Verma — Thu, 17 Aug 2023 14:19:49 +0000

TL;DR

This is a long post detailing my journey of migrating a project from Vue 2 to 3. It contains the setbacks and the victories I faced and providing breakdown of the issues as well.

1. Learning Vue

I joined my current team on May 2021, the project I was working with used Vue 2.6 And Vuex 3.4 and plain Javascript.

Vue 3.0 was already out at that point yet it was not the "default" Vue version. It won't be the case until Feb 7, 2022

2. The need for types

I was new to Vue back then and came from a React and Typescript codebase.

My first commit was to add a tsconfig.json just to have some intellisense. The pain point at that time was that Vue.extend for Vue 2 had poor support for Typescript. I wanted to fix it.

The solution came with the usage of vue-class-component with a combination of vue-property-decorator. Using a combination of the two allowed us to define components in a way that provide a reasonable amount of type safety.

The Vue component code would look something like this

import { Vue, Component, Prop } from 'vue-property-decorator'

@Component
export default class YourComponent extends Vue {
  @Prop(Number) readonly propA: number | undefined
  @Prop({ default: 'default value' }) readonly propB!: string
  @Prop([String, Boolean]) readonly propC: string | boolean | undefined
}

The migration to class components was done incrementally, any new features or components written using the class syntax. Older components were refactored out whenever we needed to change them.

We also switched our VSCode plugin from Vetur to Volar which had better Typescript support.

3. Using Vuex wrong

The Vuex stores were in the "traditional" redux style. They had a file structure like so:

store/
    actions.js
    getters.js
    index.js
    mutations.js
    state.js
    types.js

Good luck finding the right store by name! Or landing on the right action/mutation because there was no support for intellisense.

This got solved by migrating the stores to use vuex-module-decorators which came with a much better support for Typescript. Plus you get all actions/mutations/getters etc in a single file so it's easier to understand. This was also done incrementally.

Here is how the syntax for the decorator stores will look like.

import { Module, VuexModule, Mutation, Action } from 'vuex-module-decorators'

@Module
export default class Counter extends VuexModule {
  count = 0

  @Mutation
  increment(delta: number) {
    this.count += delta
  }

  @Action({ commit: 'increment' })
  incr() {
    return 5
  }
}

4. First setback

There was a spike done into the feasibility of migrating to Vue 3. It didn't last long because of the following reasons:

We used an internal UI library which depended on components that weren't compatible or were unstable with Vue 3 at the time
We couldn't figure out a reasonable strategy to migrate the UI library to Vue 3. Because then we would need to manage two versions of the same library.
We did not want to stop shipping our product while the migration was happening, it either had to be incremental or quick.

5. `vee-validate` and the `$slots` problem

The biggest hurdle that we faced was vee-validate. It is a form validation library built for Vue. The pain was that the library API for Vue 2 and 3 were entirely different.

You would almost call it another library, this was due to the new breaking $slots implementation in Vue 3 (more on that later).

Our UI library had used vee-validate to create a "form builder" that was used over 30 times in our application. We couldn't find an incremental upgrade path here. Either we migrate them all or we migrate none.

6. $slots between Vue 2 and Vue 3

The official migration documentation for slots unification goes over the API differences. It omits a major point: In Vue 3 it's not possible to get the DOM elements of the slots directly from the reference to the slot.

You would need to render your parent, then use the parent's HTML node to get the child slot selector. Or use some kind of inject/provide workaround.

This is the main reason why the vee-validate library could not use it's earlier, simpler API.

Here is a link to the problematic part of the code.

This wouldn't work anymore in Vue 3 because you can't directly extract the DOM nodes of children from the $slots property.

7. A new hope

On 1st July 2022 Vue 2.7 was released. It finally ported many features from Vue 3 back to Vue 2. This was a pivotal moment in our development because we it came with a solid Typescript support out of the box using defineComponent. This was better than vue-class-component because it needed some hacks to get inter-component type inference to work.

@matrunchyk had done a fantastic job creating a codemod to automatically migrate Vue class components to the earlier syntax. It was not perfect but workable.

I made some further modifications to it to get it to work on our project. It's available here if you want to try it for yourself: NikhilVerma/vue-codemod. It's still not polished enough to consider an upstream pull request but you can hack around to migrate your project with it.

We finally migrated to Vue 2.7 and defineComponent using the codemod in a very short time. Also used this to migrate most of the codebase to Typescript. Here is the timeline recorded in our JIRA ticket.

Date	JS Files
5th December 2021	244
22nd Feb 2022	173
23nd Feb 2022	138
24th Feb 2022	109
10th Mar 2022	103
7 Apr 2022	88
26 Apr 2022	54
9 May 2023	24
17 Aug 2023	22

At the same time, we noticed several library dependencies migrated to support Vue 3 with minimal API changes. This was exciting!

8. The solution to vee-validate

Now the only thing preventing a smooth migration was the vee-validate library. We were in luck because our UI team was working on a second version of the Flow UI library which used Lit. It also offered a replacement Form builder which could take over the vee-validate one.

Since the new library used Lit, it was agnostic of Vue 2 or 3 so incremental migration was easy.

9. Let's do this!

The final plan was in place:

Migrate all old form and vee-validate instances with the new Lit ones
Migrate remaining UI components in the library to support Vue 3
Migrate the application to Vue 3 in a single PR

The first step took around a month to complete, as the instances has to be migrated incrementally. The second step was faster, around a week to migrate because most of the other libraries had good backwards compatibility.

The third was easy too. Vue codemod helped a lot, and ESLint + Typescript caught most issues. The lifesaver was our automation suite which made sure we didn't break any critical functionality in the application.

Here is a screenshot of the pull request which migrated our app to Vue 3. (edited out the internal bits)

After almost two years. We migrated to Vue 3. Because we prepared so well the final merge was uneventful. We had a few bugs discovered afterwards, mostly due to how boolean attributes have changed in Vue 3.

10. Aftermath

We are happily using Vue 3 since then. And I hope that future Vue upgrades will be less eventful and not need writing posts like these.

I hope this was helpful to you, I am sure that there are others who are still using Vue 2 on larger codebase and having a tough time with it. And I hope by sharing their experiences it will encourage others to start their migration journey.

XPaths in the modern age

Nikhil Verma — Thu, 01 Jun 2023 13:07:53 +0000

XPaths are selectors you can use to query the elements in your document (HTML, XML etc). They are similar but complex and more featureful versions of CSS query selectors many are used to.

This is an example XPath which can find the Google Search button by starting from the search input. It's a roundabout way of doing this but it shows the powers of XPath over normal query selectors which can't do this.

$x(`//textarea/ancestor::form//input[@value="Google Search"]`);

XPath with Web components

Since XPath is a pretty old specification (created in 1999 and last updated in 2016). It doesn't specify how to operate with Web components and shadow DOM.

So if you want to write an XPath which selects an element inside the shadow DOM of a component you simply can't. The only solution is to find the component with the XPath. Then use the shadowRoot node to then further drill down into the component. For nested components it quickly becomes impractical.

To be fair this problem with shadow DOM is also present in querySelectors which don't work with it either. Lit has it's own section dedicated to using custom @query decorators to find elements.

XPath with Vue 3

There is a very specific and peculiar problem that you face when using XPaths with Vue 3, which took me a long time to debug and find out.

Vue 3 when rendering child slots appends what's called "anchor" nodes to help it optimise it's updates. For example if you have a component like this:

<Text>
   Hello World!
</Text>

And you render it in Vue 3 like this.

<span>
    <slot />
<span>

What Vue 3 will do is output the following DOM structure

<span>
    ""
    "Hello World!"
    ""
</span>

Here "" is an empty text node. This trips up the contains(text()) API of XPath. So if you were relying on your elements containing a specific text you won't be able to do that anymore.

Here is a Github issue with examples. vue/core/issues/8444

A workaround

To solve both of the problems above, I had to ponyfill XPath in our application.

There was an excellent xpath polyfill library which I forked and modified to add support for both Shadow DOM and Vue 3 text nodes.

This makes it "non spec" but it solves our needs and doesn't impact our development velocity.

It's published here xpath-next

import { parse } from 'xpath-next';

const expression = "//span";
const contextNode = document.body;

const nodes = parse(expression).select({ node: contextNode, isHtml: true });

My key takeaway from this experience is reliable technologies stop being so because the ecosystem moves on and makes them incompatible.

One could argue that Vue 3 behaviour should be fixed. But the fact that Web components don't work transparently with XPaths makes it hard to justify using it in it's original specification.

DEV Community: Nikhil Verma

Agents should be able to time travel

history.go(-10, "Bruh this path was a dead end")

LLMs as Unreliable Narrators: Dealing with UUID Hallucination

TL;DR

The Core Problem

Solution 1: Enums for Controlled Flows

Solution 2: Deterministic Alias Tokens for Multi-Turn Flows

Comparing the Approaches

Combining Both Strategies

The Takeaway

Moving from React to Vue? Here's what to expect

Embrace Vue's reactivity

Know your Vue version

Understand the core difference between Vue templates and JSX

React

React (as compiled by Babel)

Vue

Vue (compiled by Vue SFC Playground)

Vue's Typescript support is... fine

Scoped styles out of the box

Final thoughts

Why are you testing?

Your project

Your audience

Your team

From Vue 2 to 3: A long journey

TL;DR

1. Learning Vue

2. The need for types

3. Using Vuex wrong

4. First setback

5. vee-validate and the $slots problem

6. $slots between Vue 2 and Vue 3

7. A new hope

8. The solution to vee-validate

9. Let's do this!

10. Aftermath

XPaths in the modern age

XPath with Web components

XPath with Vue 3

A workaround

5. `vee-validate` and the `$slots` problem