# Element IDs and request-scoped seeding

Vident gives every component a stable DOM ID derived from a per-request
seed. The seed is set in a `before_action` (the install generator wires
it up); the result is:

- **Deterministic within a request** — re-rendering the same component in
  the same request produces the same ID, so cached fragments rehydrate
  cleanly and Stimulus targets/outlets keep referring to the right
  elements.
- **Distinct across requests** — two concurrent requests rendering the
  same component get different IDs, so if one happens to spill into a
  shared cache it doesn't poison the other.

## Strategies

The default strategy is a counter seeded from the request UUID. Other
strategies are pluggable via the initializer:

```ruby
Vident.configure do |config|
  config.stable_id_strategy = :counter # default
  # config.stable_id_strategy = :uuid  # one fresh UUID per element
end
```

## Rendering outside a request

In Rake tasks, mailer previews, or scripts that render components in
isolation, set the seed yourself:

```ruby
Vident::StableId.with_sequence_generator(seed: "my-task") do
  puts ProductCardComponent.new(product: p).call
end
```

Or, for one-off use:

```ruby
Vident::StableId.set_current_sequence_generator(seed: "my-task")
```

`with_sequence_generator` is preferable in long-lived processes — it
restores the previous generator on exit.

## The collision bug in earlier versions

Before request-scoped seeding (Vident <= 1.x), two concurrent requests
could share the in-process counter and emit the same DOM ID, which broke
Stimulus targeting on cached pages. The current strategy makes this
impossible. If you're upgrading from 1.x and have any custom `id`
overrides, audit them — fixed-string IDs still collide and you should
move them onto the seeded path.

Element IDs and request-scoped seeding

Vident gives every component a stable DOM ID derived from a per-request seed. The seed is set in a before_action (the install generator wires it up); the result is:

Deterministic within a request — re-rendering the same component in the same request produces the same ID, so cached fragments rehydrate cleanly and Stimulus targets/outlets keep referring to the right elements.
Distinct across requests — two concurrent requests rendering the same component get different IDs, so if one happens to spill into a shared cache it doesn’t poison the other.

Strategies

The default strategy is a counter seeded from the request UUID. Other strategies are pluggable via the initializer:

Vident.configure do |config|
  config.stable_id_strategy = :counter # default
  # config.stable_id_strategy = :uuid  # one fresh UUID per element
end

Rendering outside a request

In Rake tasks, mailer previews, or scripts that render components in isolation, set the seed yourself:

Vident::StableId.with_sequence_generator(seed: "my-task") do
  puts ProductCardComponent.new(product: p).call
end

Or, for one-off use:

Vident::StableId.set_current_sequence_generator(seed: "my-task")

with_sequence_generator is preferable in long-lived processes — it restores the previous generator on exit.

The collision bug in earlier versions

Before request-scoped seeding (Vident <= 1.x), two concurrent requests could share the in-process counter and emit the same DOM ID, which broke Stimulus targeting on cached pages. The current strategy makes this impossible. If you’re upgrading from 1.x and have any custom id overrides, audit them — fixed-string IDs still collide and you should move them onto the seeded path.