¿Por qué usar una etiqueta de formulario cuando envía a través de ajax?

Pregunta filosófica:

Digamos que tengo una aplicación web que requiere javascript y un navegador moderno, por lo que la mejora progresiva no es un problema. Si mi formulario se está creando a través de javascript, y mis actualizaciones de datos se realizan a través de POST y PUT de ajax, ¿hay realmente alguna razón para envolver mis controles en una etiqueta de formulario? Si todavía voy a usar la etiqueta, digamos por razones semánticas o estructurales, ¿hay alguna razón para tener parámetros de acción y método que voy a ignorar? Para mí, se siente como un remanente de una época anterior.

Hay al menos una característica importante de la experiencia del usuario proporcionada específicamente al envolver las entradas dentro de una etiqueta de formulario:

La tecla Intro enviará el formulario. De hecho, en Mobile Safari, así es como hace que aparezca el botón "Ir" en el teclado .

Sin un formulario que envuelva las entradas, no hay nada que enviar.

Por supuesto, puede proporcionar un comportamiento de tecla de entrada a través de un evento de pulsación de tecla, pero no sé si esto funciona para dispositivos móviles. No sé ustedes, pero prefiero trabajar con la semántica proporcionada por el navegador que tener que imitarlos con eventos.

En su caso, simplemente proporcionaría un onsubmitcontrolador de eventos para el formulario, que haría su envío AJAX y luego return falsecancelaría el envío real.

Simplemente puede proporcionar action=""(que significa "propio"), y methodno es obligatorio, por defecto es GET.

Si no necesita mejoras progresivas, teóricamente no las necesita.

Por otro lado, los forms tienen algunos efectos semánticos y de agrupación interesantes . Utilizándolos, puede agrupar los elementos de su formulario de manera lógica y facilitar que sus scripts recopilen los valores de ciertos elementos.

Por ejemplo, si desea enviar alguna entrada de usuario ajax, siempre es más fácil decir: "tomemos todos los elementos en este formulario y envíelos" que decir "tomemos esta entrada, estas dos selecciones y estas tres áreas de texto y envíelos ". En mi experiencia, en realidad ayuda al desarrollador si formhay etiquetas.

AJAX es genial, pero como dijo JamWaffles (+1 para él), el uso de formetiquetas proporciona un método alternativo.

Personalmente, utilizo etiquetas de formulario, incluso para las cosas que envío con AJAX porque es sintácticamente claro y facilita la captura de todas las entradas dentro de un formulario específico. Sí, también podría hacer esto con a divo lo que sea, pero como dije, usar un formulario es sintácticamente agradable.

Por cierto, los lectores de pantalla tratan el contenido en su interior de manera formdiferente, por lo que hay problemas de accesibilidad que se deben considerar de cualquier manera que elija. Tenga en cuenta que la evidencia anecdótica sugiere que Google considera la accesibilidad en sus clasificaciones, por lo que si el SEO es una preocupación para usted, use un formulario y hágalo bien.

Resumen: formularios aceptables para MVC, aplicaciones web simples, malos para aplicaciones web ricas y orientadas a componentes.

Razón: las formas no pueden anidar otras formas: gran limitación para una arquitectura orientada a componentes.

Detalles: para las aplicaciones típicas de MVC, los formularios son excelentes. En aplicaciones web ricas y complejas que usan mucho javascript y AJAX y con muchos componentes aquí y allá, no me gustan los formularios. Razón: las formas no pueden anidar otras formas. Entonces, si cada componente representa un formulario, los componentes no se pueden anidar entre sí. Demasiado. Al cambiar todos los formularios a divs, puedo anidarlos, y siempre que quiera tomar todos los parámetros para pasarlos a ajax, simplemente lo hago (con jQuery):

$ ("# id_of_my_div"). find ("[nombre]"). serialize ();

(o algún otro filtrado)

en vez de:

$ ("# id_of_my_form"). serialize ();

Aunque, por razones sentimentales y semánticas, sigo nombrando a mis divs something_form cuando actúan como formas.

No es que yo pueda ver. Actualmente estoy construyendo una aplicación web que usa <form>s, pero los estoy usando, así que tengo un método alternativo si el usuario tiene JavaScript deshabilitado (y e.preventDefaultdetiene la publicación del formulario normalmente). Para su situación, donde está diciendo que el usuario DEBE tener JavaScript, una <form>etiqueta no es necesaria, pero podría ser una idea mantenerla de todos modos en caso de que el navegador necesite hacer algo con ella, o acceder a ella como una especie de clase.

En resumen, no, no necesita usarlo <form>si está haciendo AJAX puro, aunque dejarlo podría ser una idea si de repente decide crear un código de respaldo en el futuro.

En mi opinión: si lo usa por razones semánticas, utilícelo según lo previsto. Se requiere que el atributo de acción (también se puede dejar vacío) esté bien formado, también puede separar sus URI-s de su lógica js, configurando el atributo de acción y leyéndolo antes de la llamada ajax.

No veo por qué necesitaría usar la etiqueta de formulario aquí. La única razón para usar una etiqueta de formulario (además de obtener su marcado para validar) es si va a hacer que el usuario "envíe" los datos usando una entrada sumbit o una etiqueta de botón. Si no necesita hacer eso, entonces no es necesario el formulario. Sin embargo, no estoy seguro de si se considerará un marcado "válido". Si lo usa, puede hacerlo, <form action="">ya que la acción es el único atributo requerido de la etiqueta del formulario. Sin embargo, plantea un buen punto, el futuro de las aplicaciones web probablemente ya no necesitará el formulario y la metodología de envío tradicional. Muy interesante y me hace feliz. jeje :)