Benefícios de ter uma nova ação discreta?

O método do controlador, estritamente falando, não é realmente necessário, mas sua principal vantagem é que ele coloca a lógica em um lugar claro e coerente.

A visualização é inerentemente confusa, pois é uma combinação de marcação e código e deve realmente se preocupar apenas em transformar os dados fornecidos em HTML da maneira mais direta possível. Instanciar ou consultar esses dados deve ser responsabilidade do controlador.

Essa separação de preocupações se torna mais importante conforme o nível de complexidade cresce. Mas, ao realmente tomar o caminho um pouco mais longo, você evita ter que reescrever o código quando a complexidade cresce.

Além das questões conceituais, também há razões práticas diretas pelas quais essa <%= form_with model: Link.new do |form| %>não é uma prática muito boa:

• Limita desnecessariamente o potencial de reutilização do código. Se você passar a instância do modelo para a visualização, o mesmo código pode ser facilmente usado para criar e atualizar.
• Você não está vinculando a entrada do usuário à instância do modelo, então qualquer coisa que o usuário digitar será perdida em um envio de formulário malsucedido. Isso não é muito legal.
• Não é assim que os andaimes funcionam e, portanto, é surpreendente.

Embora você possa lidar com isso na visualização com:

<%= form_with model: @link || Link.new do |form| %>
    # ...
<% end %>

Isso está colocando a lógica em uma visão onde ela não pertence.

É para ter uma rota separada, que cria o formulário, quando invocada?

Na verdade não, já que isso é possível de qualquer maneira.

Mesmo que você não tenha uma ação de controlador correspondente, o Action Rails procurará implicitamente por uma visualização e a renderizará.

Trata-se mais de separar as preocupações de uma forma que se adapte bem à complexidade e que outros desenvolvedores Rails esperam.

É para ter uma rota separada, que cria o formulário, quando invocada?

Essencialmente — sim. Se o cliente tiver conhecimento de que tipo de solicitação fazer, ele apenas faz uma solicitação diretamente para createa ação e passa os parâmetros corretos. O exemplo seria você testando createvia curlna linha de comando, ou um cliente REST fazendo as solicitações (outro programador lê os documentos e sabe o que enviar no corpo da solicitação — nenhuma newchamada necessária).

O navegador é um tipo “especial” de cliente, e ele precisa chamar newpara poder mostrar um formulário ao seu usuário. Eles fazem escolhas com base nos widgets do formulário (digitam coisas em entradas de texto, selecionam opções de selects/radio/checkboxes) e então clicam em submit, o que termina como um POST que aterrissa na createação.

A Link.newparte não está comunicando ao seu aplicativo que você está criando um novo objeto. Ele é usado pelo form_withhelper e tenta buscar dados para mostrar no seu formulário. (Ele também usa o nome do modelo para descobrir quais devem ser os nomes dos campos, no seu exemplo os campos seriam link[attribute_name]). Então passar um objeto (mesmo um vazio, como Link.new) é necessário para que o framework descubra todos os detalhes de que precisa para renderizar o formulário corretamente. E um formulário renderizado corretamente significa executar corretamente a solicitação POST no envio.

Geralmente, o fato de você estar criando um novo objeto é comunicado pelo fato de não haver idcampo. Verifique seus formulários de edição e veja se há um idcampo oculto ali, ou se está na URL de ação do formulário.

Para melhor entendimento Link.newem seu formulário, faça alguns experimentos. Por exemplo, você pode fazer form_with model: Link.new(foo: "default value")e do formulário renderizado tentaria mostrar o campo :fooque teria um “valor padrão” definido. Ou você pode fazer SomeDifferentModel.newe comparar o formulário HTML resultante.