Form validation patterns in Hologram

There is a very particular “genre” of mistake you’re probably making here, but instead of trying to explain it I will just link this article which goes over it in enormous detail:

This is somewhat off-topic (as I alluded to earlier in the thread, this is an interface design problem), but maybe you will find it helpful.

I did find it helpful, thank you! I started out feeling vaguely insulted and ended up feeling fairly enlightened. Thank you again.

You got garrison’d

Good article, though.

As another totally off-handed remark: from that article, Vim calls the field that tracks where the cursor should land on shorter lines curswant which I find oddly adorable.

@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

I’ve applied a (very) little effort toward using your suggestions. I think I understand all of the messages which will be passed. It looks like I should be able to make good progress on this when I have a fresh mind and some time tomorrow.

I am also going to try to build some simple intent-gathering inside the component when I do this. It should be an interesting project about which no one will ever care, except those I bother on this forum.

Just a minor update, to sort of close the loop.

I am now using Hologram 0.6.2. Today I implemented an intent system and it’s working well. I do still have some kinks to work out based on my particular domain. In any case, I wanted to thank everyone in the thread here for their time and guidance.