DEV Community: Marco Damaceno

Another way to search for an element in an array in JavaScript

Marco Damaceno — Thu, 17 Sep 2020 18:47:41 +0000

Is this useful for you?

function funnelSearch(arr, target, x = 0) {
  if (!arr.length) return;

  if (arr.length === 1 && arr[0] === target) {
    return target;
  }

  const left = arr[x];
  const right = arr[arr.length - x - 1];

  if (left === target || right === target) {
    return target;
  }

  if (x > (arr.length / 2)) return;

  return funnelSearch(arr, target, x + 1);
}

const numbers = [1,2,3,4,5,6,7,8,10];

console.log(funnelSearch(numbers, 1)); // 1
console.log(funnelSearch(numbers, 5)); // 5
console.log(funnelSearch(numbers, 0)); // undefined
console.log(funnelSearch('Marco Damaceno', 'D')); // D

Honestly, I don't know the name of this technique.

It starts from index 0 AND from the last one incrementing the first index and decrementing the last index. And so on until it finds the element. If it does not find, returns undefined. It takes half time to go through all the elements than a usual that starts from index 0 to the last one.

I named it funnelSearch, because I didn't find anything like it documented on the web. Maybe, I didn't use the right words on my searches. BinarySearch?

If this technique has a known name, please, let me know.

PS: It also works for strings.

Sem necessidade de framework Javascript

Marco Damaceno — Sat, 25 Apr 2020 15:46:18 +0000

Frameworks Javascript como React (sim, um framework), Vue e Angular auxiliam bastante no desenvolvimento de aplicações web. Um ecossistema foi gerado em torno de cada um deles e o que se vê hoje em dia é uma comunidade Javascript fragmentada que praticamente não se conversa.

Como fazer um componente escrito pra funcionar no React também funcionar no Angular? Ou no Vue? Algumas horas e um pouco de dor de cabeça serão necessárias para fazer funcionar essa compatibilidade. Para piorar as coisas, se vê mais pessoas entrando na área de desenvolvimento como "Desenvolvedor React" ou "Desenvolvedor Angular" e por aí vai. Isso só ajuda a fragmentar ainda mais a comunidade Javascript.

A solução para este problema - se é que foi desenvolvido para ser uma solução - são os chamados WebComponents. É o elo perdido entre os ditos frameworks. Pouco se comenta sobre eles em cada uma das comunidades. Já parou para se perguntar por quê? É simples. Seus mantenedores querem que outros desenvolvedores usem a ferramenta que eles criaram como a solução para "escrever menos código". Os criadores possuem produtos que usam a tal ferramenta, o que justifica a sua existência. Essas ferramentas sendo adotadas em massa, ajudam as empresas que as mantem (Google, Facebook e AliExpress*) sempre com pessoas dispostas a resolverem bugs para elas. Não que isso seja um problema já que o desenvolvedor que não trabalha nessas empresas está adquirindo conhecimento da mesma forma, mas pouco se vê uma discussão sobre como resolver um problema utilizando Vanilla JS. É sempre "como fazer/resolver x com react/angular/vue". Soluções boas são criadas no clubinho e não se vê muito movimento de torná-los compatíveis com outros frameworks. No final, é tudo Javascript #soquenao.

* AliExpress mantém o Vue indiretamente.

Poucos perceberam que esses frameworks surgiram para resolver um problema que hoje é perfeitamente possível resolver sem eles.

Enquanto isso...

Mais uma vaga "Desenvolvedor React" é criada no Linkedin.
Outra vaga "Desenvolvedor Angular" é criada no Linkedin.
Vagas como "Desenvolvedor Javascript" estão sumindo...

Ainda tem aqueles desenvolvedores que utilizam React pra tudo. Às vezes, um simples site com uma única interação possível a pessoa já considera usar React e Redux. Vai com calma, cidadão! Nem tudo é prego pra você usar o seu martelo.

"WebComponents é difícil de ler e manter."

