Melhores práticas para envio de dados ao servidor

[sergiohampel]

Gostaria de levantar uma pequena discussão sobre a forma como vocês fazem o processo de validação dos dados antes de enviá-los para o servidor. A problemática é simples, consiste no seguinte:

Tenho a seguinte função:

function saveData(data) {}

Onde o parâmetro data é um objeto. Como vocês fariam para validar data?

Primeiro garante o sucesso da existência de data? Exemplo:

function saveData(data) {
  if (data) {
    ...envia os dados
    return;
  }

  ...trata as exceções
}

Ou trata todas as exceções antes e, por final, envia os dados?

function saveData(data) {
  if (!data) return handleErrors();

  ...envia os dados
}

Espero que essa issue gere bons depoimentos.

[munizart]

@sergiohampel isso depende muito do tipo de aplicação que você tem, mas o legal mesmo é fazer sempre o mais abstrato e customizavel possivel, pra poder reutilizar...

Vou deixar alguns pontos sobre o modo que eu gosto de trabalhar

Nunca* dar curto-circuito numa função.

 // não gosto
function saveData ( data ) {
  if (!data) {
    throw new TypeError('Expected first argument to be truthy')
  }
}

// prefiro

function saveData ( data ) {
  if (data) {
     send(data)
  } else { // mesmo quando tem um return ou throw no bloco de cima.
     throw new TypeError('Expected first argument to be truthy')
  }
}

// * exceção: callbacks error-first
function onReceive ( error, data ) {
  if (error) {
    doSomeLogging(error)
    return retry()
  } // sem else nesse caso

  render(data)
}

Criar pontos de extensibilidade

Gosto de deixar sempre uma forma de inserir comportamento sem precisar editar o código:

function saveData ( data, validator = Boolean ) {
  if (validator(data)) {
    send(data)
  } else {
     throw new TypeError('Invalid data, validator: ' + validator.name)
  }
}

saveData({ foo: 'bar' }) // OK
saveData([1, 2 ,3], Array.isArray) // OK
saveData({ foo: 'bar' }, Array.isArray) // TypeError: Invalid data, validator: isArray
saveData() // TypeError: Invalid data, validator: Boolean

Callbacks ou Promise pra tudo que possa falhar

Se a operação pode funcionar ou não, é legal saber quando deu algum erro, então em vez do famigerado throw dos exemplos anteriores o que eu realmente uso são callbacks (se precisar dar suporte pra navegador antigo) ou Promise

Maybe

Quando o importante é saber se a operação deu certo, sem se preocupar o por que da falha, uso alguma implementação do Maybe:

const M = require(/*alguma lib funcional*/).Maybe

/**
 * @param { Number } a
 * @param { Number } b
 * @returns { Maybe.<Number> }
 */
function sum(a, b) {
  return M
    .of(a)
    .fold((a) => M.of(b)
      .fold((b) => a+b))
}

Isso ajuda a não ter que ficar checando por undefined, null e NaN toda hora.
E com o Symbol.toPrimitive da pra fazer um Maybe que funcione mesmo quando usado como primitivo

Tem outras coisas que acho importante usar, como docs e linter, mas aí já fica off-topic

[kazzkiq]

@munizart fiquei curioso do porque de nunca usar curto-circuito em uma função.

Sempre tive a impressão de que o código fica mais legível desta forma, além de me parecer padrão em outras linguagens como Go, sendo que ao mesmo tempo parece ser muito pouco utilizado no JavaScript. Sabe se chega a ser considerado uma má prática?

[lucasfcosta]

@munizart acho uma boa dica, mas acredito que o termo correto não seria short-circuit, visto que short-circuit é se aproveitar de como é feito o evaluate dos operadores booleanos, por exemplo:

// Evalua myFunc apenas se data for truthy
// Já que o operador && denota que ambos devem ser truthy, não tem nenhum motivo pra evaluar o segundo termo
data && myFunc(data);

// Usa o valor default se req.body.data for falsy
const myVar = req.body.data || defaultValue

A maybe monad é de fato interessante usar pra isso também. Curto bastante o jeito que rust trata isso com as Options (te obriga a fazer pattern matching tipo o que um Maybe em uma linguagem funcional faria) lol

Sobre os pontos de extensibilidade é também uma prática útil (IMO) que vai de acordo com os bons princípios de evolutionary design & loosely coupling, ainda no exemplo que você passou eu curto bastante fazer currying em casos como esse:

⚠️ Alerta de heavy-lifting de programação funcional abaixo

const isNull = i => i === null;
const minLength3 = v => v && v.length >= 3 ? null : "Minimum length is 3"; 
const isNumber = v => !isNaN(v) ? null : "Must be a number";

// A função abaixo recebe um array de validadores: funções que retornam `null` ou uma string com erro
// Ela então retorna uma função que recebe uma função `fn`, essa função retornada é a que vamos usar para validar os valores
// A função retornada na segunda chamada recebe um valor `v` e valida-o rodando todos os validators sobre ele
// Se todos os validators forem `null` ela chama a função `fn` que você passou, caso contrário joga um erro
const withValidators = validators => {
  return fn => v => { /
    const errors = validators.map(validator => validator(v))
    const passing = errors.every(isNull);
    return passing ? fn(v) : throw new Error(errors[0])
  }
}

// Então supondo que a função `send` envia dados para o servidor:
const sendIfValid = withValidators(minLength3, isNumber)(send);

return <MyButton onClick={() => sendIfValid(data)} />

Da forma que eu mostrei acima você pode compor suas funcões e de uma forma simples e manter todas elas puras, o que facilita muito na hora de testar porque você pode testar em diferentes granularidades, tornando TDD muito mais fácil.

No caso acima você poderia testar os validators primeiro e depois testar se o enhancer withValidators de fato só chama a função passada se todos os validators retornam null.

Um bom exemplo disso pra quem usa React é o recompose.

E pra quem quiser ler mais sobre Lambda Calculus tenho escrito vários posts introdutórios no meu blog. Entender Lambda Calculus e conceitos básicos e gerais de computabilidade melhor muito sua habilidade de raciocínio e pensamento funcional.

PS: @munizart Manda um abraço pra galera da Chaordic pfv, principalmente pro Bernardo. Sdds dessa cidade e dos migos ❤️

[dougaraujos]

@lucasfcosta Obrigado pelos posts <3

[munizart]

@kazzkiq gosto de trabalhar sem "curto circuito" nas funções, por que não curto a ideia de ter um bloco de código que que poder não ser executado até o final, acho que é algo a mais pra ficar se preocupando quando leio o código.
Quando é um só no começo da função não vejo muito problema, pq geralmente é só pra lidar com erros ou alguma precondição pro resto do código, mas já acho que dificulta quando tem 3 espalhados pela função.

@lucasfcosta
Não dei uma carregada no funcional nos exemplos pra ficar mais simples, mas a mão do funcional chegou a tremer. Pode deixar que entrego o recado