Digamos que tengo una función en una vista que se activa cuando se cambia algún tipo de estado. ¿Cuál sería el mejor nombre y por qué?Mejor práctica de Backbone.js para manejadores de eventos nombrando
Estoy personalmente perefer utilizar onEventName nombres de mantenimiento de convención de nomenclatura nativo para los controladores de eventos DOM.
Me gusta myElement.onclick = function() { /* ... */ } para click evento.
Así que para myEvent estoy usando controlador denominado onMyEvent.
Y si tengo evento stateChange, entonces voy a utilizar onStateChange manejador.
Pero realmente esta pregunta es más específica para cada equipo de desarrolladores y convenciones de estilo de código dentro del equipo/compañía.
El objetivo principal en este tipo de preguntas es mantener el estilo del código igual en todas las partes para garantizar la legibilidad.
Por lo tanto, si trabajas en equipo, mantente adherido a las convenciones de escritura de código del equipo y si trabajas solo con el código existente, intenta mantener su estilo de código (seguro si ese estilo no es obviamente feo) .
ACTUALIZACIÓN: Comprensión.
¿Qué es el evento? Aproximadamente es una acción iniciada fuera o dentro del programa, en otras palabras, algo sucede en el sistema, p. algunos cambios de estado (el estado del teclado, del mouse, de dispositivos de E/S, etc.) no importa cómo (el usuario hizo clic en el mouse o algún programa envió la señal de clic del mouse al sistema).
Digamos que la ventana del navegador está suscrita para recibir notificaciones sobre algunos eventos y el sistema operativo los envía a ellos lo antes posible, supondremos que al mismo tiempo cuando sucede algo. Por lo tanto, si el usuario hace clic en el mouse cuando la ventana del navegador está activa y el documento tiene un foco, el navegador indica que se debe disparar el evento click. Y aquí nuestro controlador onclick inicia su invocación. En otras palabras, el sistema nos dice que ahora ocurre un cambio de algún estado. Y estamos manejando este cambio y no estamos manejando un hecho diciéndonos que el estado ha sido cambiado.
Supongamos que nuestro controlador tiene el nombre onClicked. Como el nombre del controlador dice en tiempo pasado, podemos hacernos una pregunta razonable: "Cuando se hace clic, ¿cuánto tiempo pasó? ¿Cuántas veces se hizo clic? Mmm, tal vez sea demasiado tarde para manejar esta acción (¿o acciones?) ... ". Entonces este nombre nos dice que algo sucedió en el pasado.
Por el contrario, cuando nuestro controlador denominado como onClick es obvio que click caso solo disparó y disparó una vez y fue notificado de ello inmediatamente. Y vamos a mango caso clic - la información nos dice que el estado de ratón cambia en este momento (no ratón hace clic , pero el caso de clic).
Por lo tanto, los nombres en tiempo pasado son más apropiados para los casos en que necesitamos verificar si algún estado ha sido modificado o no. P.ej. si la variable almacena el state = 1 podemos llamar a la función isStateChanged(); que comparará el valor en la variable state con el valor real en el momento actual. Y aquí el tiempo pasado es una buena opción para nombrar.
onStateChanged porque esta función se dispara siempre que se cambia una especie de estado.
Esta respuesta es muy parcial y basada en la opinión. Lo cual está bien, si está pidiendo una opinión. Sin embargo, creo que OP deseaba conocer la convención o las mejores prácticas más que la opinión. Recomiendo la respuesta http://stackoverflow.com/a/11990334/545296 por @ eugene-naydenov – therealklanni
Mi apuesta es para stateChanged por:
stateChange se parece a una orden, y parece que recibe un parámetro con el nuevo estado .onStateChange y onStateChanged son más las teclas para almacenar los controladores, no el nombre del manejador.mi humilde opinión
Este es el método que he estado usando también. 'something.onStateChange = function stateChanged() {/ * maneja el cambio en estado * /};' para "on-". Al pasar un parámetro de devolución de llamada a '.live (' o '.click (', prefiero '.click (función handleClick() {/ * do stuff * /}'. – conny
Normalmente selecciono un nombre de evento de 2 factores. A medida que una aplicación crece de tamaño, es posible que tenga más de un objeto con cambios de estado o quizás un controlador que pueda transmitir eventos de cambio para más de un objeto y por lo tanto quiera diferenciar entre ambos en el código y en su cabeza:
Object1:event
Object2:event
En cuanto a qué nombre de evento, creo que se reduce a la preferencia personal y la coherencia.
Busqué en Google algunos nombres y anoté la cantidad de resultados devueltos. Usted puede obtener una idea de la popularidad relativa de las formas más comunes para los controladores de eventos:
stateChanged 168k
stateChange 81k [1]
handleStateChange 61k
onStateChange 59k
onStateChanged 12k
beforeStateChange 2k
[1] Los resultados muestran stateChange utiliza sobre todo como el nombre de un evento, no un controlador.
El uso de diferentes tipos de eventos da una recomendación mucho más fuerte hacia la forma onStateChange:
change [2]
onChange 2000k
onChanged 85k
handleChange 36k
beforeChange 27k
afterChange 22k
click [2]
onClick 48000k
onClicked 58k
handleClick 50k
beforeClick 8k [3]
onDrag 100k
handleDrag 36k
beforeDrag 32k
afterDrag 4k
onDragged 5k
[2] Demasiados resultados no relacionados con la programación.
[3] Al parecer, ciertas API de Microsoft pueden anticipar cuándo el usuario va a hacer clic.
En cuanto al subtexto [3], no es que el se anticipa que lo que está haciendo es pasar el evento a cualquier manejador que se pueda adjuntar y darle al desarrollador la oportunidad de modificar los datos del evento de alguna manera (tal vez evitar que el evento continúe o modifique el comportamiento predeterminado). Muchos frameworks hacen lo mismo. – therealklanni
Estaba tratando de hacer una broma, pero gracias de todos modos – SharkAlley
Este no es realmente el lugar para hacer bromas. Alguien claramente lo tomará al pie de la letra. Dejé el comentario para asegurarme cualquiera que lea su respuesta no se confundiría debido a su declaración. – therealklanni
Creo que uno debe marcar la diferencia en función del momento real en el que la acción está ocurriendo.Para mí, onStateChange significa que actualmente está cambiando y puedo recibir una notificación sobre esto técnicamente hablando, justo antes del cambio. OnStateChanged significa que la acción ya ocurrió y me notifican al final.
Por lo tanto, entre onStateChange y onStateChanged hay una diferencia de intención importante. Primero dice "prepárese para este cambio" mientras que el segundo dice "ya ha sucedido".
Editar: Me dejé llevar por la intención y no me di cuenta de la denominación en sí. ¿Por qué el prefijo on? Esto está reservado para los controladores. Los manejadores harán algo relacionado con (en) ese evento. Así que iría con stateChange y stateChanged.
¿Hay algo en particular que impida que esta pregunta se denomine "_JavaScript_ best practice for event handler naming"? – conny