tipos - retornar valor de una funcion javascript

La mejor manera de determinar si un argumento no se envía a la función de JavaScript

Question

Ahora he visto 2 métodos para determinar si un argumento se ha pasado a una función de JavaScript. Me pregunto si un método es mejor que el otro o si uno es malo de usar.

 function Test(argument1, argument2) {
      if (Test.arguments.length == 1) argument2 = ''blah'';

      alert(argument2);
 }

 Test(''test'');

O

 function Test(argument1, argument2) {
      argument2 = argument2 || ''blah'';

      alert(argument2);
 }

 Test(''test'');

Por lo que puedo decir, ambos tienen el mismo resultado, pero solo he usado el primero antes en la producción.

Otra opción mencionada por Tom :

function Test(argument1, argument2) {
    if(argument2 === null) {
        argument2 = ''blah'';
    }

    alert(argument2);
}

Según el comentario de Juan, sería mejor cambiar la sugerencia de Tom a:

function Test(argument1, argument2) {
    if(argument2 === undefined) {
        argument2 = ''blah'';
    }

    alert(argument2);
}

Answer 1

¿Por qué no usar el !! ¿operador? Este operador, colocado antes de la variable, lo convierte en un booleano (si lo he entendido bien), así que !!undefined y !!null (e incluso !!NaN , que puede ser bastante interesante) devolverá el valor false .

Aquí hay un ejemplo:

function foo(bar){
    console.log(!!bar);
}

foo("hey") //=> will log true

foo() //=> will log false

Answer 2

En ES6 (ES2015) puedes usar parámetros predeterminados

function Test(arg1 = ''Hello'', arg2 = ''World!''){
  alert(arg1 + '' '' +arg2);
}

Test(''Hello'', ''World!''); // Hello World!
Test(''Hello''); // Hello World!
Test(); // Hello World!

Answer 3

Es posible que algunas veces también desee verificar el tipo, especialmente si está utilizando la función como getter y setter. El siguiente código es ES6 (no se ejecutará en EcmaScript 5 o más antiguo):

class PrivateTest {
    constructor(aNumber) {
        let _aNumber = aNumber;

        //Privileged setter/getter with access to private _number:
        this.aNumber = function(value) {
            if (value !== undefined && (typeof value === typeof _aNumber)) {
                _aNumber = value;
            }
            else {
                return _aNumber;
            }
        }
    }
}

Answer 4

Este es uno de los pocos casos donde encuentro la prueba:

if(! argument2) {  

}

Funciona bastante bien y lleva la implicación correcta sintácticamente.

(Con la restricción simultánea, no permitiría un valor nulo legítimo para argument2 que tenga algún otro significado; pero eso sería realmente confuso).

EDITAR:

Este es un muy buen ejemplo de una diferencia estilística entre los lenguajes de tipo débil y los de tipo fuerte; y una opción estilística que javascript ofrece en espadas.

Mi preferencia personal (sin críticas para otras preferencias) es el minimalismo. Cuanto menos tenga que decir el código, mientras sea coherente y conciso, menos tendrá que comprender otra persona para inferir correctamente mi significado.

Una implicación de esa preferencia es que no quiero (no me parece útil) acumular un montón de pruebas de dependencia de tipo. En su lugar, trato de hacer que el código signifique lo que parece que significa; y prueba solo para lo que realmente necesito probar.

Una de las agravaciones que encuentro en el código de otras personas es la necesidad de averiguar si esperan o no, en el contexto más amplio, encontrarse con los casos que están probando. O si están intentando probar todo lo posible, con la posibilidad de que no anticipen el contexto lo suficiente. Lo que significa que termino necesitando rastrearlos exhaustivamente en ambas direcciones antes de poder refactorizar o modificar cualquier cosa con confianza. Me imagino que hay una buena probabilidad de que hayan realizado esas diversas pruebas porque previeron las circunstancias en las que serían necesarias (y que, por lo general, no son evidentes para mí).

(Considero que un serio inconveniente en la forma en que estas personas utilizan lenguajes dinámicos. Muy a menudo las personas no quieren abandonar todas las pruebas estáticas y terminan fingiendo).

He visto esto de manera más evidente al comparar el código completo de ActionScript 3 con el elegante código javascript. El AS3 puede ser 3 o 4 veces mayor que el js, y la confiabilidad que sospecho no es mejor, solo por el número (3-4X) de decisiones de codificación que se tomaron.

Como dices, Shog9, YMMV. :RE

Answer 5

Hay diferencias significativas. Vamos a configurar algunos casos de prueba:

var unused; // value will be undefined
Test("test1", "some value");
Test("test2");
Test("test3", unused);
Test("test4", null);
Test("test5", 0);
Test("test6", "");