Pode até ser verdade, mas você já parou pra analisar opções que facilitam o desenvolvimento com WebComponents? Já ouviu falar do lit-html, LitElement e haunted?

Eu tentando contribuir para maior adoção dos WebComponents, criei um repositório chamado Don't need a framework onde a ideia é reunir exemplos de como resolver certos problemas corriqueiros com WebComponents. Anunciei o projeto num grupo do Slack e alguém me fez essa pergunta:

"Não usar React, mas usar uma lib (haunted) que simula uma funcionalidade do React?"

É, meu caro. Mais um motivo da não necessidade de React ou qualquer outro framework.

E quem disse que a tal funcionalidade é exclusiva do React? Já parou pra ver o código fonte da biblioteca? Não achei nenhuma implementação do React nela. Se achar, por favor, me avise.

Se você ainda não sabe, existe uma hashtag chamada #usetheplatform que basicamente advoga sobre o uso da plataforma web do jeito que ela é para desenvolvimento de aplicações. Hoje é perfeitamente possível manter um projeto só com WebComponents aproveitando o modelo evergreen de atualização que navegadores utilizam. Se você não pode se dar ao luxo de fazer uma aplicação sem pensar em navegadores antigos, há as soluções de builders que ajudam nessa questão como Webpack, Rollup ou Parcel.

"Existem frameworks para outras linguagens. Por que seria diferente pro Javascript?"

Ainda não percebeu que o navegador é o framework? Qual a necessidade de um framework do framework?

"Eu não sei se o navegador suporta o que eu quero fazer..."

O site Can I use pode te informar se você pode usar a nova feature motherf****r do js ou não.

Eu tenho a impressão que os fãs de React são os primeiros a darem chilique quando se fala de WebComponents. Isso se confirma? Se sim, por quê? Qual é a birra?

Os anos vão passando e o seu framework favorito vai se tornando cada vez mais irrelevante com o avanço do Javascript.

"Mas é o framework x que paga minhas contas!"

Sério? Até quando?

404 status code! Really?

Marco Damaceno — Mon, 09 Mar 2020 17:47:21 +0000

Hi, guys! This is my first post on Dev.to.

I come to share with you a thought that intrigues me a little. Maybe, a little strange one at first sight.

Well... I have built a REST API for a personal project and worked on a endpoint that retrives a single resource. For instance:

GET /books/8c2ba535-5523-47a5-8a72-281c316d5fc4

As you can see, the resource can be found by an UUID. This URI is mapped as GET /books/:id.

The thing is this UUID does not represent any record in the books table in the database. So, it returns nothing.

It is common to deal with this situation returning a 404 (not_found) status code that indicates an error from the client as specified on RFC 7231 section 6.5.4

The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists.

I have dealt with it as an untouchable law until reading what is specified on RFC 7231 section 6.3.1:

The 200 (OK) status code indicates that the request has succeeded. The payload sent in a 200 response depends on the request method. For the methods defined by this specification, the intended meaning of the payload can be summarized as:
GET a representation of the target resource;

This definition for 200 status code makes me believe that returning a payload with null is correct because it is what exactly the client requested! The client just sent an ID that does not represent any record, the structure of the URI is fine though. Thus, the client gets a success response, but with a null as a resource.

According to this logic, the payload would be like:

{
  "data": {
    "book": null
  }
}

For the status code to be 404, the request would be like:

GET /boocs/8c2ba535-5523-47a5-8a72-281c316d5fc4

boocs really does not exist.

All of this makes me think the way we handle this situation depends on how we deal with the role of the database in the application.

Does the database have an active participation on the application interfering in the business rule? Go for 404 status code. Eg.: a private repository hosted on Github being accessed by an unauthorized user.

Is the database just a data repository? I tend to believe the response would have a success payload with null. Eg.: the majority of the APIs worldwide.

Summing up:

"If you have nothing to give, give nothing. If you do, decide if you want to give something, (don't) give it and communicate."

Crazy, uh?

I know there already are some talks about this on the internet, but I think it worths sharing my thoughts with you and I'd like to know about your opinion.

What do you think about?