Uma visão contrária da imutabilidade
TL / DR: a imutabilidade é mais uma tendência da moda do que uma necessidade em JavaScript. Se você estiver usando o React, ele fornecerá uma solução clara para algumas opções de design confusas no gerenciamento de estado. No entanto, na maioria das outras situações, ele não agrega valor suficiente à complexidade que apresenta, servindo mais para suprir um currículo do que para atender às necessidades reais do cliente.
Resposta longa: leia abaixo.
Por que a imutabilidade é tão importante (ou necessária) em javascript?
Bem, estou feliz que você pediu!
Algum tempo atrás, um cara muito talentoso chamado Dan Abramov escreveu uma biblioteca de gerenciamento de estado javascript chamada Redux, que usa funções puras e imutabilidade. Ele também fez alguns vídeos muito legais que tornaram a idéia muito fácil de entender (e vender).
O momento foi perfeito. A novidade do Angular estava desaparecendo, e o mundo JavaScript estava pronto para se fixar na coisa mais recente que tinha o grau certo de legal, e essa biblioteca não era apenas inovadora, mas também se encaixava perfeitamente com o React, que estava sendo vendido por outra potência do Vale do Silício .
Por mais triste que seja, as modas dominam o mundo do JavaScript. Agora Abramov está sendo saudado como um semideus e todos nós, meros mortais, devemos nos sujeitar ao Dao da Imutabilidade ... Se faz sentido ou não.
O que há de errado na mutação de objetos?
Nada!
De fato, os programadores estão mudando objetos por er ... desde que haja objetos para mudar. Mais de 50 anos de desenvolvimento de aplicativos, em outras palavras.
E por que complicar as coisas? Quando você tem um objeto cat
e ele morre, você realmente precisa de um segundo cat
para acompanhar a mudança? A maioria das pessoas apenas diz cat.isDead = true
e acaba com isso.
(Objetos mutantes) não simplificam as coisas?
SIM! .. Claro que sim!
Especialmente em JavaScript, que na prática é mais útil usado para renderizar uma exibição de algum estado que é mantido em outro local (como em um banco de dados).
E se eu tiver um novo objeto de Notícias que precise ser atualizado? ... Como faço para alcançar neste caso? Excluir a loja e recriá-la? Adicionar um objeto à matriz não é uma operação mais barata?
Bem, você pode seguir a abordagem tradicional e atualizar o News
objeto, para que sua representação na memória desse objeto seja alterada (e a exibição exibida para o usuário, ou o que se esperaria) ...
Ou alternativamente...
Você pode tentar a abordagem FP / Imutabilidade sexy e adicionar suas alterações ao News
objeto em uma matriz que rastreia todas as alterações históricas para que você possa percorrer a matriz e descobrir qual deve ser a representação correta do estado (ufa!).
Estou tentando aprender o que é certo aqui. Por favor, me esclareça :)
A moda vem e vai amigo. Existem muitas maneiras de esticar um gato.
Lamento que você tenha que suportar a confusão de um conjunto de paradigmas de programação em constante mudança. Mas ei, BEM-VINDO AO CLUBE !!
Agora, alguns pontos importantes a serem lembrados no que diz respeito à imutabilidade, e você os jogará com a intensidade febril que apenas a ingenuidade pode reunir.
1) A imutabilidade é incrível para evitar as condições de corrida em ambientes multithread .
Ambientes multithread (como C ++, Java e C #) são culpados da prática de bloquear objetos quando mais de um thread deseja alterá-los. Isso é ruim para o desempenho, mas melhor do que a alternativa de corrupção de dados. E, no entanto, não é tão bom quanto tornar tudo imutável (Deus louve Haskell!).
MAS ALAS! Em JavaScript, você sempre opera em um único encadeamento . Até trabalhadores da Web (cada um é executado em um contexto separado ). Portanto, como você não pode ter uma condição de corrida relacionada ao encadeamento dentro do seu contexto de execução (todas essas adoráveis variáveis e fechamentos globais), o principal ponto a favor da Imutabilidade sai pela janela.
(Dito isto, não é uma vantagem de usar funções puras em trabalhadores da web, o que é que você vai ter nenhuma expectativa sobre a brincar com objetos no segmento principal.)
2) A imutabilidade pode (de alguma forma) evitar as condições de corrida no estado do seu aplicativo.
E aqui está o verdadeiro cerne da questão, a maioria dos desenvolvedores do (React) dirá que o Immutability e o FP podem de alguma forma trabalhar essa mágica que permite que o estado do seu aplicativo se torne previsível.
Obviamente, isso não significa que você pode evitar as condições de corrida no banco de dados . Para isso, você teria que coordenar todos os usuários em todos os navegadores e, para isso, precisaria de uma tecnologia de back-end como o WebSockets ( mais sobre isso abaixo) que transmitirá as alterações para todos que executam o aplicativo.
Também não significa que exista algum problema inerente no JavaScript em que o estado do aplicativo precise de imutabilidade para se tornar previsível, qualquer desenvolvedor que codifique aplicativos de front-end antes que o React lhe diga isso.
Essa afirmação bastante confusa significa simplesmente que, com o React, o estado do seu aplicativo se tornará mais propenso a condições de corrida , mas essa imutabilidade permite que você remova essa dor. Por quê? Como o React é especial .. foi projetado como uma biblioteca de renderização altamente otimizada, com o gerenciamento de estado coerente em segundo lugar e, portanto, o estado do componente é gerenciado por meio de uma cadeia de eventos assíncrona (também conhecida como "ligação de dados unidirecional") que você não tem controle e confie em você lembrando de não mudar o estado diretamente ...
Diante desse contexto, é fácil ver como a necessidade de imutabilidade tem pouco a ver com JavaScript e muito a ver com as condições de corrida no React: se houver várias alterações interdependentes em seu aplicativo e nenhuma maneira fácil de descobrir o que seu estado está atualmente, você ficará confuso e, portanto , faz todo o sentido usar a imutabilidade para rastrear todas as mudanças históricas .
3) As condições da corrida são categoricamente ruins.
Bem, eles podem ser se você estiver usando o React. Mas eles são raros se você escolher uma estrutura diferente.
Além disso, você normalmente tem problemas muito maiores para lidar com problemas como o inferno da dependência. Como uma base de código inchada. Como se seu CSS não estivesse sendo carregado. Como um processo de construção lento ou ficar preso a um back-end monolítico que torna a iteração quase impossível. Como desenvolvedores inexperientes, não entendendo o que está acontecendo e fazendo uma bagunça nas coisas.
Você sabe. Realidade. Mas ei, quem se importa com isso?
4) A imutabilidade utiliza os tipos de referência para reduzir o impacto no desempenho do rastreamento de todas as alterações de estado.
Porque, sério, se você deseja copiar coisas toda vez que seu estado muda, é melhor ter certeza de que é inteligente.
5) Imutabilidade permite desfazer coisas .
Porque er .. esse é o recurso número um que seu gerente de projetos solicitará, certo?
6) O estado imutável tem muito potencial interessante em combinação com WebSockets
Por último, mas não menos importante, a acumulação de deltas de estado é um caso bastante atraente em combinação com o WebSockets, que permite um fácil consumo de estado como um fluxo de eventos imutáveis ...
Uma vez que o centavo cai nesse conceito (o estado é um fluxo de eventos - em vez de um conjunto bruto de registros representando a visão mais recente), o mundo imutável se torna um lugar mágico para habitar. Uma terra de maravilhas e possibilidades originadas por eventos que transcendem o próprio tempo . E quando bem feito este pode definitivamente fazer em tempo real aplicativos easi er para realizar, basta transmitir o fluxo de eventos a todos os interessados para que eles possam construir a sua própria representação do presente e escrever de volta suas próprias mudanças no fluxo comum.
Mas em algum momento você acorda e percebe que toda essa maravilha e magia não são de graça. Ao contrário de seus colegas ansiosos, seus stakeholders (sim, as pessoas que pagam a você) se importam pouco com filosofia ou moda e muito com o dinheiro que pagam para construir um produto que possam vender. E a conclusão é que é mais difícil escrever código imutável e mais fácil quebrá-lo, além de haver pouco sentido em ter um front-end imutável se você não tiver um back-end para suportá-lo. Quando (e se!) Você finalmente convence suas partes interessadas de que deve publicar e consumir eventos por meio de uma tecnologia push como o WebSockets, você descobre que sofrimento é escalar na produção .
Agora, para alguns conselhos, você deve aceitar.
Uma opção para escrever JavaScript usando FP / Immutability também é uma opção para tornar a base de código do seu aplicativo maior, mais complexa e mais difícil de gerenciar. Eu diria enfaticamente para limitar essa abordagem para seus redutores Redux, se você não sabe o que está fazendo ... e se você estiver indo para ir em frente e uso imutabilidade independentemente, em seguida, aplicar estado imutável em sua pilha de aplicativos inteira , e não apenas o do lado do cliente, caso contrário você perderá o valor real.
Agora, se você tiver a sorte de poder fazer escolhas em seu trabalho, tente usar sua sabedoria (ou não) e faça o que é certo pela pessoa que está lhe pagando . Você pode basear isso na sua experiência, no seu instinto ou no que está acontecendo ao seu redor (é certo que, se todos estiverem usando o React / Redux, existe um argumento válido de que será mais fácil encontrar um recurso para continuar seu trabalho). você pode tentar as abordagens Resume Driven Development ou Hype Driven Development . Eles podem ser mais o seu tipo de coisa.
Em suma, o que se pode dizer da imutabilidade é que isso fará com que você fique na moda com seus colegas, pelo menos até a próxima mania, e nesse ponto você ficará feliz em seguir em frente.
Agora, após esta sessão de autoterapia, gostaria de salientar que adicionei isso como um artigo no meu blog => Imutabilidade em JavaScript: uma visão contrária . Sinta-se à vontade para responder lá, se você tiver sentimentos fortes, também gostaria de sair do seu peito;).