Con el primer método que describe, solo la segunda prueba usará el valor predeterminado. El segundo método predeterminará todos menos el primero (ya que JS convertirá undefined , null , 0 y "" en false booleano. Y si tuviera que usar el método de Tom, ¡solo la cuarta prueba usará el predeterminado!

El método que elija realmente depende de su comportamiento previsto. Si se permiten valores distintos de undefined para argument2 , entonces probablemente querrá alguna variación en el primero; si se desea un valor no nulo, no nulo, no vacío, entonces el segundo método es ideal; de hecho, a menudo se usa para eliminar rápidamente un rango tan amplio de valores.

Answer 6

Hay varias formas diferentes de verificar si un argumento se pasó a una función. Además de los dos que mencionó en su pregunta (original), verifique los arguments.length largo o use el || operador para proporcionar valores predeterminados: uno también puede verificar explícitamente los argumentos para undefined través de argument2 === undefined o typeof argument2 === ''undefined'' si uno es paranoico (ver comentarios).

Usando el || el operador se ha convertido en una práctica estándar; todos los niños geniales lo hacen, pero tenga cuidado: el valor predeterminado se activará si el argumento se evalúa como false , lo que significa que en realidad podría estar undefined , null , false , 0 , '''' (o cualquier otra cosa para lo que Boolean(...) devuelve false ).

Así que la pregunta es cuándo usar qué cheque, ya que todos producen resultados ligeramente diferentes.

La verificación de los arguments.length muestra el comportamiento ''más correcto'', pero puede que no sea factible si hay más de un argumento opcional.

La prueba para undefined es la siguiente "mejor": solo "falla" si la función se llama explícitamente con un valor undefined , que probablemente debería tratarse de la misma manera que omitiendo el argumento.

El uso de la || el operador puede activar el uso del valor predeterminado incluso si se proporciona un argumento válido. Por otro lado, su comportamiento podría ser deseado.

Para resumir: ¡Úsalo solo si sabes lo que estás haciendo!

En mi opinión, utilizando || También es el camino a seguir si hay más de un argumento opcional y uno no quiere pasar un objeto literal como solución para los parámetros nombrados.

Otra forma agradable de proporcionar valores predeterminados con los arguments.length es posible al pasar por las etiquetas de una instrucción switch:

function test(requiredArg, optionalArg1, optionalArg2, optionalArg3) {
    switch(arguments.length) {
        case 1: optionalArg1 = ''default1'';
        case 2: optionalArg2 = ''default2'';
        case 3: optionalArg3 = ''default3'';
        case 4: break;
        default: throw new Error(''illegal argument count'')
    }
    // do stuff
}

Esto tiene el inconveniente de que la intención del programador no es (visualmente) obvia y utiliza "números mágicos"; por lo tanto, es posiblemente propenso a errores.

Answer 7

Lo siento, todavía no puedo comentar, así que para responder a la respuesta de Tom ... En javascript (undefined! = Null) == false De hecho, esa función no funciona con "null", debe usar "undefined"

Answer 8

Puede ser conveniente abordar la detección de argumentos al evocar su función con un Objeto de propiedades opcionales:

function foo(options) {
    var config = { // defaults
        list: ''string value'',
        of: [a, b, c],
        optional: {x: y},
        objects: function(param){
           // do stuff here
        }
    }; 
    if(options !== undefined){
        for (i in config) {
            if (config.hasOwnProperty(i)){
                if (options[i] !== undefined) { config[i] = options[i]; }
            }
        }
    }
}

Answer 9

Si está usando jQuery, una opción que está bien (especialmente para situaciones complicadas) es usar el método de extensión de jQuery .

function foo(options) {

    default_options = {
        timeout : 1000,
        callback : function(){},
        some_number : 50,
        some_text : "hello world"
    };

    options = $.extend({}, default_options, options);
}

Si llamas a la función entonces así:

foo({timeout : 500});

La variable de opciones sería entonces:

{
    timeout : 500,
    callback : function(){},
    some_number : 50,
    some_text : "hello world"
};

Answer 10

También hay una manera difícil de encontrar si un parámetro se pasa a una función o no . Echa un vistazo al siguiente ejemplo:

this.setCurrent = function(value) {
  this.current = value || 0;
};

Esto es necesario significa que si el valor del value no está presente / pasado, ajústelo a 0.

Muy bien eh!

Answer 11

fnCalledFunction (Param1, Param2, window.YourOptionalParameter)

Si se llama a la función anterior desde muchos lugares y está seguro de que los primeros 2 parámetros se pasan desde todos los lugares, pero no está seguro acerca del tercer parámetro, entonces puede usar la ventana.

window.param3 manejará si no está definido desde el método del llamador.

Answer 12

url = url === undefined ? location.href : url;