Jshint: Los parámetros regulares no deben ir después de los parámetros predeterminados

Este mensaje se implementó originalmente como un "error" JSHint (lo que significa que podría
no se debe ignorar): gh-1779. Si bien puede haber sido un SyntaxError en algunos primeros
borrador, no se finalizó de esa manera, por lo que en gh-2543, "rebajamos" el
mensaje a una advertencia. Esto significa que _may_ ignorarlo en JSHint 2.9.1 a través de
-W138 .

Dicho esto, no está claro si esta advertencia es apropiada en absoluto. I
personalmente creo que las funciones diseñadas de esta manera son difíciles de usar, pero
No puedo identificar ningún problema potencial de seguridad del código.

@rwaldron @caitp ¿

Solo quiero mencionar que este tipo de firma es parte de las muestras de código redux. Busque la línea:

function counter(state = 0, action) {

entonces, es ampliamente utilizado, en mi humilde opinión.

Este tipo de patrón es _absolutamente_ la definición de "pelusa".

entonces, es ampliamente utilizado, en mi humilde opinión.

Estoy totalmente en desacuerdo con la implicación de que un patrón que aparece en redux sea indicativo de algo "ampliamente utilizado". Miré a través de redux y encontré ejemplos de counter(undefined, action) y me pregunto cuál podría ser el punto de esto, considerando que cada uno de ellos en realidad _requiere_ el argumento action , o enfrenta un tiempo de ejecución error. Si action es _siempre_ obligatorio y state es opcional, ¿por qué requieren llamadas que deben pasar explícitamente undefined Eso contradice el propósito de los valores de parámetros predeterminados .

... Estoy tentado a presentar un error.

Dicho esto, no está claro si esta advertencia es apropiada en absoluto.

Creo que lo es, y cualquiera que no quiera la advertencia puede apagarlo.

No dudes en cerrar este @jugglinmike

@rwaldron ok, en realidad no hablamos de redux. ¿Puede proporcionar una muestra de error que pueda aparecer con dicha firma?
Para mí es solo una propiedad del lenguaje. Entonces, ¿cuál es la razón para marcarlo como "incorrecto"?

¿Puede proporcionar una muestra de error que pueda aparecer con dicha firma?

El único error de tiempo de ejecución que encontrará es llamar como: counter() y counter(undefined) , pero ese no es mi punto. Mi punto es que el diseño es terrible y supone una carga indebida para el programador y sus herramientas. Por ejemplo, un minificador podría analizar razonablemente lo siguiente:

function counter(action, state = 0) {
  return [action, state];
}
counter({});
counter({}, 0);
counter({}, undefined);

Y producir:

function c(a,s=0){return[a,s]}
c({});
c({});
c({});

Considerando que, poniendo el valor predeterminado primero:

function counter(state = 0, action) {
  return [state, action];
}
counter(0, {});
counter(undefined, {});

produciría:

function c(s=0,a){return[s,a]}
c(0, {});
c(undefined, {});

Ese es un ejemplo bastante elaborado, pero aún ilustra mi punto de que hace que el uso de un parámetro predeterminado sea completamente inútil.

Para mí es solo una propiedad del lenguaje.

Solo porque puedas, no significa que debas hacerlo.

Entonces, en este momento no puede explicar por qué es un mal diseño, excepto preocuparse por los errores en los minificadores.

Exigir que todos los sitios de llamadas pasen un undefined explícito, en aras de eludir una firma de llamada mal diseñada, se considera una mala práctica y un uso incorrecto de los parámetros predeterminados.

React / Redux fomenta este comportamiento. Es más probable que elimine jshint que eliminar React / Redux: /

http://redux.js.org/docs/basics/Reducers.html

Un buen truco es usar la sintaxis de argumentos predeterminada de ES6 para escribir esto de una manera más compacta:

función todoApp (estado = estado inicial, acción) {
// Por ahora, no manejes ninguna acción
// y simplemente devuélvenos el estado que nos dieron.
estado de retorno
}

@jugglinmike wdyt ^^?

@txm ¿qué sucede con el parámetro action que nunca se usa?

Sigo siendo de la opinión de que en ausencia de un peligro tangible (e incluso en
presencia de patrones que de otro modo serían indeseables), JSHint debe permanecer en silencio.
Dicho esto, tengo problemas para entender cómo el ejemplo de @txm es distinto.

¿Cómo puedo desmontarlo ...?

@thalesfsp : agregue /* jshint -W138 */ agregue el comienzo de su archivo. (Asegúrese de estar usando jshint v2.9.1 o más reciente)

Tropecé con el mismo problema con Redux. ¿Se puede desactivar en el archivo de configuración .jshintrc, por favor?

@derwaldgeist ¡Seguro! Aquí hay un ejemplo de archivo .jshintrc que silenciaría la advertencia:

{
  "esversion": 6,
  "-W138": true
}

(Por cierto, la documentación de JSHint tiene más información sobre cómo deshabilitar advertencias específicas).

@jugglinmike Gracias. No sabía que también es posible usar la sintaxis "-Wxxx" en el archivo .jshintrc. Siempre usé esto en la parte superior de un archivo. ¡Genial saber!

Dado que la 'devolución de llamada' se usa ampliamente como el último parámetro de una función, esta advertencia de pelusa me parece bastante tonta

openDialog (url, nombre, args = {}, pos) {
devolver nueva promesa (función (resolver, rechazar) {
chrome.windows.create ({
url: url,
tipo: "ventana emergente",
ancho: pos && pos.width || indefinido,
altura: pos && pos.altura || indefinido,
izquierda: pos && pos.izquierda || indefinido,
arriba: pos && pos.top || indefinido
}, función (w) {

Aparentemente, la configuración predeterminada de los otros parámetros en undefined es válida y pasa el proceso de linting. No digo que sea un patrón mejor, pero pasa el proceso de deshilachado.