Phoenix.HTML.Link.button with params

From the docs

button("hello", to: "/world", method: "get", class: "btn")
#=> <button class="btn" data-method="get" data-to="/world">hello</button>

Try

button("hello", to: "/world", method: "get", class: "btn", custom: "property")
#=> <button class="btn" data-method="get" data-to="/world" custom="property">hello</button>

Image from my test:

Apologies if I have been unclear but I’d like custom=property to be sent out within the ajax call that submits the form, while your solution only adds an html custom attribute, doesn’t it?

I see, so this button is in a form?

Have you considered adding properties as hidden inputs?

I’m not sure why this was added to rails, but conceptionally it seems quite strange to exist. GET parameters are part of the url, so I’m not sure why they should be added via options on the button. Phoenixs’ route helpers allow you to add GET parameters to urls as well as the URI module of the elixir core. If you’re looking for additional body params you’d need to wrap the button in a form to submit, which has some hidden inputs.

Phoenix doesn’t use javascript to perform ajax calls, Phoenix is just a server that lets you do on the front-end whatever you wish. If you have something that needs to perform ajax calls then it is that which should do it, phoenix will just handle the back-end side. What front-end are you using that performs ajax in the browser?

Completely agreed with the fact that GET parameters should be in the query URL.

But button\2 is actually more useful in the case of a POST/PUT/DELETE query IMHO, where params act as extra hidden fields.

Anyway, since it is phoenix_html.js which actually submits data, it could be conditional on the method so that GET is in the query parameter, and others are hidden fields.

I guess that’s what Rails does.

Cool thing about this is that method can be dynamic without having to rewrite the logic:

= button("content", to: "/example", method: method, params: params)
/ instead of
= if method == :get do
  = button("content", to: "/example?#{params |> Enum.map(fn k, v -> "#{k}=#{v}" end) |> Enum.join("&")}"
- else
  = button("content", to: "/example", method: method, params: params)

Oh ok, I thought it would, like rails_ujs does. But apparently it does has JS dependency.

Of course, one can do without it, but in this case, it seems pretty reasonable to use it the phoenix-way so that front-end and back-end plug each other easily.

Rails is really great at doing this, and I guess if phoenix is so much inspired from it, it means it is trying to reach the same convenience.

Basically instead of

      content_tag(:button, text, [data: [method: method, to: to] ++ csrf_data] ++ opts)

I’d expect to go for:

      content_tag(:form, text, method: method, action: to) do
        if method != :get do
          hidden_field(:csrf_token, Plug.CSRFProtection.get_csrf_token())
        end
        Enum.map(opts[:params], fn k, v -> 
          hidden_field(k, v)
        end) 
        content_tag(:button, text, type: :submit)
      end

And this would work for either :get and :post.

Phoenix’s button handling with method is mostly a convenience to not need to wrap just a button with a form, to defines nothing more than a url/method. If you need more data as part of the request use a form with hidden fields. You’re imho past the point there the convenience does make much sense.
For get requests you could alter the url, but a form will also just use get params if you submit it with the GET method. I guess both ways are viable for get parameters.

If you’d use form_for instead of content_tag(:form, …) you’d get the csrf token and the method override automatically and it would therefore work for any http method.

No clue what rails_ujs is, but I can’t imagine such a feature working without javascript support for it, and thus it will fail when javascript is disabled. It’s really not something that should be relied on.