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?