sercrod

@submit

Summary

@submit attaches a handler to the native submit event. The expression on @submit is evaluated when a form is submitted and the submit event reaches the element that declares @submit. Typical uses include validating data, toggling flags, or invoking custom submission logic before or instead of the browser’s default form submission.

@submit is part of the event handler family (such as @click, @input, @change, @keydown) and follows the same general evaluation rules as other @ directives. It does not automatically prevent the browser’s default submission; use modifiers or *prevent-default when you want to block navigation.

Basic example

Intercept form submission and mark the form as submitted without leaving the page:

<serc-rod id="contact" data='{
  "form": {
    "name": "",
    "message": ""
  },
  "submitted": false
}'>
  <form @submit.prevent="submitted = true">
    <label>
      Name:
      <input type="text" name="name" :value="form.name">
    </label>

    <label>
      Message:
      <textarea name="message" :value="form.message"></textarea>
    </label>

    <button type="submit">Send</button>

    <p *if="submitted">
      Thank you, we received your message.
    </p>
  </form>
</serc-rod>

Behavior:

Behavior

Core rules:

Evaluation timing

@submit participates in the normal Sercrod render and event lifecycle:

Execution model

Conceptually, Sercrod handles @submit as follows:

  1. During rendering, Sercrod encounters an element with an attribute whose name begins with the events prefix and whose base name is submit, such as @submit or @submit.prevent.stop.

  2. Sercrod strips the prefix and splits the remaining part on dots:

    • "submit.prevent.stop" becomes event name submit and modifiers prevent and stop.

  3. Sercrod reads the attribute value as an expression string, for example handleSubmit($event) or submitted = true.

  4. Sercrod builds a handler function handler(e) that:

    • Applies the prevent modifier by calling e.preventDefault() if present.

    • Applies the stop modifier by calling e.stopPropagation() if present.

    • Creates a proxy scope that:

      • Exposes $event and $e as the native event.
      • Exposes el and $el as the element with @submit.
      • Falls back to data on the host and then to window for global names.

    • Invokes eval_event(expr, mergedScope, { el, $event: e }).

    • Decides how to update the host after the expression, based on the event name and modifiers (see below).

    • Removes itself if the once modifier is set.

  5. Sercrod registers this handler with addEventListener("submit", handler, options) on the element, where options reflect capture, passive, and once.

  6. When the handler finishes without throwing, Sercrod applies its default update strategy:

    • It treats submit as a mutating event, so by default it triggers a full host update, unless modifiers override this behavior.

The expression runs in the context of the host; any property writes to data are marked as dirty and become visible in subsequent renders.

Interaction with form submission

Because @submit hooks into the native submit event, it integrates with normal form behavior:

Update strategy and performance

The generic event engine applies an update strategy after each handler:

This strategy ensures that typical form flows see an updated UI after submit (for example showing confirmation messages or clearing fields), while still allowing you to suppress updates when not needed.

Use with attribute bindings and staged forms

@submit combines naturally with attribute bindings and staging mechanisms:

Use with conditionals and loops

Like other event directives, @submit can be used with structural directives that control the element itself:

Sercrod-specific restrictions

For @submit itself, there are no special Sercrod only restrictions beyond the general event rules:

Unlike structural directives such as *each, *include, or *import, @submit does not participate in element ownership rules for children, so there is no restriction like “only one per element” for @submit.

Best practices

Additional examples

Minimal custom submit with validation:

<serc-rod id="signup" data='{
  "email": "",
  "error": "",
  "ok": false
}'>
  <form @submit.prevent="
           error = (!email || email.indexOf('@') === -1)
             ? 'Please enter a valid email.'
             : '';
           ok = !error;
         ">
    <input type="email" name="email" :value="email">
    <button type="submit">Sign up</button>

    <p *if="error" *print="error"></p>
    <p *if="ok">
      Check your inbox to confirm your email.
    </p>
  </form>
</serc-rod>

Listening on a wrapper element instead of the form:

<serc-rod id="host" data='{
  "count": 0
}'>
  <div @submit.prevent="count = count + 1">
    <form>
      <input type="text" name="q">
      <button type="submit">Search</button>
    </form>
  </div>

  <p>Submits in this area: {{%count%}}</p>
</serc-rod>

In this pattern, the form still fires submit, and the event bubbles to the wrapper div where @submit is attached.

Notes