kartheek
Indy Forms - Simplify Your Forms
Indy Forms
Forms can be simplified using IndyForm. A form can be implemented in just couple of lines.
use IndyForm.FormComponent, context: Context
form_component(form_key, create_action, update_action, opts)
form_key: is your schema name. This is used for finding the form in the params.create_action: can be anatomorlist of atoms. This is used to determine what action should be performed - create or update.update_action: can be anatomorlist of atoms. This is used to determine what action should be performed - create or update.
create_actionorupdate_actionvalues can be directly mapped to socket.assigns.live_action values.opts:change_listenerscan be enabled throughopts
form_component(form_key, create_action, update_action, change_listeners: true)
Example
A complete example which reduces around 50 lines of boilerplate code form component to 3 just lines:
defmodule UserForm do
alias IndyFormSample.Accounts, as: Context
use IndyForm.FormComponent, context: Context
form_component("user", :new, :edit)
end
or can be writen in verbose 7 lines if you prefer this way:
defmodule UserForm do
alias IndyFormSample.Accounts, as: Context
use IndyForm.FormComponent, context: Context
@form_key "user"
@create_action :new
@edit_action :edit
form_component(@form_key, @create_action, @edit_action)
end
Value Change Listeners
on_value_change/2 is invoked when there is a change is detected in field while handling validate event.
key is an atom - which is field name defined in your form.
You can override to handle changes in form happening without writing a single line of javascript.
Note: Don’t forget to enable value change listeners by passing change_listeners: true through form_component opts.
# handle changes relating to field :contact_me
def on_value_change(socket, {:contact_me, _old_value, new_value}) do
show_phone? = show_phone?(new_value)
show_email? = show_email?(new_value)
socket
|> assign(:show_phone, show_phone?)
|> assign(:show_email, show_email?)
end
# needed for handling changes not relating to our fields of interest
def on_value_change(socket, _), do: socket
Design Goals
Design goals of this library :
- less code injection through macros.
- less magic and more explicit configuration.
- flexibility to override everything to perform one off customizations.
- reduce boilerplate code in application.
You can read docs about forms and contexts.
Browse code at GitHub - lkarthee/indy_form: Simplify LiveView Forms.
And browse sample code here - GitHub - lkarthee/indy_form_sample: A sample project using IndyForm
I want hear more from you - please share feedback or discuss about use cases or suggest design changes.
Note: this library is not published on Hex. You can use it from GitHub. I want to publish after hearing your feedback.
Regards
Kartheek
Edits: changed sample code to reflect few changes.
Most Liked
al2o3cr
One consistent pain-point with libraries like this (not Elixir-specific, see also Devise and many others) is providing enough hooks / APIs / abstraction-points that people can customize the behavior without having to start over from scratch.
For instance, what if I wanted to display a different flash message when creation succeeds? The current messages are hard-coded deep inside apply_crud_action:
I18n could be an easy-to-add escape hatch for this particular case, since it’s just text.
But things get rougher for behavioral changes: for instance, if I wanted to display a “your changes couldn’t be saved” flash message on error. That’s also buried inside of create and update, and not easily overridable.
derpycoder
Phoenix 1.7 is going to have redesigned Form API, because form API sucks.
Chris McCord iterated at the end of his ElixirConf 2022 talk.
How can your library help with that kind of problem?
For instance, he mentions choose your own adventure kind of form, i.e. based on your previous selection, new form sections get rendered. (Which doesn’t work well with Ecto Changesets and Phoenix HTML Form data protocol.)
kartheek
Thank you @al2o3cr for your feedback.
I have refactored library:
- to include
on_event,on_errorto handle more scenarios. - removed
nameparam to the macro from which flash messages were being generated.
Please look at this version and provide your inputs if any.
It does not make sense to generate flash messages - considering issues relating to i18n and message customisation. on_error/2 and on_success/2 can be overridden to generate flash messages.
It’s a challenge to keep up with changes in Phoenix Live View with every release and its not abnormal considering it has not yet reached 1.x .
With a fairly large application with more than 50 form components - i ended up with a lot of files and heex templates. When migrating from controller based pages to live view I faced a lot of issues with boilerplate code. In mid way, I stopped the migration and refactored all the migrated live view pages using high level components.
I realised that the only way to stabilise my application code is by using stable things from Live View and fill pages with high level components. That way if I have to upgrade to a new release of LiveView, i will just upgrade the high level components like form, table, etc. Even the .heex pages are filled with either html tags or high level components. I got rid of <%= if … do %> tags with 0.18.x.
derpycoder
This link is broken.
kartheek
Fixed it thanks.







