# `MishkaCmsCore.Runtime.JsHook`
[🔗](https://github.com/mishka-group/mishka_cms_core/blob/v0.0.1/lib/mishka_cms_core/runtime/resources/js_hook.ex#L5)

Manages JavaScript and TypeScript hooks in the MishkaCMS runtime system.

This resource handles client-side code hooks that can be dynamically injected into pages
for enhanced interactivity and custom behaviors. JS hooks support both JavaScript and
TypeScript formats, can be scoped globally or to specific sites, and are loaded based
on priority ordering. Each hook contains executable code that integrates with the
Phoenix LiveView hook system or runs as standalone scripts.

The resource implements activation/deactivation controls allowing hooks to be temporarily
disabled without deletion, and soft deletion through archival for recovery capabilities.
Hooks automatically trigger background compilation jobs when modified, ensuring optimized
delivery to client browsers. Priority-based loading ensures critical hooks execute first.

Database-level constraints prevent empty content and modifications to archived hooks,
while multi-tenant support ensures proper isolation between sites. The resource provides
specialized queries for retrieving active hooks with global fallback, making it easy
to gather all applicable hooks for a given site context.

# `t`

```elixir
@type t() :: %MishkaCmsCore.Runtime.JsHook{
  __lateral_join_source__: term(),
  __meta__: term(),
  __metadata__: term(),
  __order__: term(),
  active: term(),
  aggregates: term(),
  archived_at: term(),
  calculations: term(),
  content: term(),
  description: term(),
  file_extension: term(),
  format: term(),
  id: term(),
  inserted_at: term(),
  is_global: term(),
  latest_version: term(),
  lazy: term(),
  modules: term(),
  name: term(),
  npm: term(),
  paper_trail_versions: term(),
  permissions: term(),
  priority: term(),
  recent_versions: term(),
  site: term(),
  site_id: term(),
  sorted_versions: term(),
  updated_at: term(),
  version_count: term(),
  version_preview: term()
}
```

# `__guarded_change__`

Apply the full GuardedStruct pipeline (sanitize → validate → derive →
main_validator) to `attrs` and return either `{:ok, transformed_attrs}`
or `{:error, errors}`. Wire this into an `Ash.Resource.Change` to plug
guardedstruct rules into Ash's changeset pipeline.

The function is named `__guarded_change__` because it does more than
validate — it can also transform values (trim, downcase, slugify,
auto-fill, etc.) before they reach the data layer.

# `__guarded_field_meta__`

O(1) lookup of a field's compile-time metadata by name. Returns
`nil` for unknown fields.

# `__guarded_field_name_set__`

Compile-time-baked `MapSet` of every field name owned by the
`guardedstruct` block. Used by `GuardedStruct.AshResource.Change`
to decide, in O(1), whether a key in `changeset.atomics`
belongs to the pipeline.

# `default_short_name`

# `input`

```elixir
@spec input(values :: map() | Keyword.t()) :: map() | no_return()
```

Validates that the keys in the provided input are valid for at least one action on the resource.

Raises a KeyError error at compile time if not. This exists because generally a struct should only ever
be created by Ash as a result of a successful action. You should not be creating records manually in code,
e.g `%MyResource{value: 1, value: 2}`. Generally that is fine, but often with embedded resources it is nice
to be able to validate the keys that are being provided, e.g

```elixir
Resource
|> Ash.Changeset.for_create(:create, %{embedded: EmbeddedResource.input(foo: 1, bar: 2)})
|> Ash.create()
```

# `input`

```elixir
@spec input(values :: map() | Keyword.t(), action :: atom()) :: map() | no_return()
```

Same as `input/1`, except restricts the keys to values accepted by the action provided.

# `json_api_match_route`

# `primary_key_matches?`

---

*Consult [api-reference.md](api-reference.md) for complete listing*