Form validation patterns in Hologram

[bartblast]

@mwmiller

@bartblast

Instead, use the last “green” commit from the dev branch:

I tried this out and it works great! Except for that it exposes a problem I had before with the $blur event.

My site has a form which includes user-enterable numeric strings. These are sent to the server for validation and then new data is presented. I don’t have a submit button or anything, it’s just “magic.”

I initially tried to use $blur events to avoid sending on each keystroke, waiting for the user input to appear complete. However, I couldn’t figure out how to get the value of the input therewith. So I moved to $change and chalked it up to my ignorance.

With the above version, I now get crazy responsive stuff with each keystroke… but this makes it impossible to enter a long number because it’s already validated, returned and changed in the very box in which I am typing.

I’ve learned a lot since I first started this (thanks!), so I tried $blur again with high hopes. Not so much. I put in a debug command called from the $blur-fired action:

Debug command received: %{event: %{}}

So, I know a particular input has blurred and I should check its value, but I don’t get this value in the event. Should I be doing something in the action to extract the input value from the component?

@mwmiller That part about “crazy responsive stuff with each keystroke” honestly sounds like it could be a Hologram advertisement! But I understand the UX concern you’re raising.

Here are the key technical facts about Hologram’s event system:

Synthetic Events: Hologram uses synthetic events (similar to React). For example, $change maps to the native input event, not the native change event.

Form-level vs Field-level Events: The $change event behaves differently depending on where you put it:

• On a text input: triggers on every keystroke (maps to input event)
• On a form: behaves like the native change event - typically triggers when a field loses focus

$blur Events: These map directly to native blur events and can be triggered on many element types (links, buttons, etc.), not just form elements. That’s why they don’t include a value property - it wouldn’t make sense for non-form elements.

Client-side Validation: Here’s the key architectural point - you don’t need to go through the server for initial validation! Hologram runs Elixir in the browser, so you can do validation client-side. Your validation code will be isomorphic - the same Elixir validation logic (including Ecto changesets) can run both client-side and server-side. You should still validate server-side as a security measure and for data integrity (e.g., when saving to database, checking business rules, ensuring referential integrity), but the initial user feedback can be immediate and local.

Suggested Pattern: For your use case, try this approach:

1. Use $change event on your input field to sync the value with your component state instantly only if you need to use that value elsewhere in your component or modify it through other actions - otherwise, you can skip this step since the form’s $change event will include all current form field data
2. Use $change event on the form element to trigger validation when the user stops inputting (e.g., when the field loses focus)
3. Run your validation logic client-side for immediate feedback
4. Validate again server-side when actually persisting the data