Good question, and not one I was contemplating conciously. I don’t know if it fits my use case. I don’t want to submit whole forms, the idea is to submit individual fields. So, as it is now, each input sends spike-form-event:set-value to the backend, which updates only one form field. The form, as a whole, lives on the server, on the client it’s just a bunch of individual inputs.

I wasn’t making a conscious decision not to use Phoenix.HTML.Form but there are several factors why I figured focusing on individual fields rather than one HTML element

1. I can spread the inputs / controls throughout the page, not worrying about nesting HTML form tags or even validity of HTML, mixing parent, children and even unrelated forms together

2. Some of my “forms” are not really forms at all, but “backend structures for the UI” with input element here and there

3. Changing / submitting the form doesn’t require the whole form to be submitted. Only changed field is submitted to the backend. I guess this could even be improved by just sending diff. I need to look into that as we do indeed have some long text inputs that could use an improvement. But sending one of them, rather than 3, is already an improvement. We don’t yet do that, but we’re looking into collaboration of multiple users on the same form, I think syncing individual inputs rather than whole edits of whole forms is going to be easier.

With 3) there is a possible issue of race condition where some input wasn’t synced yet and user hits “Save”, but I am working this around for now with a slight delay on the “Submit” button and users haven’t reported problems. Something to consider.

I’d be curious why you didn’t implement Phoenix.HTML.Form to be able to use the existing phoenix helpers to build the markup, just powered by a different system beneight.

The Spike readme file does not have defined elixir as a code language after ```, so on github it does not have syntax highlight.

How about making 2nd argument of Spike.append/4 and Spike.update/3 optional?

For example Instead of:

  @doc false
  def append(%{ref: ref} = struct, ref, field, params) do
    append(struct, field, params)
  end

  @doc false
  def append(struct, ref, field, params) do
    append_embeds(struct, ref, field, params, embeds(struct))
  end

You could have:

  @doc false
  def append(struct, ref \\ nil, field, params)
  def append(struct, nil, field, params) do
    append(struct, field, params)
  end

  @doc false
  def append(struct, ref, field, params) do
    append_embeds(struct, ref, field, params, embeds(struct))
  end

Do you plan any support for i18n error messages? Just returning %{field_name: "spike.validations.acceptance"} as a result of an extra function would help a lot I think. Also equivalent of Ecto.Changeset.validations/1 would be amazing.

Do you plan to support custom types (like Ecto.Type), so developers does not need to validates multiple times?

Do you have plans for optional ecto support in future creating for example by spike_ecto?

That looks super nice. I’m curious how you would build a form, where the structure is provided at runtime. My common use-case lately is receiving a JSON-Schema and rendering a form dynamically.

Similar to this: GitHub - json-editor/json-editor: JSON Schema Based Editor

Answering your questions,

1. Spike.append/update default param is great idea, opened an issue and is now on my todo list.
   Make 2nd argument for Spike.update and Spike.append optional · Issue #6 · hubertlepicki/spike · GitHub

2. I18n great idea, opened issue
   Support gettext for error messages · Issue #2 · hubertlepicki/spike · GitHub

3. The casting & validations are something I need to rethink. This has been put together very quickly to make it work, and uses Vex and Tarams libraries. Tarams already steals code from Ecto, I believe, so you can define own types. But I do need to rethink both of these decisions in long term.

4. spike_ecto no, the way I use these forms are entirely in-memory and then, after form is “valid” I feed the valid form to a workflow that performs some actions. Doing ecto inserts / updates / removes manually does not bind the database schema to UI, which I think is an antipattern

I suspect my main focus shortly will be the performance improvements Improve performance of very large forms · Issue #1 · hubertlepicki/spike · GitHub It’s not a big problem in the app I use it in, as the “large” forms maybe have dozens of child records but there is no good reason it shouldn’t support thousand or more child forms. Currently the updates are doing very naive walkthrough of the graph and this can be and should be improved.