Phoenix: Enhanced Phoenix.HTML.Link

[essenciary]

Doing some development with Phoenix and really missing the conveniences and succinctness of the Rails URLHelper.

Most urgently and importantly:

• the :confirm data attribute (implemented unobtrusively, without external dependencies on JS libraries)
• link_to_if
• link_to_unless

Are they planned or is anybody working on them already? If not, I can take a stab at implementing them.

[josevalim]

Please go ahead! We do need help implementing those conveniences.

[essenciary]

Thanks, will do.

[BlakeWilliams]

@essenciary You still working on this? If not I wouldn't mind attempting it.

[essenciary]

After further discussions with the core team, this basically can be broken into 2 parts:

1. the unobtrusive JS part - where we agreed to:
   a. skip support for custom :confirm attribute (as @josevalim said that rails is moving away from it) and just add it as a normal "data-" attribute. So nothing to be done here.
   b. port the rails' jquery-ujs
2. link_to_if / link_to_unless - where we haven't discussed anything but the implementation should be straightforward

I've just started on 1 and haven't done anything on 2 yet. Don't have too much time these days so if you want to pick one up, please go ahead. Just let me know each one, so I can tackle the other.

[chrismccord]

I'm not convinced link_to_if and link_to_unless are neccessary. These are not helpers I've ever used and can be easily achieved with a wrapping <%= if expr do %><%= link "something", to: ... %><% end %>. I'll let others chime in though. Maybe these is a highly used feature by others?

[djm]

@chrismccord I have to agree with that.

Not coming from the world of Rails, I had to look up what the functions did and having done that I'm now certain I'm missing something that they do as otherwise they just seem to take what would otherwise be perfectly good HTML and turn it into a function call.

For frontend developers that do not know a template system in depth it would seem your solution is the easier one for them to get to grips with, as they'd see a given anchor's CSS classes and IDs in the HTML as one would expect, not hidden in a function call.

To back this up, coming from the Python world, both of the two larger templating systems (Django's & Jinja2) stick with what you've suggested and just provide some kind of way of generating a URL and leave the rest up the user.

Having said that, if the functions do add something I'm missing, please do shout!

[sorentwo]

I would much rather see a jquery-less port of ujs included. Less overhead for a rather small set of features, not likely to conflict with other bundled assets. I'm willing to do the porting if desired.

[chrismccord]

port the rails' jquery-ujs

Can someone clarify what all is provided with the port? Are we talking about the remote: true stuff in rails, or just data-confirm?

I would much rather see a jquery-less port of ujs included.

Agreed. If we go this route, we already provide a private Ajax object in phoenix.js

[paulcsmith]

link_to_if can be very useful for pagination for example <%= link_to_if @more_pages?, "next", next_page_path %> or anytime you don't want to totally remove a link, or just show that the link won't do anything (e.g. post can't be deleted if it's already been published for example). I'm not sure this is worth having a helper for, but those are some use cases.

[paulcsmith]

@chrismccord The most useful ones would be data-confirm, allowing links to make post requests (for sign out, delete, etc.) and disabling submitted forms. The disabling of submitted forms is a really handy one to prevent duplicates and to show loading states on forms.

[chrismccord]

allowing links to make post requests (for sign out, delete, etc.) and disabling submitted forms

We already support this:

    <td><%= link "Delete", to: post_path(@conn, :delete, post), method: :delete %></td>

link_to_if can be very useful for pagination for example <%= link_to_if @more_pages?, "next", next_page_path %>

Just to be clear, this is the same as <%= if @more_pages?, do: link "next", to: next_page_path(@conn) %> right?

[paulcsmith]

I didn't realize method: :delete was supported. Awesome :+1:

link_to_if is an unclear name. link_to_if in Rails will link if the condition is true, otherwise it will print the text without a surrounding anchor tag

<%= if @more_pages? do %>
  <%= link "next", to: next_page_path(@conn) %>
<% else %>
  "next"
<% end %>

[chrismccord]

@paulcsmith thanks for clarifying. 6 years of doing rails and I never knew the semantics of those methods. The if/else approach is 100x more clear imo, at the small cost of possibly duplicating the link text.

[paulcsmith]

No problem. Yeah it is a tricky method. It's useful if you remember what it does, but it's not immediately obvious.

[essenciary]

In regards to the jQuery / jQuery-less ujs - initially I was thinking too that it's better to go the jQuery-less way, but after doing a bit of research, I changed my mind considering that:

• sooner or later Phoenix will probably achieve feature parity with rails' ujs because there are useful functionalities in there (https://github.com/rails/jquery-ujs/blob/master/src/rails.js). If we start with that, we get a well tested code-base out of the box almost for free (and future updates for browser compatibility, thank you very much)
• like it or not, jQuery is ubiquitous. And implementing everything without it will actually have a boomerang effect: rather than getting a lighter JS layer, as most of the users will use jQuery anyway, they'll end up with both jQuery and the non-jQuery code for handling the same things.
• there's a thing call jqLite - is used by Google in Angular in a very smart way:
  _jqLite is a tiny, API-compatible subset of jQuery that allows Angular to manipulate the DOM in a cross-browser compatible way. jqLite implements only the most commonly needed functionality with the goal of having a very small footprint.
  If jQuery is available, angular.element is an alias for the jQuery function. If jQuery is not available, angular.element delegates to Angular's built-in subset of jQuery, called "jQuery lite" or "jqLite."_

In my opinion, the ideal approach would be to use rails' jQuery ujs but make it compatible with jqLite and use jQuery if already available (and skip loading jqLite all together).

[sorentwo]

• While Phoenix's UJS implementation may achieve feature parity it doesn't need to copy Rails wholesale, much like the rest of Phoenix. Hand picking some of the most desirable features (confirm, disable, remote) is a great place to start.
• jQuery had approached ubiquity, but that trend has been declining. It seems that the decisions made for Phoenix thus far have steered toward the simplest smallest thing that works. Some examples would be a custom Ajax wrapper or using brunch instead of an asset pipeline. Nobody who chooses to use jQuery will be effected.
• Phoenix.js is built with ES6+ (Babel) and modules. I imagine we'd want to keep that trend.

I'm fully in favor of using the API that jquery-ujs expects, wherein everything is built off of data-* attributes. If done right it would still be possible to drop in another *-ujs library and have it function the same way.

[napcs]

Just chiming in. I strongly miss link_to_unless_current. I have used that forever as it makes doing a navbar incredibly easy. I've never used link_to_if, but I can see its use as well.

[sorentwo]

Here's a list of the UJS enhancements in question, as scraped from the jquery-ujs tests:

• call-remote - AJAXify links
• csrf-refresh - Refresh the CSRF token remotely (not sure about this one)
• csrf-token - Inject the CSRF token into forms automatically
• data-confirm - Use a confirmation dialogue to prompt before an action
• data-disable - Disable a form button to prevent duplicate submission
• data-disable-with - Disable a form button with a message
• data-method - Support DELETE, POST, etc. (Already supported, at least partially)
• data-remote - AJAXify forms

[scrogson]

Before anyone goes porting stuff...take a look at this: https://github.com/hauleth/vanilla-ujs

[sorentwo]

@scrogson: Awesome find.

[josevalim]

Folks, I am closing this. If someone wants to tackle ujs, it will be very welcome. I am not sure how it would fit within Phoenix, even more with the Phoenix HTML project being extracted in the future but it is definitely something people are looking for.

link_to_if and friends are also welcome additions but it is worth discussing their APIs. For example, in order to calculate the current path, we need the connection but we don't currently receive it. So we need to discuss how those new functions will look like. Please open up a separate issue for those if interested.

Thank you!