
<a href="#english">English version below</a>

Negli ultimi anni ho formulato la stessa domanda in varie forme, rivolgendola a nessuno, a me stesso, ad amici.
La domanda assume diverse forme, ma la più semplice, sebbene soggetta a interpretazioni, potrebbe essere la seguente:

**Possiamo ideare un test che dimostri se esista o meno qualcosa che l'essere umano non può pensare?**

Immagino che questa questione sollevi molte incertezze. Cosa si intende per "pensare"? Prima di immergerci nella discussione, potremmo fare alcuni esempi per complicare ulteriormente la questione. Prendiamo un cane affettuoso e intelligente, ad esempio un labrador. Questo cane è in grado di comprendere richiami verbali, espressioni facciali e, anche in assenza di comandi diretti, può dedurre dal contesto ciò che sta accadendo. Ora supponiamo di voler insegnare al cane a fare somme. Forse, con qualche artificio, riusciremmo ad insegnargli a fare piccole somme. Ma se volessimo insegnargli a risolvere equazioni di secondo grado o a distinguere tra ironia e sarcasmo? O ancora, a mettere in atto una strategia per essere promosso nella scuola dei cani guida per ciechi. Immagino che troveremmo qualcosa che, anche avendo a disposizione un cane immortale e tempo infinito, il cane non potrebbe mai comprendere. Non perché non sia in grado di farlo, ma perché non può **concepirlo** (un sinonimo del **pensare** di cui sopra).

Non so se l'esempio abbia semplificato la domanda o l'abbia resa più complessa. Ora cercherò di delineare con maggior chiarezza il problema. Supponiamo di incontrare una razza aliena che manifesti un comportamento sconosciuto per noi. Tale comportamento è il risultato di un'emozione che noi non proviamo, ma che possiamo descrivere come un misto di paura e sorpresa e che ha effetti particolari sulla fisiologia di questi esseri. Anche se non siamo in grado di sperimentare questa emozione, abbiamo tutti gli strumenti per descriverla e comprendere i suoi effetti. Riusciamo a concepirla; quindi, un'emozione del genere non dovrebbe essere annoverata tra le cose che non possiamo pensare. Vale a dire, la capacità di sperimentare qualcosa non la rende impensabile. Senza dover ricorrere a esseri alieni, possiamo affermare lo stesso anche per il concetto di infinito e argomenti simili.

È importante notare che se esistesse qualcosa che l'essere umano non può pensare, non saremmo neanche in grado di descriverla, definirne i contorni o studiarla. Proprio come un cane non potrebbe descrivere l'empatia. Pertanto, la mia domanda non è se esista qualcosa che non possiamo pensare, ma piuttosto se possiamo dedurre l'esistenza o meno di tale categoria di cose, indipendentemente da cosa essa sia. Ipoteticamente, sarebbe interessante comprendere se possiamo mettere in atto un ragionamento logico o un test empirico che dimostri che tale categoria di cose esista o non esista, poiché **l'intelligenza** umana è universale e può comprendere tutto. Un'altra formulazione della domanda potrebbe essere: **l'intelletto umano è universale?**

Se consideriamo il pensiero umano e le cose pensabili come un sistema, vogliamo capire se, dall'interno del sistema, possiamo dedurre che il sistema è limitato, se ha confini e, eventualmente, se esista qualcosa al di fuori di tali confini. Se qualcosa esistesse al di fuori di questo sistema, saremmo certi che non potremmo mai sapere cosa sia. Potremmo solo sapere che esiste, ma non sapremmo quanto sia grande l'insieme delle cose impensabili.

Intuitivamente, potremmo essere inclini a credere che tale insieme esista, che non ci siano ragioni per credere che il nostro intelletto sia universale, ma la congettura va dimostrata. Diamo per un attimo per scontato che il nostro intelletto non sia universale e che l'insieme di cose pensabili sia limitato (forse infinito ma comunque limitato). In questo contesto, avrebbe senso chiedersi se esista un modo per capire se tale limite esista o meno. In altre parole, possiamo creare un meta-ragionamento che capisca l'esterno del sistema dal suo interno? Io credo che ciò non debba essere escluso. L'intelletto umano non è un sistema formale per cui sappiamo già che questo è possibile, ma nonostante ciò, credo sia legittimo quantomeno tentare.

Quale forma dovrebbe avere questo test? Nonostante ci abbia riflettuto, non sono in grado di proporre una risposta. Verosimilmente potrebbe essere un test di carattere logico: supporre che tale insieme di inconcepibilità esista e dimostrare, ad esempio, che sarebbe una contraddizione logica o viceversa. Ma a questo punto sorge la domanda: e se tale sistema esistesse al di fuori della nostra logica? Così, la domanda si ripresenta sotto un'altra veste: **la logica di cui siamo capaci è universale?**
L'universo è regolato soltanto dalla nostra logica? Qualcosa ci sfugge? Se esistesse un'altra logica, per esempio in un universo alternativo, la nostra intelligenza sarebbe completa soltanto se fosse possibile descrivere questo universo e questa logica. Se esistesse semplicemente un universo in cui un'altra logica regolasse gli eventi, non potremmo dire che esiste qualcosa al di fuori del nostro concepibile se fossimo in grado di osservarla e descriverla.

Più la domanda viene formulata e sviscerata, più sembra che non abbia senso. Questo è decisamente un risultato possibile, **la domanda in sé è priva di senso**. Sarebbe interessante parlare anche di questa eventualità, ma la lasciamo da parte per ora solo per portare la discussione su un binario secondario.

Dimentichiamo per un attimo l'idea di voler creare il test di cui abbiamo parlato e diamo per scontato che esista un insieme di concetti inconcepibili per l'essere umano. Non importa quali, e non è nemmeno necessario dimostrarne con certezza l'esistenza. Poiché questi concetti possono avere effetti sull'universo che ci circonda, è possibile che abbiamo avuto a che fare con tali effetti?

L'immagine che vorrei proporre è quella di una bolla non trasparente. Noi vediamo questa sfera; mentre rotola, ha effetti sulle nostre vite che possiamo vedere. Piega i fili d'erba quando vi passa sopra, e dobbiamo spostarci per farla passare. Nonostante i suoi effetti siano molto visibili, noi possiamo solo vedere l'esterno, solo i suoi confini. Non sappiamo e non potremo mai sapere cosa c'è all'interno. Nel tentativo di descriverne il perimetro, saremmo limitati perché dovremmo fare congetture sul suo contenuto per spiegarne i contorni, senza mai poter essere precisi. A questo punto sorge una domanda interessante: **abbiamo incontrato qualcosa che somiglia a quanto descritto?**  
Abbiamo osservato qualche bolla e ci siamo accontentati di descriverne i confini? Forse ci siamo persino convinti che i confini siano tutto ciò di cui è fatta la bolla? Io credo di sì, ritengo che abbiamo alcuni buoni candidati.

Un esempio potrebbe essere il concetto di "causa prima". La domanda "perché esiste l'universo invece di non esistere". Ci sono chiaramente molte risposte apparenti a questa domanda, alcune di carattere trascendentale (dio, il tutto), altre meno metafisiche. Il punto è che non abbiamo una risposta a questa domanda. Forse stiamo osservando i confini della bolla? Il problema non è quale sia la risposta corretta, ma semplicemente che non possiamo pensare la risposta corretta? Potremmo stare osservando il perimetro dell'insieme delle cose impensabili?

Mi scuso se vi lascio, come ho iniziato, con un'altra domanda.

---

<h3 id="english">English version (automatic translation)</h3>

In recent years, I have posed the same question in various forms, addressing it to no one, to myself, to friends.
The question takes on various forms, but the simplest, though subject to interpretation, might be the following:

**Can we devise a test that demonstrates whether something exists that the human being cannot think?**

I imagine that this question raises many uncertainties. What is meant by "thinking"? Before delving into the discussion, we could provide some examples to further complicate the issue. Let's take an affectionate and intelligent dog, for example, a Labrador. This dog can understand verbal cues, facial expressions, and even in the absence of direct commands, can deduce from the context what is happening. Now, suppose we want to teach the dog to do additions. Perhaps, with some artifice, we could teach it to do small sums. But if we wanted to teach it to solve quadratic equations or distinguish between irony and sarcasm? Or even implement a strategy to be promoted to the guide dog school for the blind. I imagine we would find something that, even with an immortal dog and infinite time, the dog could never comprehend. Not because it can't do it, but because it cannot **conceive** it (a synonym for the **thinking** mentioned above).

I don't know if the example has simplified the question or made it more complex. Now I will try to outline the problem more clearly. Suppose we encounter an alien race that exhibits behavior unknown to us. This behavior results from an emotion we do not experience, but we can describe it as a mixture of fear and surprise and has particular effects on the physiology of these beings. Even though we are unable to experience this emotion, we have all the tools to describe it and understand its effects. We can conceive it; therefore, such an emotion should not be counted among things we cannot think. In other words, the ability to experience something does not make that something unthinkable. Without resorting to alien beings, we can say the same for the concept of infinity and similar topics.

It is important to note that if there were something the human being cannot think, we would not even be able to describe it, define its contours, or study it. Just like a dog cannot describe empathy. Therefore, my question is not whether something exists that we cannot think, but rather whether we can deduce the existence or non-existence of such a category of things, regardless of what it is. Hypothetically, it would be interesting to understand if we can implement logical reasoning or an empirical test that proves that such a category of things exists or not because **human intelligence** is universal and can comprehend everything. Another formulation of the question might be: **Is human intellect universal?**

If we consider human thought and thinkable things as a system, we want to understand if, from within the system, we can deduce that the system is limited, if it has boundaries, and eventually, if there is something outside of those boundaries. If something existed outside of this system, we would be certain that we could never know what it is. We could only know that it exists, but we would not know how vast the set of unthinkable things is.

Intuitively, we might be inclined to believe that such a set exists, that there is no reason to believe that our intellect is universal, but the conjecture needs to be proven. Let's assume for a moment that our intellect is not universal and that the set of thinkable things is limited (perhaps infinite but limited). In this context, would it make sense to ask whether there is a way to understand whether this limit exists or not? In other words, can we create a meta-reasoning that includes the outside of the system from within? I believe that this is not to be excluded. Human intellect is not a formal system, so we already know that this is possible. However, despite this, I think it is legitimate to at least try.

What form should this test take? Despite thinking about it, I cannot even propose an answer. Likely, it could be a logical test: assume that such a set of inconceivability exists and demonstrate, for example, that it would be a logical contradiction or vice versa. But at this point, the question arises: what if this system existed outside of our logic? Thus, the question reappears in another form: **Is the logic we are capable of, universal?**
Is the universe governed solely by our logic? Is something escaping us? If another logic existed, for example, in an alternative universe, our intelligence would be complete only if this universe and this logic were describable. If there were simply a universe where another logic governed events, we could not say that there is something outside our conceivable if only we were able to observe and describe it.

The more the question is formulated and dissected, the more it seems to make no sense. This is definitely a possible result, **the question itself is meaningless**. It would be interesting to talk about this possibility too, but we leave it aside for now just to bring the discussion onto a small secondary track.

Let's forget for a moment about wanting to create the test we talked about, and let's take for granted that there is a set of concepts inconceivable for humans. No matter which ones, and it is not even necessary to prove with certainty that they exist. Since these concepts can have effects in the universe around us, is it possible that we have dealt with such effects?

The image I would like to propose is that of an opaque bubble. We see this sphere; as it rolls, it has effects on our lives that we can see. It bends the blades of grass when it passes over them; we have to move to let it pass. Despite its effects being very visible, we can only see its exterior, only its boundaries. We do not know and will never know what is inside. In describing its perimeter, we would also be limited because we would have to make conjectures about its content to explain its contours without ever being able to be precise. At this point, an interesting question arises: **Have we encountered something resembling what was described?**
Have we observed some bubble and contented ourselves with describing its contours? Perhaps we have even convinced ourselves that the contours are all that makes up the bubble? I believe so, that we have some good candidates.

An example could be the concept of "first cause." The question "why does the universe exist instead of not existing?" There are clearly many apparent answers to this question, some transcendental (God, the whole), others less metaphysical. The point is that we do not have an answer to this question. Perhaps we are observing the contours of the bubble? The problem is not what the correct answer is but simply that we cannot think the correct answer? Could we be looking at the perimeter of the set of unthinkable things?

I apologize if I leave you, as I started, with another question.


The question


<a href="#english"><small>English version below</small></a>

Tempo fa un amico ha condiviso un certo video con me. Ogni tanto chiacchieriamo, come tanti, di cose che ci affascinano e lui è sempre più incline di me a farsi prendere da misteri, teorie alternative, soprattutto se ammantate da pseudo credibilità.

Credo che meglio di me, e in maniera più concisa, ne abbiano scritto nella magnifica [teoria della montagna di merda](https://urielfanelli.altervista.org/keinpfusch/la-teoria-della-montagna-di-merda/2010-03-26/).

Il video in questione lo trovate su [youtube](https://www.youtube.com/watch?v=mGgG327Fjdk). Non aspettatevi niente di interessante. La mia email di seguito:

---

Beh, visto che ho un po' di tempo ecco il mio pensiero non solo sul video che mi hai mandato, ma forse più in generale su questo genere di approcci.
Se la vuoi fatta breve in generale credo ci sia un problema di onestà intellettuale e di professionalità.
Se vuoi la versione lunga andiamo con ordine. Ho visto il video e ho ascoltato le tesi del tizio in questione. In pratica per farla breve lui dice che alcuni salti evolutivi dell'uomo sono inspiegabili, altri sembrano non avere senso (premessa) e quindi l'evoluzione dell'uomo non ha seguito un percorso "naturale" (tesi) o qualcos altro è vi è coinvolto.
Ci sono anche parecchi sotto testi, uno che ho sentito riprendere anche a te: c'è del non detto, la scienza ufficiale (lasciami usare questa espressione) non sa spiegare o pretende che l'unica verità sia la sua. A proposito di questo riporto delle parole tue: "...tanti interrogativi ai quali non si sa dare risposta e vengono annacquati in una presunzione di conoscenza oramai data per acquisita".
Vorrei entrare nel merito delle cose che il tizio ha detto, ma prima c'è una cosa che mi fa un solletico insopportabile e allora fammene parlare subito. C'è questa convinzione che il mondo accademico non abbia saputo rispondere a delle cose e abbia deciso di accontentarsi di una lacunosa versione ufficiale. Che ostenti sicurezza su argomenti del tutto poco chiari e che proponga questa sicurezza come l'unica verità. Io non so da dove viene questo pensiero che vedo molto diffuso, ma la mia esperienza è del tutto diversa. Io non ho mai visto questo atteggiamento nel mondo accademico (in larga maggioranza). Mi spiego subito ma prima fammi fare un piccolo distinguo: non sto parlando né di religione né di filosofia. Della prima non parlo perché la professione della religione è inventarsi una verità, non cercarla. Della filosofia non parlo perché è letteralmente il mondo dello scontro delle idee. Li le idee si raffinano, non indicano necessariamente una verità. Ma tu hai indicato altri campi nel tuo messaggio che invece fanno al caso nostro: biologia, geologia, archeologia...

Facciamo che io ti dico come ho sempre percepito questi settori. Poniamo che vi sia un caso ambiguo, una roccia che non dovrebbe essere dove si trova, una costruzione non in linea con il resto delle costruzioni del suo tempo, un animale che si trova dove non dovrebbe. A me pare che di solito queste discipline si approccino a queste cose facendo ipotesi e poi mettendole in discussione. "Sull'argomento X fin adesso la migliore ipotesi che abbiamo è questa", ma non ne sono sicuri. Non c'è quest'ostentazione di sicurezza di cui si parla. Ci sono ipotesi. Tutto è un ipotesi. Alcune hanno funzionato così bene e per così tanto tempo che la fiducia di tutti nei loro confronti è altissima. Ma rimangono ipotesi, modelli, teorie. Abbiamo ribaltato certezze che hanno tenuto banco per secoli. Abbiamo 2 o più teorie contrastanti sullo stesso argomento che convivono, che si mettono in gioco finché una emergerà o saranno soppiantate da una terza. Il mondo accademico che conosco io si comporta così ormai da secoli. È da Galileo in poi che abbiamo questo atteggiamento. Più o meno, s'intende.
È sempre così? No. Siamo sempre persone, si fa fatica ad accettare il nuovo, ad abbandonare il vecchio. A volte ci sono questioni di vanità, altre di soldi.
Ho esempi di vanità che hanno ucciso migliaia di bambini. Esempi di cecità selettiva che hanno avvelenato milioni di persone. Queste cose capitano e capiteranno, ma non è l'atteggiamento comune. In generale l'umanità che fa ricerca seriamente è storicamente pronta a fare passi avanti e difficilmente lascia che i dogmi resistano per sempre.
Di nuovo devo ribadire che gli inciampi sono parecchi, soprattutto se ci sono di mezzo soldi. La ricerca sui vaccini è stata guidata dai soldi. Magari qualche ricercatore che vive di stipendio l'ha fatto per lo spirito di ricerca, ma le aziende lo hanno fatto per profitto.

Su queste cose qui sopra ho discusso con T. che ha un punto di vista interessante e non affatto sbagliato, ma non voglio dilungarmi troppo.

Vediamo come tutto questo che ti ho detto si rapporta al video che hai condiviso. E fammelo fare proponendoti un'angolazione diversa. Mettiamo che io faccia un video in cui ti dico che le volte romane non possono stare in piedi. È impossibile che i romani avessero le capacità di fare quegli archi lì. Qualcosa di particolare ha mandato in avanti il loro sviluppo tecnologico ma l'architettura mainstream non ci tiene a porsi questi interrogativi. Ti suona scemo? Lo è. E lo sai cos'è scemo? Non tanto che io creda che i romani avessero fatto qualcosa di straordinario, ma che lo spieghi con qualcosa non dimostrabile (il salto tecnologico misterioso). Se io credo che i romani abbiano inventato degli archi strepitosi, se sono uno storico, architetto, archeologo, sarà mio piacere studiare, fare ipotesi, verificarle, dibatterle con gli altri.
Questa è la disonestà intellettuale di cui ti parlo. Appena qualcuno rimanda tutto a cose inspiegabili, quantomeno dimostra di non avere voglia di cercare di capire, vuole solo prendere una scenica scorciatoia. Il tizio del video nello specifico dice alcune cose di cui anche io so che sono minchiate, nel senso di falsità (esempi dopo), e altre di cui io non so niente ma se mi dici che sono inspiegabili, che ce le tengono nascoste o cose del genere, allora io capisco molto su di te, non sulle teorie.

Vabbè, smetto di essere generico. Cose di cui io sono a conoscenza seppure non sia un biologo e le abbia sempre studiate per passione:

- Siamo gli unici del genere homo. Si, adesso. Fino a qualche migliaio di anni fa condividevamo la terra con l'uomo di Neanderthal. Poi li abbiamo massacrati.
- Non possiamo generare figli con altre specie e nomina le scimmie. No, con le scimmie no, siamo molto distanti. Con Neanderthal potevamo e la prole era fertile (a differenza di muli e bardotti per intenderci ma mi sono informato e non ne siamo sicuri. Ancora una volta l'umiltà della scienza mainstream). In queste settimane hanno studiato che la popolazione della Lombardia era particolarmente sensibile al covid per l'alta presenza di geni provenienti dai Neanderthal nella popolazione locale.
- Siamo gli unici essere viventi che non possono partorire senza aiuto. Avevo T. accanto e mi ha detto "togli queste stronzate". Non è chiaramente vero. Però se vuoi sapere cose simpatiche, siamo la specie con la più alta probabilità di parti mortali, per via della dimensione del cranio, che mi ricordo aver studiato essere correlata allo sviluppo evolutivo della postura eretta.

Ma credimi, qui i dettagli non sono importanti. Importante è che se una cosa non quadra, se una teoria sembra stiracchiata, c'è abbastanza spazio di manovra nello studio e nella ricerca, senza spingersi nelle ipotesi non verificabili.

Ti dico l'ultima cosa che trovo interessante, poi basta, ho scritto troppo. Ho sempre trovato stupefacente come cose molto complesse sono inspiegabili se si guarda solo il punto di partenza e di arrivo. TI faccio alcuni esempi banali: il pane come lo abbiamo inventato? Bisogna coltivare tantissime piante di grano che non sono molto utili di suo, prendere solo alcune sue parti (non facilmente separabili), capire che si può fare la farina, che con l'acqua viene fuori un impasto che col fuoco diventa commestibile. Visto così sembra assurdo, impossibile, qualcuno deve avercelo detto (poi mi domanderei chi lo ha detto a loro). Se invece si capisce che le cose avvengono con un certo grado, con ripetuti tentativi, raffinamenti, nel corso di secoli...allora non sembra poi così strano.
A me una volta è capitato di arrovellarmi su una cosa del mio settore che mi pareva inspiegabile: l'invenzione dell'elettronica. L'elettronica si sviluppa agli inizi del 900, nel giro di vent'anni. Mi sembrava troppo rapido. Avevamo da poco scoperto come sfruttare l'elettricità, che avevamo comunque osservato in natura. L'elettronica è tutt'altra cosa però. Si tratta sempre di elettricità che passa da qualche parte ma servono quelli che si chiamano semi conduttori. I semi conduttori, a differenza dei conduttori (rame, ferro, oro, zinco, etc) sono difficilissimi da produrre. I materiali di cui sono fatti non sono abbastanza puri in natura, bisogna sottoporli ad un processo industriale chiamato "drogaggio dei semiconduttori". Mi meravigliava come avessimo potuto gettare le basi di questa disciplina in appena vent'anni, agli inizi del 900. Anche io scherzavo e dicevo che ce l'avevano suggerita gli alieni. Naturalmente il tarlo mi è rimasto e poi leggendo svariate cose ti rendi conto come questo risultato si sia reso possibile mettendo insieme tanti piccoli passi, fatti da persone differenti nel corso di tutto il secolo precedente. Che avevamo capito le basi, ma chi ci aveva provato non aveva chiaramente maestria nell'arte del drogaggio. Insomma, una volta visto tutto nel suo insieme, non era poi così stupefacente. Ma se guardi solo il punto di partenza e l'arrivo...allora è magia.

---

Alcune delle cose che ho scritto potrebbero non essere esatte. È questo il punto.

<h3 id="english">English version</h3>

**This version is autogenerated with GPT**

Some time ago, a friend shared a certain video with me. Occasionally, like many others, we chat about things that fascinate us, and he is always more inclined than I am to get caught up in mysteries, alternative theories, especially if they are shrouded in pseudo-credibility.

I believe that the magnificent [theory of the mountain of shit](https://urielfanelli.altervista.org/keinpfusch/la-teoria-della-montagna-di-merda/2010-03-26/) has expressed it better than me, and in a more concise manner.

You can find the video in question on [YouTube](https://www.youtube.com/watch?v=mGgG327Fjdk). Don't expect anything interesting. Here's my email response:

---

Well, since I have some time, here are my thoughts not only on the video you sent me but perhaps more generally on this kind of approach. In short, I think there is a problem of intellectual honesty and professionalism in general.

If you want the long version, let's go in order. I watched the video and listened to the arguments of the guy in question. In short, he says that some evolutionary leaps of man are inexplicable, others seem to make no sense (premise), and therefore human evolution did not follow a "natural" path (thesis), or something else is involved.

There are also many subtexts, one of which I heard you mention: there is the unsaid, official science (let me use this expression) cannot explain or insists that its truth is the only truth. Regarding this, I quote your words: "...many questions to which we do not have an answer and are diluted in a presumption of knowledge now taken for granted."

I would like to delve into the things the guy said, but first, there's something that bothers me, so let me talk about it right away. There is this belief that the academic world has failed to answer some things and has decided to settle for a patchy official version. That it pretends to be confident about entirely unclear topics and presents this confidence as the only truth. I don't know where this widespread thought comes from, but my experience is entirely different. I have never seen this attitude in the academic world (for the most part). Let me explain right away, but first let me make a small distinction: I am not talking about religion or philosophy. I don't talk about the former because the profession of religion is to invent a truth, not to seek it. I don't talk about philosophy because it is literally the world of the clash of ideas. There, ideas refine, not necessarily indicating a truth. But you mentioned other fields in your message that are relevant to us: biology, geology, archaeology...

Let me tell you how I have always perceived these fields. Suppose there is an ambiguous case, a rock that shouldn't be where it is, a construction not in line with the rest of the constructions of its time, an animal that is where it shouldn't be. It seems to me that these disciplines usually approach these things by making hypotheses and then questioning them. "On topic X, until now, the best hypothesis we have is this," but they are not sure. There is no ostentation of certainty as mentioned. There are hypotheses. Everything is a hypothesis. Some have worked so well and for so long that everyone's trust in them is very high. But they remain hypotheses, models, theories. We have overturned certainties that held sway for centuries. We have two or more conflicting theories on the same topic coexisting, putting them to the test until one emerges or they are supplanted by a third. The academic world I know has behaved like this for centuries now. It has been since Galileo onwards. More or less, you understand.

Is it always like this? No. We are still people; it is hard to accept the new, to abandon the old. Sometimes there are issues of vanity, other times of money.

I have examples of vanity that have killed thousands of children. Examples of selective blindness that have poisoned millions of people. These things happen and will happen, but it is not the common attitude. In general, humanity seriously engaged in research has historically been ready to take steps forward and hardly lets dogmas persist forever.

Again, I must emphasize that there are many stumbling blocks, especially when money is involved. Vaccine research has been driven by money. Perhaps some researcher who lives on a salary did it for the spirit of research, but companies did it for profit.

On these things above, I have discussed with T., who has an interesting and by no means wrong point of view, but I don't want to dwell too much.

Let's see how all this I told you relates to the video you shared. Let me do it by proposing a different angle. Suppose I make a video in which I tell you that Roman arches cannot stand. It is impossible that the Romans had the ability to make those arches. Something special propelled their technological development forward, but mainstream architecture does not want to ask these questions. Does it sound silly to you? It is. And you know what's silly? Not so much that I believe the Romans did something extraordinary, but that I explain it with something unprovable (the mysterious technological leap). If I believe that the Romans invented amazing arches, if I am a historian, architect, archaeologist, it will be my pleasure to study, make hypotheses, verify them, debate them with others.

This is the intellectual dishonesty I'm talking about. As soon as someone attributes everything to inexplicable things, at least it shows a lack of desire to try to understand; they just want to take a scenic shortcut. The guy in the video specifically says some things that even I know are nonsense, in the sense of falsehood (examples below), and others that I know nothing about, but if you tell me they are inexplicable, that they are being hidden from us or something like that, then I understand a lot about you, not about the theories.

Okay, I'll stop being generic. Things of which I am aware, even though I am not a biologist and have always studied them out of passion:

- We are the only ones of the Homo genus. Yes, now. Until a few thousand years ago, we shared the earth with Neanderthals. Then we massacred them.
- We cannot produce offspring with other species, and he mentions monkeys. No, not with monkeys, we are very distant. With Neanderthals, we could, and the offspring was fertile (unlike mules and hinnies, for example, but I have researched, and we are not sure. Once again, the humility of mainstream science). In recent weeks, they studied that the population of Lombardy was particularly sensitive to COVID due to the high presence of Neanderthal genes in the local population.
- We are the only living beings that cannot give birth without assistance. I had T. next to me, and he said, "remove this nonsense." It is clearly not true. But if you want to know funny things, we are the species with the highest probability of deadly births due to the size of the skull, which I remember studying to be related to the evolutionary development of an upright posture.

But believe me, the details are not important here. What is important is that if something doesn't add up, if a theory seems stretched, there is enough room for maneuver in study and research without venturing into unverifiable hypotheses.

I'll tell you the last thing I find interesting, and then enough, I've written too much. I've always found it amazing how very complex things are inexplicable if you only look at the starting and ending points. Let me give you some banal examples: how did we invent bread? We have to cultivate many wheat plants that are not very useful on their own, take only some parts of it (not easily separable), understand that flour can be made, that an dough comes out with water, and it becomes edible with fire. Seen like this, it seems absurd, impossible; someone must have told them (then I would wonder who told them). If, on the other hand, you understand that things happen with a certain degree, with repeated attempts, refinements, over centuries... then it doesn't seem so strange. Once I agonized over something in my field that seemed inexplicable to me: the invention of electronics. Electronics develops in the early 1900s, within twenty years. It seemed too fast to me. We had recently discovered how to harness electricity, which we had nevertheless observed in nature. Electronics is a completely different thing. It always involves electricity passing somewhere, but semiconductors are needed. Semiconductors, unlike conductors (copper, iron, gold, zinc, etc.), are extremely difficult to produce. The materials they are made of are not pure enough in nature; they must undergo an industrial process called "semiconductor doping." I was amazed at how we could lay the foundations of this discipline in just twenty years, at the beginning of the 1900s. I joked too and said that the aliens suggested it to us. Of course, the worm stayed with me, and then reading various things, you realize how this result became possible by putting together many small steps, taken by different people over the course of the previous century. That we had understood the basics, but those who had tried did not clearly master the art of doping. In short, once you see everything as a whole, it wasn't so astonishing. But if you only look at the starting and ending points... then it's magic.

---

Some of the things I wrote may not be accurate. That's the point.


Allora è magia!


Recently a new (quite useless) debate arose on Twitter. Our fellows developer have been called to decide what they prefer when using git: merge or rebase.

As usual, people are divided between supporters of one or the other, saying bad things about the opposite.
Actually, git rebase looks like a misunderstood tool and many people stated that their git repository
is usually damaged when they use git rebase. What surprised me a lot is that also very seasoned developers
and conference rock stars said that they cannot use git rebase. This confirms one of my greatest biases in our
community: people don't know git. Not their fault probably, but this is it.
The reason why they usually have no problem with git merge is that usually you can use it without having a clear idea of what's happening and a very complicated mess, easily obtainable with git merge, still results in a working repository.

In this post, I don't want to explain the difference between the two or how git rebase works, for that you have plenty
of tutorials and even the official git guide is great. What I'm going to tell you, instead, is the flow I use when working with git.
Since it mainly involves git rebase, I hope at the end you'll have a clearer idea of its mechanism.

## The goal

When I work on a repository I'd like the history to look in a certain way:

- Each commit should represent a single feature
- When a feature branch is closed, it should end up in the main branch as a single commit
- My history should look like a straight line
- All the above regardless of how many people work on the project

This is an example

![An example of a clean git repository](/assets/blog/git-rebase/gitexample.png)

I know, this above shows the commits of a single person but trust me, it's the same for a repository with tens of developers.

## Feature branches

Whenever a new feature has to be developed, we create a new feature branch. This doesn't change if you use git merge or rebase.
Eventually, the branch is going to be populated with several commits.

![A feature branch with two commits](/assets/blog/git-rebase/featurebranch.png)

As you can see from the image, while you're working on it, the main branch may have advanced. This is important to consider

## Rebase to integrate recent updates

The first usage for git rebase, is to keep your feature branch up to date with the changes in the main branch.
Sometimes you want to see how your feature behaves if it includes all the other changes your team introduced and, also,
you don't want to lose all the commits in your branch. The "easiest" solution here is to run
`git merge main`. This is easy, but it's dirty! What you'd prefer is to rewrite your history like you're answering this important
question: "How would my work, my feature branch, look like if I'd start to work on it today". In git words,
can I rewrite the history like if my feature branch is based on the current main and not on the old main, the one available when started?

To answer this question, you can run `git rebase main` while in your branch. You may be called to solve several
conflicts, after all, the main branch may have touched files you have touched too.

![Rebase your feature branch](/assets/blog/git-rebase/rebase-feature-branch.webp)

This is the image many people propose to you when they want to explain git rebase.

To avoid too many conflicts, I can only suggest avoiding long-living branches. Though, there's another
way to avoid conflicts and we'll talk about it in a while.

## Completing your feature branch

When your feature is over, you want to integrate it into the main branch. At this point what I do is rewrite the history as if my entire branch is composed of only one commit. This is where rebase shines. One of the underestimated powers of rebase is the ability to completely rewrite the history. So, what we have to do is to rewrite history to collapse all our commits into one only. Let's consider this branch.

![A branch to rewrite](/assets/blog/git-rebase/rewritehistory.png)

First of all, we want to collapse the history into one commit. The command we want to use is

`git rebase -i 68a2ca7c`

Let's see what this means

- `-i` mean `interactive`. Here it's where the magic happens
- `68a2ca7c` is the commit, in the main branch, on which our feature branch is based

If you run this command you'll get an interactive text editor

![Interactive rewrite](/assets/blog/git-rebase/historyeditor.png)

As you can see this is your branch history. You can change this text to update all of your commits.
On top, is the most recent commit, and on the bottom is the oldest. You can collapse one or more commits into another by changing `pick` with `fixup` or `squash` (or the abbreviations `f` and `s`). The difference is that with fixup the commit messages are lost,
and with squash are kept. I usually use squash and this is the result

![All squashed](/assets/blog/git-rebase/squashed.png)

If you now close the editor, the history will look like this

![After rewriting history](/assets/blog/git-rebase/afterrebasei.png)

Ok, our work is now collapsed in one commit only, great. This will come in handy if we want to revert because it's definitely easier to revert one commit only instead of several.

Now, depending on our case, we may already or not be on top of the main branch. If you're, that's fine.
If you're not, like in the example above, we need to move this branch on top of the main branch. You guessed it,
we need git rebase!

`git rebase main`

This is the point where you may have to solve conflicts. Since we collapsed all commits into one, solving conflicts should be relatively easy. Solving conflicts is harder if you have several commits because a conflict may appear at commit 3/10 and the conflict may have been solved already in commits from 4 to 10! We can't ever face this situation because we only have one commit.

After solving your conflict, if any, this is the result.

![After rewriting history](/assets/blog/git-rebase/ontop.png)

## Let's close this branch!

Now it's time to close the branch, which means we want this work to be on our main branch. You have two options after you move to your main branch with `git checkout main`

- `git merge feature-branch`
- `git rebase feature-branch`

As you can see you can use one of the two. I prefer to use git rebase because like this the history will look like a straight line

![After rewriting history](/assets/blog/git-rebase/end.png)

## Conclusions

This is just one way of working on your repository and it's not necessarily the better one. I hope though you can see the power of git rebase. Some people prefer to have what's called a "merge commit" and this is totally fine. Even in that case rebase can be a useful tool to move your work on top of another branch.

So, there's not really a war between rebase and merge: they're two different tools, anything else is just a useless debate

## Bonus

An interesting topic, when talking about git rebase, is what happens if we rewrite the history of a shared branch.
As you may know if you rewrite the history of a branch and the branch is in use by your teammates, an ancient curse will hit you and your red fish. As we saw before though, sometimes we want to rebase our branch on top of our updated main branch.  
In this case I suggest to push the rebased branch using

`git push --force-with-lease`

It's very similar to --force with the difference that, if anybody else pushed to the remote any new commit, the push is rejected.
I personally have it aliased as

`please = push --force-with-lease`

If the push succeed, your teammates have to run `git pull` in the branch. In any case it's better to coordinate and be very clear about rebasing a common branch, it's also a way to let everybody working with you know about what0s happening!


About another useless war: git rebase VS merge


<small>
  Original photo by&nbsp;
  <a
    href="https://www.pexels.com/@wdnet?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels"
    target="_blank"
  >
    PhotoMIX Company
  </a>&nbsp;
  from&nbsp;
  <a
    href="https://www.pexels.com/photo/black-samsung-tablet-on-google-page-106341/?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels"
    target="_blank"
  >
    Pexels
  </a>
</small>

_I want to thank [Balázs Orbán](https://balazsorban.com) for helping me writing this tutorial_

In this post we're going to explore another way of login into your website powered by NextAuth.js: [Google One Tap](https://developers.google.com/identity/gsi/web/guides/features).

Google One Tap is the quickest way to login through a Google account. Basically the idea is that your website is able to understand if the current user has any Google profile and show a little interface where the user can select which account to use to login, even before starting any login process. So we don't even have to ask the user "Do you want to login with Google?". We already know they can use Google.
Here we're going to see how to integrate this login process with NextAuth.js so that we can keep using this library to handle our users and their authentication. I won't go in details about how NextAuth.js works, so I'll assume that you already know about the [Credentials Provider](https://next-auth.js.org/configuration/providers/credentials-provider) and [Adapters](https://next-auth.js.org/adapters/overview).

## Ingredients and recipe

In order to use Google One Tap, we need to build a [custom Credentials Provider](https://next-auth.js.org/providers/credentials)

We can configure it to either simply return the user's data, or have access to our user database through an Adapter (or any other way).

### Provider

We need to build a custom provider, one that's able to retrieve from Google the information about the user. Once we get the user data, we can return it, or do something else with it, like create the user in our own database.

The Provider is the core part of this login process. We need a Credentials Provider. This provider will receive a token from the front-end generated by Google. We can use this token to query the Google API, retrieve the user and map it to our system.
Since we need to interact with Google, we need to get an id and secret from a Google app. You can refer to the [Google Provider documentation](https://next-auth.js.org/providers/google).

Let's see the code:

```ts
import CredentialsProvider from `next-auth/providers/credentials`;
import { OAuth2Client } from 'google-auth-library';

// This is an instance of a google client that we need to ask google informations about the user
const googleAuthClient = new OAuth2Client(process.env.NEXT_PUBLIC_GOOGLE_ID);

export default NextAuth({
  providers: [
    CredentialsProvider({
      // The id of this credential provider. It's important to give an id because, in frontend we don't want to
      // show anything about this provider in a normal login flow
      id: 'googleonetap',
      // A readable name
      name: 'google-one-tap',

      // This field define what parameter we expect from the FE and what's its name. In this case "credential"
      // This field will contain the token generated by google
      credentials: {
        credential: { type: 'text' },
      },
      // This where all the logic goes
      authorize: async (credentials) => {
        // The token given by google and provided from the frontend
        const token = (credentials as unknown as OneTapCredentials).credential;
        // We use the google library to exchange the token with some information about the user
        const ticket = await googleAuthClient.verifyIdToken({
          // The token received from the interface
          idToken: token,
          // This is the google ID of your application
          audience: process.env.NEXT_PUBLIC_GOOGLE_ID,
        });
        const payload = ticket.getPayload(); // This is the user

        if (!payload) {
          throw new Error('Cannot extract payload from signin token');
        }

        // Check out the jwt https://next-auth.js.org/configuration/callbacks#jwt-callback
        // and session https://next-auth.js.org/configuration/callbacks#session-callback callbacks
        // to see how to store the user in the session.
        // We return the retrieved user
        return payload;
      },
    }),
  ],
});
```

### Adapter

We don't want to access the database directly, because NextAuth.js already knows how to do so. We can instead use the same adapter we set in NextAuth.js options because that exposes all the needed methods to retrieve or create a user. It's possible to use NexthAuth.js without an adapter: in this case we may decide to implement our own way to access the database but this is definitely less easier. We won't cover this case here.

We want to create an adapter but retain an instance to use it later (in the `authorize` callback). For this example, we are going to use the [MongoDB Adapter](https://next-auth.js.org/adapters/mongodb), but any other official (or your custom) adapter should do:

Let's see the code:

```ts
import NextAuth from 'next-auth';
import CredentialsProvider from `next-auth/providers/credentials`;
import { OAuth2Client } from 'google-auth-library';
import { MongoDBAdapter } from '@next-auth/mongodb-adapter';
import clientPromise from '@lib/mongodb';

// This is an instance of a google client that we need to ask google informations about the user
const googleAuthClient = new OAuth2Client(process.env.NEXT_PUBLIC_GOOGLE_ID);

export default async function auth() {
  // An example using the MongoDB adapter
  const adapter = MongoDBAdapter({
    db: (await clientPromise).db('your-database'),
  });

  return await NextAuth(req, res, {
    adapter,
    providers: [
      CredentialsProvider({
        // The id of this credential provider. It's important to give an id because, in frontend we don't want to
        // show anything about this provider in a normal login flow
        id: 'googleonetap',
        // A readable name
        name: 'google-one-tap',

        // This field define what parameter we expect from the FE and what's its name. In this case "credential"
        // This field will contain the token generated by google
        credentials: {
          credential: { type: 'text' },
        },
        // This is where all the logic goes
        authorize: async (credentials) => {
          // The token given by google and provided from the frontend
          const token = (credentials as unknown as OneTapCredentials)
            .credential;
          // We use the google library to exchange the token with some information about the user
          const ticket = await googleAuthClient.verifyIdToken({
            // The token received from the interface
            idToken: token,
            // This is the google ID of your application
            audience: process.env.NEXT_PUBLIC_GOOGLE_ID,
          });
          const payload = ticket.getPayload(); // This is the user

          if (!payload) {
            throw new Error('Cannot extract payload from signin token');
          }

          // If the request went well, we received all this info from Google.
          const {
            email,
            sub,
            given_name,
            family_name,
            email_verified,
            picture: image,
          } = payload;

          // If for some reason the email is not provided, we cannot login the user with this method
          if (!email) {
            throw new Error('Email not available');
          }

          // Let's check on our DB if the user exists
          const user = await adapter.getUserByEmail(email);

          // If there's no user, we need to create it
          if (!user) {
            user = await adapter.createUser({
              name: [given_name, family_name].join(' '),
              email,
              image,
              emailVerified: email_verified ? new Date() : undefined,
            });
          }

          // Let's also retrieve any account for the user from the DB, if any
          const account =
            user &&
            (await adapter.getUserByAccount({ provider: 'google', id: sub }));

          // In case the account is not yet present on our DB, we want to create one and link to the user
          if (!account && user) {
            await adapter.linkAccount({
              userId: user.id,
              provider: 'google',
              providerAccountId: sub,
              accessToken: null,
              accessTokenExpires: null,
              refresh_token: null,
            });
          }
          // We can finally returned the retrieved or created user
          return user;
        },
      }),
    ],
  });
}
```

## Front-end

So, on the front-end we need to show the Google One Tap interface (a Google library will do the job) and to pass the token generated by Google to our provider. Usually this interface is shown in the home page, without asking the user to start the login process. This is the power of the Google One Tap, just one click to get in, without ever leaving the homepage of your website.

First of all, let's make sure to include the Google script somewhere in the page. A good place is your `_app.tsx` and we can use the [Script component from Next.js](https://nextjs.org/docs/basic-features/script):

```tsx
<Script
  src="https://accounts.google.com/gsi/client"
  strategy="afterInteractive"
/>
```

We also need to interact with this script. We can create a custom hook to contain the logic

```ts
import { useEffect, useState } from 'react';
import { useSession, signIn, SignInOptions } from 'next-auth/react';

interface OneTapSigninOptions {
  parentContainerId?: string;
}

const useOneTapSignin = (
  opt?: OneTapSigninOptions & Pick<SignInOptions, 'redirect' | 'callbackUrl'>
) => {
  const { status } = useSession();
  const isSignedIn = status === 'authenticated';
  const { parentContainerId } = opt || {};
  const [isLoading, setIsLoading] = useState(false);

  useEffect(() => {
    if (!isLoading && !isSignedIn) {
      const { google } = window as any;
      if (google) {
        google.accounts.id.initialize({
          client_id: process.env.NEXT_PUBLIC_GOOGLE_ID,
          callback: async (response: any) => {
            setIsLoading(true);

            // Here we call our Provider with the token provided by google
            await signIn('googleonetap', {
              credential: response.credential,
              redirect: true,
              ...opt,
            });
            setIsLoading(false);
          },
          prompt_parent_id: parentContainerId,
          style:
            'position: absolute; top: 100px; right: 30px;width: 0; height: 0; z-index: 1001;',
        });

        // Here we just console.log some error situations and reason why the google one tap
        // is not displayed. You may want to handle it depending on yuor application
        google.accounts.id.prompt((notification: any) => {
          if (notification.isNotDisplayed()) {
            console.log(notification.getNotDisplayedReason());
          } else if (notification.isSkippedMoment()) {
            console.log(notification.getSkippedReason());
          } else if (notification.isDismissedMoment()) {
            console.log(notification.getDismissedReason());
          }
        });
      }
    }
  }, [isLoading, isSignedIn, parentContainerId]);

  return { isLoading };
};

export default useOneTapSignin;
```

Now, we need to place a div somewhere, with a specific id and use the hook we just created:

```tsx
const Component = () => {
  const { isLoading: oneTapIsLoading } = useOneTapSignin({
    redirect: false,
    parentContainerId: 'oneTap',
  });

  return (
    <div id="oneTap" style={{ position: 'absolute', top: '50', right: '0' }} />
  );
};
```

That's all.


Google One Tap login with NextAuth.js


<small>
  Original photo by&nbsp;
  <a
    href="https://www.pexels.com/@black-ice-551383?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels"
    target="_blank"
  >
    Black ice
  </a>&nbsp;
  from&nbsp;
  <a
    href="https://www.pexels.com/photo/blue-background-with-text-overlay-1314536/?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels"
    target="_blank"
  >
    Pexels
  </a>
</small>

When it's time to implement authentication on a [NextJS](https://nextjs.org/) project, chances are that you're going to use [Next-Auth](https://next-auth.js.org/).
It's a very strong product and integrates perfectly with NextJS. It allows you to keep authentication in house so that
you don't have to use external services. While it's very versatile, implementing magic code login can be not obvious.
Magic code is not currently directly supported by next-auth and we need to implement some parts on our own. My hope is that
next-auth team will cover the gap quite soon, making this guide obsolete 😉

## Magic codes

One of the basic authentication methods on next-auth is magic link. With magic link your users just need
to insert their email; they'll receive an email containing a one-time-valid link and can click on it to be logged in automatically.  
There are some problems in next-auth implementation, especially if user uses two different browsers to start the login process and to visit the
magic link. While this seems to be an edge case it acutally is not. On mobile this is pretty common because
mail application spawn their own browser instance that shares nothing with the original one. On iOS email
links are sometimes visited automatically to create preview, invalidating the magic link before the
user even clicks on it.  
This is why magic code can be more versatile. The user, instead of receiving a link, will receive a code (can be numeric, alphanumeric, doesn't matter).
After inserting the email the login page will show an input waiting for that code.
This has the advantage that user can start login on desktop, for example, but check their email on mobile phone.

<img src="/assets/blog/magiccode/magiccodeinput.png" alt="An interface showing an input for the magic code. Several numbers have been already inserted to confirm the email address" title="An interface showing an input for the magic code. Several numbers have been already inserted to confirm the email address" width="200">

## Implementation with next-auth

As first thing we need to tell next-auth that a new `provider` is available. I won't exaplain what a provider is, please refer to [next-auht documentation](https://next-auth.js.org/configuration/providers).  
We need an email provider with some special parts

```ts
const options: NextAuthOptions = {
  ...otherNextAuthOptions,
  providers: [
    Providers.Email({
      server: 'smtp:...',
      from: 'Your email from value',
      maxAge: 5 * 60,
      generateVerificationToken: async () => {
        const token = await generateAuthtoken();
        return token;
      },
      sendVerificationRequest: ({
        identifier: email,
        url,
        token,
        baseUrl,
        provider,
      }) => {
        return new Promise((resolve, reject) => {
          const { server, from } = provider;
          // Strip protocol from URL and use domain as site name
          const site = baseUrl.replace(/^https?:\/\//, '');

          nodemailer.createTransport(server).sendMail(
            {
              to: email,
              from,
              subject: `Authentication code: ${token}`,
              text: text({ url, site, email, token }),
              html: html({ url, site, email, token }),
            },
            (error) => {
              if (error) {
                // logger.error('SEND_VERIFICATION_EMAIL_ERROR', email, error);
                console.error('SEND_VERIFICATION_EMAIL_ERROR', email, error);
                return reject(
                  new Error(`SEND_VERIFICATION_EMAIL_ERROR ${error}`)
                );
              }
              return resolve();
            }
          );
        });
      },
    }),
  ],
};
```

Let's dive into the provider and see what we're doing.

```ts
generateVerificationToken: async () => {
  const token = await generateAuthtoken();
  return token;
},
```

This part generated the (alpha)numeric code. The function `generateAuthtoken` can be what you prefer. For example a function that
returns five random numbers. If you do not specify this option, next-auth will generate its token format,
which is very long.

`maxAge: 5 * 60` tells next-auth that this magic code must be valid for 5 minutes only. It's a good idea
to use low numbers when using magic code, because, since they're usually short, they can be guessed quite easily. A magic link, on the opposite , can last longer.

```ts
sendVerificationRequest: ({
  identifier: email,
  url,
  token,
  baseUrl,
  provider,
}) => {
  // ...
};
```

this function basically build and send the email containing the code. Usually this function is used to customize the look&feel of our emails,
but we're using it also because the original one won't show the code as text, but only as a link.

If we change nothing, next-auth will already show a form that asks user email, and the user will receive our email containing the magic code but we're not done yet.

## Customize signin page

Customization of singin page is usually done for visual purpose, but in case of magic code we are forced to do so, because we need to show a custom
`magic code input` that next-auth is not providing. I think this is the part that prevents a more smooth implementation of magic codes with next-auth.

First of all we need to change next-auth configuration to use a custom singin page

```ts
{
  // other options
  pages: {
    signIn: '/auth/signin',
  },
}
```

We want to use `/auth/singin` page to render the signin form. Let's create the file `/pages/auth/signin` in out NextJS project
with the following minimal code

```tsx
import React, { useState } from 'react';
import { getSession, getProviders } from 'next-auth/client';
import { NextPage } from 'next';
import { useRouter } from 'next/dist/client/router';

interface Provider {
  id: string;
  name: string;
  type: string;
  [k: string]: string;
}

interface SigninPageProps {
  isLoggedIn: boolean;
  providers: Array<Provider>;
  csrfToken: string;
}

const SigninPage: NextPage<SigninPageProps> = ({ providers, isLoggedIn }) => {
  const { query } = useRouter();
  const { error } = query;
  const callbackUrl = 'https://your-website.com';

  const [email, setEmail] = useState('');
  const [showVerificationStep, setShowVerificationStep] = useState(false);
  const emailProvider = Object.values(providers).filter(
    (provider) => provider.type === 'email'
  );

  if (showVerificationStep) {
    return (
      <div>
        <VerificationStep email={email} callbackUrl={callbackUrl} />
      </div>
    );
  }

  return (
    <div>
      <div>
        <h2>Sign in wiht your email</h2>

        {emailProvider.map((provider) => (
          <EmailInput
            key={provider.id}
            provider={provider}
            onSuccess={(email) => {
              setEmail(email);
              setShowVerificationStep(true);
            }}
          />
        ))}
      </div>

      {/* {credentials} */}
    </div>
  );
};

SigninPage.getInitialProps = async (context) => {
  const { req } = context;
  const session = await getSession({ req });
  return {
    isLoggedIn: session !== null,
    providers: await getProviders(),
  } as unknown as SigninPageProps;
};

export default SigninPage;
```

This is a very basic page which do not consider a lot of situations (errors for example), but this way we can focus
on relevant code. Basically we're showing an email input (the `EmailInput` component not yet defined). When the user
insert the email, the component will notify us through the `onSuccess` props. After the user inserted their email, we can
show the input that accepts the code by setting `showVerificationStep` to true.  
Let's have a look at the email input

```tsx
import React, { KeyboardEvent, useCallback, useState } from 'react';
import { signIn } from 'next-auth/client';

interface EmailInputProps {
  provider: Provider;
  onSuccess: (email: string) => void;
}

const EmailInput: React.FC<EmailInputProps> = ({ provider, onSuccess }) => {
  const [email, setEmail] = useState('');
  const [loading, setLoading] = useState(false);

  const handleSignin = useCallback(async () => {
    setLoading(true);
    const res = await signIn('email', {
      email: email,
      redirect: false,
    });
    setLoading(false);
    if (res?.error) {
      if (res?.url) {
        window.location.replace(res.url);
      }
    } else {
      onSuccess(email);
    }
  }, [email, onSuccess]);

  const onKeyPress = useCallback(
    (e: KeyboardEvent) => {
      if (e.key === 'Enter') {
        handleSignin();
      }
    },
    [handleSignin]
  );

  return (
    <div>
      <input
        type="email"
        name="email"
        placeholder="e.g. jane.doe@company.com"
        value={email}
        onChange={(e) => {
          setEmail(e.target.value);
        }}
        onKeyPress={onKeyPress}
      />
      <button disabled={loading}>Next</button>
    </div>
  );
};
```

The email input receives the email from the user and when a button is clicked (or Enter is pressed) it calls the signin method from next-auth.

```tsx
await signIn('email', {
  email: email,
  redirect: false,
});
```

It's important to notice that we specify `redirect: false`. This avoid any page change that is what we want in order to show the code input. What's next-auth is doing is to create (and store on DB) the magic code and to send the email to our user. If the operation goes through correctly, `onSuccess` is called and our component is now allowed to show the magic code input. Let's see it in action

```tsx
import React, { KeyboardEvent, useCallback, useState } from 'react';

interface VerificationStepProps {
  email: string;
  callbackUrl?: string;
}

/**
 * User has inserted the email and now he can put the verification code
 */
export const VerificationStep: React.FC<VerificationStepProps> = ({
  email,
  callbackUrl,
}) => {
  const [code, setCode] = useState('');

  const onReady = useCallback(() => {
    window.location.href = `/api/auth/callback/email?email=${encodeURIComponent(
      email
    )}&token=${code}${callbackUrl ? `&callbackUrl=${callbackUrl}` : ''}`;
  }, [callbackUrl, code, email]);

  const onKeyPress = useCallback(
    (e: KeyboardEvent) => {
      if (e.key === 'Enter') {
        onReady();
      }
    },
    [onReady]
  );

  return (
    <div>
      <h2>Verify email</h2>
      <p>Insert the magic code you received on your email</p>
      <label>
        Magic code:
        <input
          type="text"
          value={code}
          onChange={(e) => setCode(e.target.value)}
          onKeyPress={onKeyPress}
        />
      </label>

      <button onClick={onReady}>Go</button>
    </div>
  );
};
```

The user can now insert the magic code. When it's done we can redirect to the verification step. From there next-auth will take the control and verify the user for you.

## Conclusion

Magic code with next-auth is not strightforward because it requires some implementation from you. This means also that it's up to you to handle errors that can happen (at least to show some message for the user). In case you get stuck, have a look at the original signin page on next-auth repository and get inspiration. Again, I really hope next-auth will deprecate this guide soon by implementing magic code authentication directly, or by improving current magic link experience.


Magic code login with NextAuth


<small>Original photo by <a href="https://www.pexels.com/it-it/@sebastian-ervi-866902?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels" alt="Post cover author page" target="_blank">Sebastian Ervi</a> from <a href="https://www.pexels.com/it-it/foto/artisti-ballando-band-cantante-1763075/?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels" alt="Pexel, free image catalogue">Pexels</a></small>

<blockquote class="normal">
<strong>2020/08/23</strong> Edit: The method to get correct Caravaggio parameters has been greatly improved by the introduction of <strong>caravaggio-plugin-nextjs</strong> which simplifies discovering of current deployment. This means that setting VERCEL_URL into Vercel is not needed anymore. For this to work you need Caravaggio version `3.3.0` at least.
</blockquote>

In this guide I'll show you how to get more from your [NextJS](https://nextjs.org/) projects when it's time to serve images. You'll be able to apply any kind of transformation to the images on the fly without the need to create those resources at build time.

What we're going to do is to ask an image proxy to serve the images stored in the `public` folder and to transform them. Those images will be cached on Vercel CDN after the first request and served at speed of light on any following request. Let's see it in action.

## Why and alternative solutions

I had the need to create a `srcset` for the images in my blog in order to serve `webp` images to browsers that are capable of reading this format, but also to resize and apply several visual transformations. My blog is powered by nextJS so I need something that integrates with it. There are several solutions and packages out there. What they do is to create static resources based on your request, for example if you want all of your images to be served at different sizes depending on screen size and screen density, these libraries creates all the possible alternative images at build time so that they are available for the final user.  
I was a bit unsatisfied by these solutions for a couple of reasons: since images are generated at build time, the build takes longer when the number of images goes up. Also the size of the cache goes up to store all the possible variants of the images. Again, some of these libraries have limitations such as being able to apply only some of the operation (resize the image and produce webp, but not both at the same time).

Being the creator of [Caravaggio](https://caravaggio.ramielcreations.com), I was wondering if there's any way to include it in a NextJS project. Caravaggio is already able to deploy on Vercel, can produce cachable resources (CDN) and it's versatile enough. I can apply lot of transformations at the same time to a single image. In several old projects, which are in production now and serve lots of users, Caravaggio is serving all the assets without a crash in years: it is a good candidate.

Luckily enough, it proved to be very easy to integrate Caravaggio with NextJS.

One great advantage of this approach is that you can use Caravaggio to transform any image, not only the ones in your NextJS public folder.    
This will be very useful if you have user contributed images or external resources because you can use the same
code in both cases. Caravaggio will consider relative urls to be internal images, while absolute urls will be considered external.

Also, you can apply the same method to transform images that you want to use with `css` or for `css-in-js`, thanks to a React hook provided by the library.

## Let’s get our hands dirty

All the examples below are written in `Typescript` because both `caravaggio` and `caravaggio-react` are written in typescript. You can ignore TS specific parts if you use plain javascript.

Let's start by installing the needed dependencies in your NextJS project

```bash
yarn add caravaggio caravaggio-react caravaggio-plugin-nextjs

// or using npm
npm install caravaggio caravaggio-react caravaggio-plugin-nextjs
```

`Caravaggio` is the image proxy itself, while [`caravaggio-react`](https://github.com/ramiel/caravaggio-react) is a react library that will make your life easier. It contains components and hooks to easily interact with Caravaggio from the code itself. [`caravaggio-plugin-nextjs`](https://github.com/ramiel/caravaggio-plugin-nextjs) seamlessy integrates Caravaggio with NextJS.

Once installed we need to create an api

```bash
touch pages/api/assets/[...params].ts
```

I called the api `"assets"` but you can change its name to whatever you prefer. This api will serve images by proxying them through Caravaggio. Here the content of the file

```ts
// pages/api/assets/[...params].ts

import caravaggio from 'caravaggio';
import nextPlugin from 'caravaggio-plugin-nextjs';

const ONE_DAY = 60 * 60 * 24;

export default caravaggio({
  logger: {
    options: {
      level: "error",
    },
  },
  basePath: "/api/assets",
  browserCache: `s-maxage=${ONE_DAY}`,
  plugins: {
    plugins: [{
      name: 'nextjs',
      instance: nextPlugin()
    }]
  }
});
```

Even if Caravaggio can act as a complete webserver, it can be used also as a request handler, like in this case.  
Let's see what the various configurations do.

`logger` is just setting the log level to `error` since we are not interested in more. Logs will be available on your vercel logs.  
`basePath` tells Caravaggio that it's not served from the root folder. If you named your api differently, you must change this value accordingly.  
`browserCache` instruct Caravaggio about the cache value for served images. This value will enable cache on Vercel and the second time the same resource is requested, it will hit vercel cache. You can change the time from one day to any value you prefer.    
`plugins` adds `caravaggio-plugin-next`. This will transform relative urls to absolute urls, seamlessy integrating Caravaggio with NextJS. You probably don't need to pass any further configuration to the plugin but if you have any particular need, refer to [its documentation](https://github.com/ramiel/caravaggio-plugin-nextjs)

That's all, the entire api endpoint is here. Let's see what else to do.

It's time to use Caravaggio in our project. Open you `pages/_app.tsx` file and have a content similar to this one

```tsx
// pages/_app.tsx  (or .js)

import { AppProps } from "next/app";
import { CaravaggioProvider } from "caravaggio-react";

export default function MyApp({ Component, pageProps }: AppProps) {
  return (
    <CaravaggioProvider url="/api/assets">
      <Component {...pageProps} />
    </CaravaggioProvider>
  );
}
```

Let's see what we have done. We imported a Caravaggio provider through

`import { CaravaggioProvider } from "caravaggio-react";`

We wrapped the `Component` with it and passed url option which tells what subpath Caravaggio is served from. In our case it's the internal api we created before. If you choose something different from `api/assets`, change this value accordingly.

## Obtaining fancier images!

It's time to show images in our website. We'll import an `Image` component from `caravaggio-react`. It takes the same props as an `img` tag but also accepts all the [operations available on Caravaggio](https://caravaggio.ramielcreations.com/docs/general-usage). Also, we don't need to put any strange url in it, we can use the relative path to public resource as we're used to do with NextJS.

Let's say we have an image and we want to serve it in progressive jpg, resized to 300px keeping the aspect ratio. If we have our `<img src="/school.png" alt="A nice school building" />`, we can write instead:

```tsx
import { Image } from 'caravaggio-react';

<Image
  src="/school.png"
  alt="A nice school building"
  opt={{
    o: "jpg",
    progressive: true,
    rs: {
      s: "300x",
    },
  }}
/>
```

The possibility you have with those `opt` are a lot and you can find any available operation on [Caravaggio documentation](https://caravaggio.ramielcreations.com/docs).

This specific image is not created at build time, but it's generated dynamically on the fly and cached. Build time remains the same as before, no cache folder is used and if you change any of these options there's nothing to regenerate. Fast and easy!

If you want to use Caravaggio to transform an external image, you can use the same component. Caravaggio will consider absolute urls as external resources.

```tsx
<Image
  src="https://pexels.com/cangaroo.png"
  alt="A cangaroo jumping around"
  opt={{
    o: "webp",
    q: 90,
    blur: 10,
    rs: {
      s: "640x480",
    },
  }}
/>
```

## Easily create srcset from your images

`caravaggio-react` has a useful component to create `srcset` easily: `ImageSet`. Let's see it in action:

```tsx
import { ImageSet } from "caravaggio-react";

<ImageSet
  src="/myimage.png"
  alt="example image"
  className="myclass"
  // Sets is an array of sources
  sets={[
    {
      // This source produce a webp image
      type: "image/webp",
      // The rules for this source
      rules: {
        // When screen is less wider than 300px
        "300w": {
          // Use this caravaggio options to produce the image
          opt: {
            o: "webp",
            rs: {
              s: "300x",
            },
          },
        },
        // Use this for screen large up to 600px
        "600w": {
          opt: {
            o: "webp",
            rs: {
              s: "600x",
            },
          },
        },
      },
    },
    // This is the second set, we want it for browsers 
    // not capable of handling webp images.
    // The rules are the same except for the output format
    {
      rules: {
        "300w": {
          opt: {
            rs: {
              s: "300x",
            },
          },
        },
        "600w": {
          opt: {
            rs: {
              s: "600x",
            },
          },
        },
      },
    },
  ]}
/>;
```

The component generates this html:

```html
<figure class="myclass">
  <picture>
    <source
      type="image/webp"
      srcset="
        /api/assets/o:webp/rs,s:300x?image=http://localhost:3000/myimage.png 300w,
        /api/assets/o:webp/rs,s:600x?image=http://localhost:3000/myimage.png 600w
      "
    />
    <source
      srcset="
        /api/assets/rs,s:300x?image=http://localhost:3000/myimage.png 300w,
        /api/assets/rs,s:600x?image=http://localhost:3000/myimage.png 600w
      "
    />
    <img src="/myimage.png" alt="example image" />
  </picture>
</figure>
```

## Hook: use it to get images for css and css-in-js

Image components are not the only way to create images, you can use a hook to generate image urls to use, for example, in css.

Here an example

```tsx
import { useCaravaggioImage } from "caravaggio-react";

const Component = () => {
  const image = useCaravaggioImage("/images/bg.png", {
    blur: 0.3,
  });

  return <div style={{ backgroundImage: `url('${image}')` }}>Some content</div>;
};
```

## Conclusions

If you want to see the code in action, this blog is powered by the same concept exposed in this article. You can look at the code on [the repository](https://gitlab.com/ramiel/ramielcreations).     
Also be sure to check all the transformations enabled by Caravaggio and ask for any new operation... pull requests are welcome of course!

Enjoy your images!


NextJS + Caravaggio, serve images like a rockstar!


This article is part of a series. You can find [part 1 here](/a-simple-guide-to-react-hooks).

In the first article we focused on `useState` and we saw some details about implementing it using typescript. This time we'll focus on `useEffect` which probably is the second most used hook.
Often, in order to understand `useEffect`, guides and documentation makes lot of reference to component lifecycle. This is totally correct and may help you to better understand when the effect callback is called and why. The problem raises when you're not familiar with the component lifecycle, when you never really got what `componentDidMount` or `componentDidUpdate` do and when. Just to be clear, it would be better to really understand those concepts to fully understand how a React component works. On the other hand I'll try to explain `useEffect` without doing any parallelism with these old class methods. From time to time I'll talk about "when the component mount", "before or after render", but still I'll try to talk about useEffect as classes never existed and we always had just hooks.

## What is an effect?

We're going to start, using the same code we produced at the end of the previous article, let me re-post it here

```tsx
import React, { useState } from 'react';

interface HookTestProps {
  startAt?: number;
}

const Counter: React.FC<HookTestProps> = ({ startAt = 0 }) => {
  const [count, setCount] = useState<number>(startAt);

  return (
    <div>
      <p>{count}</p>
      <button onClick={() => setCount((count) => count + 1)}>Add 1</button>
      <button onClick={() => setCount((count) => count - 1)}>Rem 1</button>
    </div>
  );
};

export default Counter;
```

We have two buttons that can increase/decrease a counter, simple.

Our next goal is to automatically increase the number every X seconds, regardless of the user interaction. For this task we need to use the `useEffect` hook, which, as the name says, let us handle (side) effects. An effect is everything that happens outside of the normal flow of your components: you need to perform a fetch request to get some data to populate your component? Effect. You need to apply some animation? Effect. In our case we want to increase the number without the user interaction, just every X seconds. Let's write the first version of the effect.

```tsx
interface HookTestProps {
  startAt?: number;
  autoIncreaseTime?: number;
}

const Counter: React.FC<HookTestProps> = ({
  startAt = 0,
  autoIncreaseTime,
}) => {
  const [count, setCount] = useState<number>(startAt);

  useEffect(() => {
    if (autoIncreaseTime && autoIncreaseTime > 0) {
      setInterval(() => {
        setCount((c) => c + 1);
      }, autoIncreaseTime);
    }
  });

  return (
    <div>
      <p>{count}</p>
      <button onClick={() => setCount((count) => count + 1)}>Add 1</button>
      <button onClick={() => setCount((count) => count - 1)}>Rem 1</button>
    </div>
  );
};
```

Lets see what's happening: the `useEffect` hook accepts a function and runs it. Our function set an interval every `autoIncreaseTime` milliseconds and increases the counter by 1. There are rules to understand _when_ the effect will run your function, in this case your function is called every time your component is rendered. Oops... we have a couple of problems. If the function is called every time the component is rendered, we don't know how many intervals will run! If the component disappear from our application (is not shown anymore for any reason) the interval will still run because we never wrote a line of code to disable it.

We need a **_way to control when our function runs_**and a **_way to stop its execution_**.

To control when our effects run, we need to specify the second argument of the useEffect hook, which is an array describing the dependencies of our effect. React will look at those dependencies and, when they'll change, the effect will be run again. In our case we want to setup a new `setInterval` any time we have a new `autoIncreaseTime`. If that value changes our old interval is not valid anymore and want to create a new one.

```tsx
useEffect(() => {
  if (autoIncreaseTime && autoIncreaseTime > 0) {
    setInterval(() => {
      setCount((c) => c + 1);
    }, autoIncreaseTime);
  }
}, [autoIncreaseTime]);
```

Set an array of dependencies for our effect
There are use cases for passing an empty array or not passing that array at all, we'll talk about them in a future article.
The first problem is solved, we now explicitly  tell React when to run our effect.

Let's solve the second problem: whenever the `autoIncreaseTime` changes, or our component gets removed, we want to stop the interval. To do this we need to return a cleaning effect function: basically we can return a function that clean our effect and React will call it when needed. Let's transform our code to clean the effect:

```tsx
useEffect(() => {
  if (autoIncreaseTime && autoIncreaseTime > 0) {
    const interval = setInterval(() => {
      setCount((c) => c + 1);
    }, autoIncreaseTime);

    // Instruct react on how to clean our effect
    return () => {
      clearInterval(interval);
    };
  }
}, [autoIncreaseTime]);
```

Clean the effect
All of our problems are solved and we described the basic usage of the effect hook. The `useEffect` hook can be one of the most complicated because dependency definition, run condition and clean process are left to you. This is why some [lint rules](https://www.npmjs.com/package/eslint-plugin-react-hooks) exists and may help you, especially to fulfill the dependency array automatically. The only thing to remember is that these lint rules work only for some cases (the most common) but may not work as intended in some situations, so it's better to understand on our own what to do.

Next time we'll see how to build a custom hook and some traps hidden in the hooks lifecycle. See you soon, meanwhile you can find the code of this article on codesandbox

[![Edit Hooks guide 2](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/s/hooks-guide-2-12849?fontsize=14&hidenavigation=1&module=%2Fsrc%2FCounter.tsx&theme=dark)


A simple (typescript) guide to React Hooks - part 2


This is the first of a series of articles about hooks. Yes, I know, you can find plenty of posts like this out there but stay with me, we'll try to find different points of view and we'll analyze some edge cases that can make you hurt while using hooks. We won't cover everything and we'll skip the very basics: you already know that `useState` is there to let you handle... state, I'll skip this useless information, I promise.
I'm going to include `typescript` in the code because there are some subtle things to know and because soon or later you'll probably use it anyway. If you're not familiar with typescript don't worry, the code is highly readable anyway

You can find all the code of this article on a git repository soon, so that you can just travel through commits for each step.

Cover photo by **[Castorly Stock](https://www.pexels.com/@castorly-stock-1988778?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels)** from **[Pexels](https://www.pexels.com/photo/assorted-colour-crotechet-hooks-3639038/?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels)**

## A simple _useState_ example

So, let's build a simple state to handle a counter. We're going to show the value on the screen and two buttons to increase/decrease that number. Sounds easy? I know, but we'll see some important aspects that you may have missed. We'll also use this as a starting point for further discussions.

```tsx
import React, { useState } from 'react';

interface HookTestProps {
  startAt?: number;
}

const Counter: React.FC<HookTestProps> = ({ startAt }) => {
  const [count, setCount] = useState(startAt);

  return (
    <div>
      <p>{count}</p>
      <button onClick={() => setCount((count) => count + 1)}>Add 1</button>
      <button onClick={() => setCount((count) => count - 1)}>Rem 1</button>
    </div>
  );
};

export default Counter;
```

Analyze it: we're using a `count` variable that holds the state, initialized with `startAt` value, and `setCount` that is used to change that state. You're probably familiar with it already. What type is `count`? If you ask typescript, it'll tell you that  it is `number or undefined`. This is because the type is guessed by the `startAt` type that is, as said, number or undefined. When we define an hook like this, it can be better to also enforce the type and in our case it makes no sense to have a counter that can be undefined; we want it to be a number. A naive approach is to simply provide a fallback value

```tsx
const [count, setCount] = useState(startAt || 0);
```

It works but it's not elegant: by mistake we can remove the fallback value, zero, and the compiler won't tell anything: we need to take advantage of the `generic` nature of useState. It accepts the type and the correct syntax is

```tsx
const [count, setCount] = useState<number>(startAt);
```

Better. The typescript compiler will suddenly complain about startAt: it must be number but it can also be undefined and this is a problem. Good job typescript. Now it makes a lot of sense to provide a fallback value because is logically correct and also because we'll make the compiler happy 😀.

```tsx
const Counter: React.FC<HookTestProps> = ({ startAt = 0 }) => {
  const [count, setCount] = useState<number>(startAt);

  return (
    <div>
      <p>{count}</p>
      <button onClick={() => setCount((count) => count + 1)}>Add 1</button>
      <button onClick={() => setCount((count) => count - 1)}>Rem 1</button>
    </div>
  );
};
```

## Changing the value of _count_

Let's focus on the function that changes the value of count. We have a button to increase the count value by 1 and of course we need to know the current value of the counter to increase it by one. Sometimes you may be tempted to write code like this

```tsx
<button onClick={() => setCount(count + 1)}>Add 1</button>
```

Spoiler alert: this code works. Is it correct? No.
The `setCount` function accepts two type of parameters: a number (or the type of your state) and a function which is called with the current value of the state. If you have to use the current value of the state to compute the new state, you **must** use the latter version. If you don't, try to think what happens if you write this

```tsx
// count is 1
setCount(count + 1);
setCount(count + 1);
```

How much is the state at the end? Probably it'll be 2 and no 3 as you may expect.

So, long story short, use the other version

```tsx
<button onClick={() => setCount((count) => count + 1)}>Add 1</button>
```

so you are sure your changes will compute from the latest value of the state, not from the current one. Here below the final version of our counter and you can play with it on CodeSandbox.

```tsx
import React, { useState } from 'react';

interface HookTestProps {
  startAt?: number;
}

const Counter: React.FC<HookTestProps> = ({ startAt = 0 }) => {
  const [count, setCount] = useState<number>(startAt);

  return (
    <div>
      <p>{count}</p>
      <button onClick={() => setCount((count) => count + 1)}>Add 1</button>
      <button onClick={() => setCount((count) => count - 1)}>Rem 1</button>
    </div>
  );
};

export default Counter;
```

[![Edit priceless-archimedes-f2z60](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/s/priceless-archimedes-f2z60?autoresize=1&codemirror=1&fontsize=14&hidenavigation=1&module=%2Fsrc%2FCounter.tsx&theme=dark&view=editor)

\*You can find **[here part 2](/a-simple-typescript-guide-to-react-hooks-part-2)\***


A simple (typescript) guide to React Hooks


Recently, I've been unsatisfied with current routing solutions in Javascript, especially when coupled with React. Don't get me wrong, libraries out there are great, like [React-Router](https://github.com/ReactTraining/react-router), but they don't well overlap with my idea of routing. Sometimes they're too coupled with the view system, other they miss some basic features or are not customizable enough. My idea, of course, has been to write yet another router library but this time it isn't something I started from scratch. It happened that long time ago (more than 7 years ago!) I wrote a router library. It was a time when the history.pushState API wasn't introduced yet and routing involved hashbang, `!#/` at the end of the regular url. Inside that library there were some good ideas and it has been used a lot, so it is a good starting point.

---

## tl;dr

If you aren't interested in reasons behind the code or if you prefer to get your hands dirty, go checkout these libraries:

[RouterJS](https://github.com/ramiel/router.js): VanillaJS routing library.
[React-RouterJS](https://github.com/ramiel/react-routerjs): The way to use the library with React.

## View agnostic

My idea is that the library should be "**view agnostic**". I'd say more, it must be framework agnostic. It should be possible to use it with vanilla JS, React, Vue, outside of the browser or anywhere else you like. Let's focus on the meaning of being **view agnostic**. I feel like a routing library is really unrelated from the fact that we use it to show a particular view: we will do it eventually, in most of the cases, but showing a view is a side effect of the routing. Routing is the ability to map a state (usually the current url) with another state. Actually the pushState API does the same: it lets you define a state while navigating with the browser but tells nothing about what should be shown on the screen. This is what I missed so much using react-router: it is so coupled with the view, the react components, that is hard to use it for other use cases. It's not impossible, it's just unnatural for me.

So let's try to stay simple and say that a route is a function bound to an url match. This is what happens in express.js or zeit-micro. Here how to do it with RouterJS:

```js
import { createRouter } from 'routerjs';

const options = {
  /*...*/
};
const router = createRouter(options)
  .get('/user/:name', userRoute)
  .get('/post/:slug', postRoute);
```

simple routes definition
The take is easy: define a route through a string (in this case there are also named parameters like `:name`) and bind a function to it. This is the simplest pattern we can have for a routing library and in fact it's very, very common.

Where is defined which view to show? Nowhere.
We're free to setup our own mechanism to select a view inside those functions or use a more generic approach: for example we can create a React library that accepts the route definition and somehow show a View, but we'll see this later or, if you're curious, read the ["React integration" section](#react-integration).

## Multiple engines

Another idea is that, while the core concept is the same, "a route matches a function", the way these two pieces are glued together can depend on many factors: is the pushState API available? Do we want to use hashbang in our app? Are we on something different from a browser, for example on some javascript framework for mobile applications?

What changes, in all of these cases, is the way we navigate, the way we understand the route is changed and so on. For this reason the router accepts an engine. The default is an engine based on browser history but we can pass our own implementation.

```js
import { createRouter } from 'routerjs';

// The default, an engine using popState API
const router = createRouter({ engine: BrowserHistoryEngine() });

// An engine for ReactNative
const router = createRouter({ engine: ReactNativeEngine() });

// An engine for hashbangs
const router = createRouter({ engine: HashBangEngine() });
```

While just the first engine has a real implementation and maybe the other makes no sense at all (I'm not very practical of react native coding :p), you have more freedom now and you can implement your own engine with peculiar features. An engine is something very trivial: a function that returns an object with various methods, to get the current route or to execute redirects and so on.

## Middlewares

Middleware is a handy concept: basically the idea is to provide a set of components (middleware) that run before your main function. The most known implementation of middlewares is the one of `express` but I think the most powerful one comes from `zeit-micro`: **a middleware is a function**. Nothing special, just a function. It has no metadata associated, no special class derivation, no factory. Nothing, just a function. So in the frontend router of my dreams a middleware is a function. A similar approach is taken by `page.js` by visionmedia. An additional feature I need to have is that an error should stop normal flow.

Now, let's see the most classical middleware example: authorization. The idea is to forbid a route if the user is not authenticated. First of all lets see how a route function is done:

```js
import { createRouter } from 'routerjs';

const protectedRoute = (req) => {
  console.log(`Hello, I'm a protected route!`);
};

createRouter.get('/protected', protectedRoute);
```

A typical, simple route
Now let's implement a middleware that checks if the user is authenticated

```js
cont authMiddleware = fn => async (req) => {
    // this fake async call returns true if the user is authenticated.
    // The implementation is not shown because it's not important,
    // you can imagine whatever you want: a fetch request or
    // a cookie check
    if(!await isAuthenticated(req)) {
        throw new Error('User not authenticated');
    }
    return fn(req);
}
```

A simple middleware, a function
So, a middleware is a function that takes the next function as parameter (which can be another middleware) and applies some logic. Let's apply this to our protected route

```js
import { createRouter } from 'routerjs';
import authMiddleware from './authMiddleware';

const protectedRoute = (req) => {
  console.log(`Hello, I'm a protected route!`);
};

router = createRouter()
  .get('/protected', authMiddleware(protectedRoute)));
```

If you need to apply more middlewares you just need to wrap one in the other, or use a typical compose function, provided by the library.

```js
import { createRouter, compose } from 'routerjs';
import authMiddleware from './authMiddleware';
import logMiddleware from './logMiddleware';

const protectedRoute = (req) => {
  console.log(`Hello, I'm a protected route!`);
};

router = createRouter().get(
  '/protected',
  compose(
    authMiddleware,
    logMiddleware
    // ... other middlewares
  )(protectedRoute)
);
```

Middleware composition
Easy, isn't it?

## Other goodies

There's not enough space in this post to explain what else is available in the library, so you should have a  look at the [official documentation](https://github.com/ramiel/router.js), you will find:

- Request and context
- Error handling
- Always executed callbacks
- Auto-click handler
- Base-path definition

## React integration

Let's talk about the integration with React. Even if I talked a lot about how the router library shouldn't be tied to the view system, this doesn't mean they should not interact. It's very powerful, in my opinion, to have them separated, the same way redux can work without React even if they're often coupled. The integration is left to another little module called `[react-routerjs](https://github.com/ramiel/react-routerjs)`. Let's see how it works.

First, it provides you a **RouterProvider**, similar to the one from redux or similar libraries. It accepts your routing definition:

```js
import { createRouter } from 'routerjs';
import { RouterProvider } from 'react-routerjs';

const router = createRouter() //...your routing definition

const App = () => {
  return (<RouterProvider router={router}>
      // ... your app components
  </Router>);
}
```

This should be placed as on top as possible in your components hierarchy. It's really nothing fancy, just a context provider.

This give you access to a series of components. One of this is a `Link` component. While RouterJS doesn't need any special component for the links, you may have defined your routes with a `basePath` because your application is served under an `/app` path for example. So, any time you want an anchor, you should write something like

`<a href="/app/user">Profile</a>`

The `Link` component can read the router configuration and let you write

`<Link href="/user">Profile</Link>`

instead, taking care of transforming the url in the correct, expanded path.

The main usage of the React binding is the ability to select a view component. Let's see it in action:

```js
import React form 'react';
import { createRouter, compose } from 'routerjs';
import { withView } from 'react-routerjs';

const Home = React.lazy(async() => await import('./Home'));
const Profile = React.lazy(async() => await import('./Profile'));

const router = Router()
  .get('/home', compose(
      // ...other middlewares
      // We can tell that this route is shown through the Home component
      // that can be provided directly or, as in this case, through a
      // React.lazy call
      withView((req, ctx) => <Home />)
  )(homeRoutehandler))

  .get('/profile/:id', compose(
      withView((req, ctx) => <Profile id={req.params.id} />)
  )(profileRoutehandler))
```

Later we can use the `<RouteView>` component to show it in the application

```js
import { RouterProvider, RouteView } from 'react-routerjs';

const App = () => {
  return (
    <RouterProvider>
      // ...
      <RouteView />
    </RouterProvider>
  );
};
```

The `<RouteView />` component will use the `Home` or the `Profile` components to show the correct view. Since we can return a promise through React.lazy, we'll take advantage of React Suspense to lazy load our components 😍

The `RouteView` and `withView` couple can also specify a target to set the current view for different parts of the application.

## That's not all folks

If you liked what you read, discover the libraries on Github, there's much more!

[RouterJS](https://github.com/ramiel/router.js): VanillaJS routing library.
[React-RouterJS](https://github.com/ramiel/react-routerjs): React components for RouterJS.


Routing in React, a different approach


This post is about a little coding exercise where we will create basic components to implement reactive programming paradigm using only node.js streams. There are lot of libraries out there for reactive programming, like [RxJS](https://rxjs-dev.firebaseapp.com/), [Bacon](https://baconjs.github.io/) and [Callbags](https://github.com/callbag/callbag). These libraries don't use node.js streams while is possible to wrap regular streams as source. Another good library is [Highland](http://highlandjs.org) which build node.js-like streams. More than explaining how to use this kind of libraries, in this article we want to write a simple one, understand which problems it solves and which advantages gives us.

Starting from a real world problem, first we'll build some basic tools which will remember us the basic blocks of functional programming, such as `map`, `filter` and `reduce` functions. Then we'll see how to combine these bricks to write a neat, clear and effective code.

You can find all the code present in this article on [repl.it](https://repl.it/@FabrizioRuggeri/ReactiveNodeStreams).

A library that expose these concepts has been released on npm, check it out on [github](https://github.com/ramiel/streamfp).

## The case

Let's define the problem we want to solve. We want to fetch, from a database, a list of economical transactions. Later we want to convert each transaction amount from US-dollar to euro, filter only the ones with an amount higher than 100€ and compute the sum.

Don't mind if those operations can probably be done with most of the database out there, for the sake of the experiment let's say we can just retrieve a list as an array or a stream.

Here a simple implementation

```js
const sumRichTransactions = async () => {
  const transactions = await DB.getAsArray({ collection: 'Transaction' });

  const sum = transactions
    .map((transaction) => transaction.amount * USD2EUR_CONVERSION_FACTOR)
    .filter((amount) => amount > 100)
    .reduce((sum, amount) => sum + amount, 0);

  return sum;
};

sumRichTransactions();
```

The code should be clear enough. First we retrive the data as an array, then we map each value to convert the amount from dollars to euro, then we keep only those which amount is more than 100€ with the filter function and lastly we reduce the array to get the sum of the amounts. We return this sum.

## What's wrong with it

Let's look at some possible problems of this approach. Everything stays in memory: the array returned by the db is stored in memory, the memory of your application. If there are millions of those transactions, the memory footprint can be huge.
`map`, `filter` and `reduce` are handy functions but each of it cycle our dataset one time. This means the dataset is cycled three times in this example (reduce cycles a subset actually). Cycling without a bike is just loosing time. To solve this problem could be useful to know that we could use a nice different approach with `transducers`. Transducers are really powerful and worth reading about it. This [article](https://medium.com/@roman01la/understanding-transducers-in-javascript-3500d3bd9624) by @roman01 gives a great introduction.

We want to change this implementation to use streams to demonstrate how these problems are solved.

## Streams

In this article I take as a fact that you already know node.js streams. I already know that streams is one of the most underestimated parts of node.js so here a little recap:

Streams can be of three types:

- Readable
- Writable
- Duplex/Transform

A `Transform` stream is a Duplex stream that _can_ transform data it receives.

`null` has a particular meaning among streams. If the null value is fed to a stream, the stream ends. It's like saying that `null` has the meaning of "end of communications".

Streams usually work with buffer but they can be configured to work with objects. Practically this means that every chunk read/write by a stream is an object. For simplicity we'll work in object mode.

Streams can be piped to produce chains that looks like `Readable → Transform → Transform → Writable`. It's written like this:

```js
readableSrc
  .pipe(transformStream1)
  .pipe(transformStream2)
  .pipe(finalWrtitableDest);
```

For anything else you don't know about streams, read the official [documentation](https://nodejs.org/api/stream.html) or the article _[Node.js Streams: Everything you need to know](https://medium.freecodecamp.org/node-js-streams-everything-you-need-to-know-c9141306be93)_.

## Our first Transform stream

Let's imagine to have function called `DB.getAsStream` which gives the same results of `DB.getAsArray` but in the form of an object stream.

```js
const stream = DB.getAsStream({ collection: 'Transaction' });

stream.on('read', (transaction) => console.log(transaction));

//Everytime the read callback is called something like this is printed
// {id:1, amount: 12, currency: "USD"}
// {id:2, amount: 456, currency: "USD"}
// {id:3, amount: 120, currency: "USD"}
```

Let write a transform stream that changes each transaction returning the amount converted in euro. We will use the simplified constructor for stream, but the same can be achieved with the class-style constructor.

```js
const USD2EUR_CONVERSION_FACTOR = 0.85;

const usd2eur = new Transform({
  // Each chunk is an object. Here we tell node to not consider the chunks as buffers
  objectMode: true,

  // The signature is (chunk, encoding, callback) but we can safely rename chunk to transaction
  transform(transaction, encoding, callback) {
    callback(null, transaction.amount * USD2EUR_CONVERSION_FACTOR);
  },
});
```

Let's write the entire code

```js
const { Transform } = require('stream');

const usd2eur = new Transform({
  // ... same as before
});
const stream = await DB.getAsStream({ collection: 'Transaction' });
const transformedStream = stream.pipe(usd2eur);

transformedStream.on('data', (amount) => console.log(amount));
// This will output
// 10.2
// 387.59
// 102
```

As you can imagine, it's possible to write also the filter and reduce functions as transform, but is this needed? Must we really write each business function as a Transform implementation? What if we can focus on our business code and hide somewhere else the Transform instantiation? Well, we can...

## Providing the building blocks

In our first implementation we focused on our business without caring of how `map, filter, reduce` functions works. We have them as part of the standard javascript library and we simply use them. We focused on writing the mapping function, the filter function and the reduce function.

Let's isolate them:

```js
const amountToEur = (t) => t.amount * USD2EUR_CONVERSION_FACTOR;
const moreThan100 = (amount) => amount > 100;
const sum = (sum, amount) => amount + sum;

// Later we use them

transactions.map(amountToEur).filter(moreThan100).reduce(sum, 0);
```

Now we're going to write the implementation of `map, filter and reduce` but for streams so we can reuse our business logic. At the end we'll write our code like that

```js
stream.pipe(map(amountToEur)).pipe(filter(moreThan100)).pipe(reduce(sum, 0));
```

### Map

Here an implementation of map using a transform stream. We want to let the user provide a map function and apply it for each chunk.

```js
const map = (fn, options = {}) =>
  new Transform({
    // By default we are in object mode but this can be overwritten by the user
    objectMode: true,
    ...options,

    transform(chunk, encoding, callback) {
      let res;
      try {
        res = fn(chunk);
      } catch (e) {
        return callback(e);
      }
      callback(null, res);
    },
  });
```

This should do the trick. Every chunk passing in the stream is _mapped_ to a new value using the user mapping function `fn`, exactly as map for arrays. The second parameter is included in this implementation for completeness, but it's useless in our case.

Great. Now we can write

### Filter

Filter exploits a peculiarity of transform streams: they're not forced to emit an output value for each input value. They're totally unrelated, output values can be as much as the input or less or more. Here the filter for streams

```js
const filter = (fn, options = {}) =>
  new Transform({
    objectMode: true,
    ...options,

    transform(chunk, encoding, callback) {
      let take;
      try {
        take = fn(chunk);
      } catch (e) {
        return callback(e);
      }
      return callback(null, take ? chunk : undefined);
    },
  });
```

Notice that if the filter function returns false, we call the callback with _undefined_. We do not use _null_ otherwise the stream will end!

### Reduce

Reduce is probably the more complex but not that much.

```js
const reduce = (fn, acc, options = {}) =>
  new Transform({
    objectMode: true,
    ...options,

    transform(chunk, encoding, callback) {
      try {
        acc = fn(acc, chunk);
      } catch (e) {
        return callback(e);
      }
      return callback();
    },

    flush(callback) {
      callback(null, acc);
    },
  });
```

As you can see reduce must implement also `flush` method. This method is called at the end, when all the transformations are done (on stream "end" event). At that point we want to return the accumulated value.

We should note a key difference between `reduce` and the other functions. While map and filter emit a value while the stream is ongoing, reduce will emit only at the end. This is because, with streams, we can't know beforehand how many chunks there will be, we must wait the stream end before emitting the reduced value.

## Using the building blocks

A you can see, map, filter and reduce have the same signature of their array counterpart except for the last parameter which is ignored by the way. Let's see how our code looks like using the new functions

```js
// Isolate our new shiny functions in their module
const { map, filter, reduce } = require('./streamUtils');

const amountToEur = (t) => t.amount * USD2EUR_CONVERSION_FACTOR;
const moreThan100 = (amount) => amount > 100;
const sum = (sum, amount) => amount + sum;

const stream = await DB.getAsStream({ collection: 'Transaction' });
return stream
  .pipe(map(amountToEur))
  .pipe(filter(moreThan100))
  .pipe(reduce(sum));
```

So, we focused on our business code. Cool. We also solved all our initial problems. The memory is under control since the streams never bloat your memory which will keep only the current chunk. Also, we never cycle the dataset more than once. Each chunk pass through map and filter function once and then goes on the reduce function which will access the chunk one by one too. It's very similar to what transducers do.

This is a great achievement because, without changing too much the way we wrote the code, we gain a lot and are covered against problems that can arise only at runtime.

## Bonus 1: compose

The code is neat, quick and have a low memomry footprint but we can have a better style. Having each map/filter/reduce function wrapped by a `pipe` function makes the code a bit ugly. We have two choices: make the code chainable (`.map().filter().reduce()`) as it happens for arrays, or use a point free code style.

To make the code chainable we could wrap the stream object and this is what a library like Highland does. Since that is already a good example, let's go for the point-free version.

Point-free code style is a popular way of writing the code especially in functional programming world. What we want is to group all the transoform passed to pipes in order to remove all those `.pipe()` call: we want to compose them. The desired result is:

```js
...
...
return compose(
    map(amountToEur)
    filter(moreThan100)
    reduce(sum)
)(stream)
```

As you can see this is very similar to `compose` for functions. The only difference is that it takes a stream and returns a stream. Here the implementation of compose.

```js
const compose =
  (...fns) =>
  (stream) =>
    fns.reduce((transformed, fn) => transformed.pipe(fn), stream);
```

It's a simple reduce that start with a stream and, at each step, returns the stream piped with the next transformer.

## Bonus 2: async

Map, filter and reduce accept only synchronous functions. Stream transformers are innerly asynchronous because, as many node.js functions, a callback is accepted as last parameter. Here a version of map that accept a promise as return value of the map function and waits until the promise is fullfilled.

```js
const asyncMap = (fn, options = {}) =>
  new Transform({
    objectMode: true,
    ...options,

    transform(chunk, encoding, callback) {
      let promise;
      try {
        promise = fn(chunk);
      } catch (e) {
        callback(e);
        return;
      }
      if (!(promise instanceof Promise)) {
        promise = Promise.resolve(promise);
      }
      promise.then((res) => callback(null, res)).catch((err) => callback(err));
    },
  });
```

This implementation accepts also functions that don't return promises and promisify their return value.

## Bonus, some more

There are other little advantages, e.g.

- easy by-step inspection
- incomplete map
- error handling
- Multiple flows (stream fork)
- stream as promises

but maybe these will find place in another article :)

## Conclusion

We saw how we can solve some common problems with a nice use of node.js streams. We wrote together some basic block, the functions `map`, `filter` and `reduce`, to build everything else with it. Usually libraries that offer similar functionalities have useful functions such as throttle, debounce, group etc. We definied only three basic functions because them can be used to build any other fancy functionality. To be honest, we could have defined only reduce, because it's the very base component of any other function. Map and filter can be actually written as reduce implementation. If you like the approach I suggest you to have a look at the libraries I mentioned at the beginning of this article because usually offers many ineresting features (e.g. lazyness and asynchronicity).


The hidden power of node.js streams: reactive programming.

Every developer out there used Github at least once to store their projects. Github imposed itself as code platform a couple of years ago when solutions as SourceForge saw its decline. Github helped all of us to have more confidence with git and also, in my opinion, created a bit of confusion deciding to name the code patch system "pull request".

Gitlab was born a bit later and it's a very similar platform which can be installed on your own servers.It's like having a Github service handled by you. Gitlab comes in several shapes and one is the community edition which is basically a free SaaS. This is the version I want to talk about today, the `gitlab.com` service.

The main reason why developers choose GitHub for their personal projects is because of the community. We're all there and the system works very well actually.

In the latest years, although, I started falling in love with Gitlab for some reasons I'm going to explain later in this article. I started using Gitlab for two reasons: it offers illimited private projects and it used to be adopted by some companies I worked with.

One month ago I started developing [Caravaggio](https://ramiel.gitlab.io/caravaggio/) a fast image web proxy written in Node.js. Because I need to keep the project as private at the beginning and because I'd want to use some tools which I like more on Gitlab, I hosted it there. It was the first time I used Gitlab for a personal project. Let me tell you what I learned and why I made this choice.

## What makes Gitlab a great tool

As many of you may have already noticed, often the code is the easier part of a project and, instead, you have to put more effort into other aspects. So, here my needs to release Caravaggio:

### Documentation

I need a way to give my users a good documentation which cannot be contained in the space of a readme file. Basically, I need a proper website. A statically generated website is enough and Gitlab provides `Gitlab-pages` which are more or less the same as `GitHub pages`. Gitlab-pages gives you a lot of freedom since you can choose any tool you like to produce your website and it's easy to integrate your building tool with Gitlab's CI system.

The result is this [beautiful documentation](https://ramiel.gitlab.io/caravaggio/) produced with [docusaurus](https://docusaurus.io/en/).

![Documentation website](/assets/blog/gitlab-over-github/documentation.png)

### Continuous integration and deployment

One of the key features which make me love Gitlab is the integrated continuous integration system. Github let you use an external system to run your CI tasks so you can choose great tools like Travis or CircleCI. The effort to integrate them is really low and there's nothing wrong with it.

Gitlab takes another approach: the CI system is totally integrated into the platform so you don't need to use an external service. This means you can watch your running pipelines from the same interface where you have your code and the integration is generally deeper. Then, they did something amazing: on gitlab.com you can use a series of shared runners, machines which runs your pipelines along with the ones from other projects. There is no limitation if your project is private, it has the same capability of the public projects (on Gitlab the concept of private repositories is not behind any pricing policy). If you want, and here is the magic, you can spawn runners of your own, on your local machine or on a server you have somewhere, and set them as dedicated runners for your project. This means you can choose to use shared or dedicated runners. Traditionally what companies do, when they need private resources to launch CI jobs, is to configure some Jenkins on their own servers. Gitlab solution is a lot better. You have nothing to configure (Jenkins can be hard sometimes), you just have to run a service (provided as OS package usually) and register it. You can start with the shared ones and, if you really need more power, spawn your owns and they're technically the same. Simple and powerful 😍.

For Caravaggio, my CI jobs are running test, checking code quality, deploying new versions on [npm](https://www.npmjs.com/package/caravaggio) and on the [docker store](https://store.docker.com/community/images/ramielcreations/caravaggio).



Thanks to its integrated CI system, Gitlab is capable to provide an `auto-devops` feature which basically set for you a series of jobs based on your project type. If you do nothing you get, out of the box, tests, code quality checks and deployments on a kubernetes cluster 😱

### Drawbacks

Gitlab.com is an excellent solution but it could improve under some aspects. Mainly, I don't consider the platform reliable. Sometimes it stays unusable for hours because of a new release being deployed or other little problems: you can look at their twitter account [https://twitter.com/GitLabStatus](https://twitter.com/GitLabStatus)

This is something they should fix. Today, simply, is not acceptable that a service becomes unusable because of a release. This is a good reason, for companies, to install Gitlab on their server. Nonetheless, gitlab.com should try to improve a lot under this aspect.

[edit 2019] They are better now! It seems they get rid of any problem due to releases and the platform is far more reliable than before. Good job Gitlab!

### You will miss the community

This is true and this can be tough. Gitlab is an excellent choice when you're in an enterprise environment. You can install it on your servers and maintain it completely private and within the boundaries of your control.

Anytime I had to release something public instead, I chose GitHub because it's where people expect to find the code for open source projects. Every developer has an account on GitHub but maybe not one on Gitlab, so for them, it will be easier to contribute sending pull requests or opening issues.

It looks like I have no choice: need to go public, GitHub. Need to use the tools I love, go with Gitlab.

This time with Caravaggio I decided to make a bet and to leave it on Gitlab. I want to understand if the project will be less considered because of the platform. I want to understand if today, Gitlab is a good solution for public, open source projects, as it deserves to be.

I expect to have fewer interactions and probably some user will be discouraged when it will time to open an issue or send merge requests (the name of pull requests on Gitlab...a lot more meaningful!)

Choosing Gitlab over Github today


Me and [@rafrart](http://rafrart.com) started a little old project...

![Sketch dr Gregory Marlow](https://res.cloudinary.com/ramiel/image/upload/v1480176452/IMG_20161126_165001_syepix.jpg)


The first draw of...


The way we develop javascript applications has radically changed during the last years. Javascript has become a widely used language and it broke the walls of the environment in which it was born, to be used at every level in software production, for the web and more.

In any case we do not write javascript as we were used to do. For example if we are going to write a React.js application, the first thing, even before writing a single js line, we configure webpack to transpile our ES6 code, to convert JSX in a language spoken by the broswer, to minify the code, to create a source map etc. Writing javascript means having a compilation phase.

This is well explained in the article [How it feels to learn JavaScript in 2016](https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f) by [@jjperezaguinaga](https://medium.com/@jjperezaguinaga)

Despite I see the advantages and I appreciate the direction we took, I was always wondering how it would be to write application like in the '90. Would it be so scary to write an application just using an editor and a browser? Would the code be unreadable? Are there limits we cannot trespass without a transpiler?

This article is an answer to these questions...and a little time travel back in time.

## The project

The idea is to take some existing code and to reduce it to have some JS which works on every modern browser. It's an extrusion work. On every step I'm going to remove a functionality not supported directly by the browser and I'm going to adapt the code. At the end we will have a bunch of text files and a working application without regressions. I decided to take a simple project and then I chose an example "todo app" written in react/redux ([here](https://github.com/reactjs/redux/tree/4574a8c/examples/todos) the original code). I adapted it simplifing the build system to have more control.

The initial code is available on the github repository at [step-0](https://github.com/ramiel/js-back-to-the-roots/tree/step-0).

Ah, the application looks like this after webpack passage and served from a development server:

![todo application](https://res.cloudinary.com/ramiel/image/upload/v1477824533/todo_fj3jwt.gif)

## Goodbye next generation javascript

Let's start giving a look to our `webpack.config.js`

```js
const path = require('path')
const config = {
  entry: './src/index.js',
  output: {
    path: path.join(__dirname, 'public/'),
    filename: 'bundle.js'
  },
  module: {
    loaders: [{
      test: /\.jsx?$/,
      exclude: /node_modules/,
      loader: 'babel',
      include: __dirname,
      query: {
        cacheDirectory: true,
        presets: ['es2015', 'stage-0', 'react']
      }
    }]
  },
  resolve: {
    extensions: ['', '.js', '.jsx']
  },
  cache: true,
  devtool: 'source-map',
  devServer: {
    port: 9000,
    host: '0.0.0.0'
  }
}

module.exports = config
```   

As you can notice there are three presets which let us use modern javascript. Let's start removing `stage-0` which let us use some nice feature not yet implemented in ES6. Naming conventions aka stage-0 can be confusing, [@jayphelps](https://medium.com/@jayphelps) explains them very well on [his article](https://medium.com/@jayphelps/please-stop-referring-to-proposed-javascript-features-as-es7-cad29f9dcc4b#.lh0j4t2cv).

Running `npm start` in our application give us some errors, let's see them one by one:

```
  13 | 
  14 |       return {
> 15 |         ...state,
      |         ^
  16 |         completed: !state.completed
  17 |       }
  18 |     default:
```  

Ok, looks like we cannot use anymore the spread operator to easily build objects. What does it means? To obtain the same code with ES6 only javascript, we must use `Object.assign` instead, so the above code will be:

```js
return Object.assign(
  {},
  state,
  {completed: !state.completed}
)
```

It looks like this was the only place in the code where we were using stage-0 features. Easy task. Other feature as `async/await` can have a larger impact after modification (i.e. to promises) but are not so difficult to do.

The modified code can be found at [step-1](https://github.com/ramiel/js-back-to-the-roots/tree/step-1)

## Goodbye modern javascript

It's time to prevent webpack to transpile ES6 code removing the preset from the configuration

```js
module: {
    loaders: [{
      test: /\.jsx?$/,
      exclude: /node_modules/,
      loader: 'babel',
      include: __dirname,
      query: {
        cacheDirectory: true,
        presets: [/*'es2015', 'stage-0',*/ 'react']
      }
    }]
}
```
    

With es2015, we lost the possibility to import any dependency using `import`. This is the first problem we have to fix. Should be easy enough to replace all the import with a `require` for the moment. At the end, when we will remove webpack, even require will not be available but for the moment let's transform any line like this    
`import React from 'react'`

into    
`const React = require('react')`

I used this regular expression `import\s+(.+)from\s+('.+')` and replaced with `const $1 = require($2)` to do the job. Even the export format has to change. We can rely on `module.exports` instead of `export default`. Here the variations could be a bit more complex but at the end should not be so hard.

Incredibly, just the require system has been a problem after removing es6 transpiler. No other feature was used. Features as `arrow functions` are already well supported from modern browsers. We don't have to worry. Of course, supporting some old browser can be more complicated and would need polyfills. We won't dive in that scenario for now.

I noticed that all the react components were written as function. Just for test, I tried to rewrite the App.js as a class, to see what happen. I changed the code from

```jsx
const App = () => (
  <div>
    <AddTodo />
    <VisibleTodoList />
    <Footer />
  </div>
)
```
    

to

```jsx
class App extends React.Component {
  render () {
    return (<div>
      <AddTodo />
      <VisibleTodoList />
      <Footer />
    </div>)
  }
}
```

everything went fine. Using `classes` is fine.

So, after removing the support for es6 we lost the ability to require modules through `import`. In a more complex application I fear the migration wouldn't be so easy. You can find the code from this iteration on [step-2](https://github.com/ramiel/js-back-to-the-roots/tree/step-2)

## The art of removing a react transpiler

React offers a great tool to interact with its virtual DOM, `JSX`. With JSX you can disguise javascript code as html-like elements.

So you can write

```jsx
<MyButton color="blue" shadowSize={2}>
  Click Me
</MyButton>
``` 

instead of

```js
React.createElement(
  MyButton,
  {color: 'blue', shadowSize: 2},
  'Click Me'
)
```    

Let's see how difficult is to remove react support on our webpack configuration. As expected, webpack is complaining for not understanding JSX

```jsx
       9 | 
      10 | render(
    > 11 |   <Provider store={store}>
         |   ^
      12 |     <App />
      13 |   </Provider>,
      14 |   document.getElementById('root')
``` 

We have to change all the JSX. For example this simple code

```jsx
render(
  <Provider store={store}>
    <App />
  </Provider>,
  document.getElementById('root')
)
```

became this

```js
const element = React.createElement(
  Provider,
  {store},
  React.createElement(App, null)
)
render(
  element,
  document.getElementById('root')
)
```
    

which is not complex. But can became a nightmare. To mitigate this task you can use [the online Babel compiler](https://babeljs.io/repl/#?babili=false&amp;evaluate=true&amp;lineWrap=false&amp;presets=es2015%2Creact%2Cstage-0&amp;code=function%20hello()%20%7B%0A%20%20return%20%3Cdiv%3EHello%20world!%3C%2Fdiv%3E%3B%0A%7D) which will translate for you any JSX into the relative clean JS code.

You cannot let the compiler do everything for you or you'll end with complex function like this

```js
React.createElement(
  'a',
  { href: '#',
    onClick: (function (_onClick) {
      function onClick (_x) {
        return _onClick.apply(this, arguments)
      }

      onClick.toString = function () {
        return _onClick.toString()
      }

      return onClick
    }(function (e) {
      e.preventDefault()
      onClick()
    }))
  },
  children
)
```   

which can be written

```js
React.createElement(
  'a',
  { href: '#',
    onClick: e => {
      e.preventDefault()
      onClick()
    }
  },
  children
)
```
    

Maybe it's easier to write code from scratch than adapting existing JSX code. It's hard in any case. On the opposite, maybe this will enforce you to write simpler components and to separate more, in order to have cleaner code.

You can find the new code on [step-3](https://github.com/ramiel/js-back-to-the-roots/tree/step-3)

## Thank you babel, I'll include modules by myself

We are almost up. We just need to remove babel (and then webpack, which became useless). Removing babel and its loaders means we cannot use anymore require to include code and manage dependencies. We'll need to include all the external libraries through `script` tags and the same for all of our scripts.

Ok, let's remove `webpack.config.js` and `package.json`. We won't need them anymore.

We need to include our script directly in the html page (like at my grandma's times) but we have no bundle anymore. Let's include index.js and let see what happens. I moved it under `public/js` folder, just to follow an ancient convention ;)

`<script type="text/javascript" src="js/index.js"></script>`

I will continue to serve the page through a web server to avoid browser complaining. For this I'll use `http-server`, a static file server written in node. You can use nginx or what you prefer.

```bash
npm install http-server -g
http-server public
``` 

If you open your devtools you'll notice that the browser is complaining about the `require` function which is not defined in the environment. As we said, we need to import our libraries differently.

Our project depends on a bunch of libraries:

- react
- react-dom
- redux
- react-redux

we can download them and include in our project but we're lucky enough and all are served by a [CDN](https://cdnjs.com/libraries/react/#).

So now this is our index.html

```html
<script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/react/15.3.2/react.min.js"></script>
<script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/react/15.3.2/react-dom.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/redux/3.6.0/redux.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/react-redux/4.4.5/react-redux.min.js"></script>
```

and this the index.js

```js
const React = window.React
const { render } = window.ReactDOM
const { createStore } = window.Redux
const { Provider } = window.ReactRedux
...
``` 

We need to include our javascript files too. The first required is App.js. Here the boring work of transforming all the require as we did in `index.js` and to include the file as a script in the html page. I already miss webpack which did all of this job for me. Another thing you should do is to wrap every module in an autocalling function. This is, for example, `App.js` after the restiling.

```js
;(function (window) {
  const React = window.React
  const Footer = window.Footer
  const AddTodo = window.AddTodo
  const VisibleTodoList = window.VisibleTodoList

  class App extends React.Component {
    render () {
      return React.createElement(
            'div',
            null,
            React.createElement(AddTodo, null),
            React.createElement(VisibleTodoList, null),
            React.createElement(Footer, null)
        )
    }
    }

  window.App = App
})(window)
```  

Here the inclusion order is important. At the end of the operation this is my body

```html
<body>
    <div id="root"></div>
    <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/react/15.3.2/react.js"></script>
    <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/react/15.3.2/react-dom.js"></script>
    <script src="https://cdnjs.cloudflare.com/ajax/libs/redux/3.6.0/redux.js"></script>
    <script src="https://cdnjs.cloudflare.com/ajax/libs/react-redux/4.4.5/react-redux.js"></script>

    <script type="text/javascript" src="js/actions/index.js"></script>
    <script type="text/javascript" src="js/components/Link.js"></script>
    <script type="text/javascript" src="js/containers/FilterLink.js"></script>
    <script type="text/javascript" src="js/components/Footer.js"></script>
    <script type="text/javascript" src="js/containers/AddTodo.js"></script>
    <script type="text/javascript" src="js/components/Todo.js"></script>
    <script type="text/javascript" src="js/components/TodoList.js"></script>
    <script type="text/javascript" src="js/containers/VisibleTodoList.js"></script>
    <script type="text/javascript" src="js/reducers/todos.js"></script>
    <script type="text/javascript" src="js/reducers/visibilityFilter.js"></script>
    <script type="text/javascript" src="js/reducers/index.js"></script>

    <script type="text/javascript" src="js/components/App.js"></script>
    <script type="text/javascript" src="js/index.js"></script>
</body>
```   

scary eh?!

Give a look at the complete code on [step-4](https://github.com/ramiel/js-back-to-the-roots/tree/step-4)

What you loose here is the ability to handle namespace collision. Is up to you to be sure no module collides, on declaring a name, with another.

## Conclusion

It has been a long trip. I'm happy, at the end I've been able to re-write the todo application as in the '90! It's a bit strange, especially to see all the list of scripts inclusion. Luckily we don't have to do it anymore! It would be amazing if the browsers could [handle this natively](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import)!

Probably, coding this way, force us to put more code in the same file. Maybe a single file to handle the entire application. On the opposite, having the modularity part of javascript, let us write more ordered code, to think more schematically and to better organize our ideas.

Another thing which appears clear (and believe me, is not evident), is that, if we end up with those strange build system, there is a reason. It's the result of a need.

What looks less true instead, is the belief that we need a transpiler to play with all the modern javascript: it's not true, modern browsers can handle the majority of the code. The inclusion of the stage-0 module then, looks a bit overestimated. Probably we can remain with ES6 code without loosing so much expressivity without ES7. If you need to support (not too) old browsers, you cannot avoid to use babel to transpile your code. For example it is absolute mandatory in order to support IE11. Remember, this article don't want to demonstrate that webpack/babel are useless because, at the end, they are your best friends in the jungle that the browser's javascript implementation has always been.

*Many thanks to Jozsef for helping me to write this little story*


Back to the roots of javascript


### Premise

Recently, while we were developing an API in node, some of my colleagues come to me saying that the dependency injection pattern I was using until that moment wasn't useful on our project. They give me a lot of reasons then. Before going to talk about those reasons maybe it worth to give some background.

### Dependency injection

I don't want to explain what dependency injection is or this article will became too long so I let someone better than me to do it: you can give a look at this [article](http://fabien.potencier.org/what-is-dependency-injection.html) by [Fabien Potencier](http://fabien.potencier.org/). It talks about DI in PHP and then, more specifically on symfony but is a very good reading. Of course you can find plenty of article which explain the same mechanism on javascript. I personally find very well written the chapter on the book [Node.js design Patterns](https://www.packtpub.com/web-development/nodejs-design-patterns) by Mario Casciaro.

Dependency injection is the starting point for a more complicated inversion of control scenario but it is a good starting point (and a simple one) to gain a lot in your code, without much effort.

### The arguments

Here a list of arguments I received why I should stop doing DI and I should start something different. I report here the arguments in a non particular order.

1. **In javascript you don't need DI because the language itself permit you to change anything (they refer to any object) without any particular problem.**

Well, even if you can do something this doesn't mean you should.

The reason behind this argument come from the fact that DI help you to have a more testable code and in javascript you don't need DI to obtain this result.

Let's take this code which use DI.

```js
class UserBusiness{
    constructor(userModel){
        this.userModel = userModel;
    }

    buildAndSave(cb){
        /* stuff... */
        this.userModel.save(this, cb);
    }
}

// Somewhere else

const UserModel = require('UserModel');
let b = new UserBusiness(new UserModel());
```

So in this case we have a business object which use a  usermodel to persist data on a DB. With DI you can easily write unit tests for this business class injecting a mock for the `userModel`, so in the test module you'll have something similar:

```js
var userModelInstance = require('userModelMock');
b = new UserBusiness(userModelInstance);
```   

In the mock you'll have a fake `save` method which do nothing, just call the passed callback (we can complicate it but let's stay it simple like this).

Now let's examine the same example without DI

```js
const UserModel = require('UserModel');
class UserBusiness{
    constructor(){
        this.userModel = new UserModel();
    }

    buildAndSave(cb){
        /* stuff... */
        this.userModel.save(this, cb);
    }
}
```    

What is you want to write an unit test for this business class? Here what they suggest:

```js
const UserModel = require('UserModel');
UserModel.prototype.save = function(data, cb){
    cb();
}
b = new UserBusiness();
```  

So we're using this concept "in javascript you can modify any object". The problem is that you have to do it in any test when you need to mock the model. Even if this works we must notice two important things:

- we need to know how UserModel is coded and so we have to hope it have a simply modifiable code like in the former example
- we are relying on the particular implementation of `require` which is a bad practice.

You can understand why the first reason can be a problem. I'll explain why rely on the require implementation can be a problem soon.

*note: you can obtain the same result using libraries like [proxyquire](https://www.npmjs.com/package/proxyquire), the result is not far from this*

1. **If you're using DI to have always the same instance of something on all your application you can use a singleton instead**

This arguments comes from the fact that this people thinks I'm using DI to just share the same instance of something across all my application, which is partially false.

Let's say we have a module which handle the connection to the DB and it is the only entrypoint to have a DB connection. Probably I'll inject an instance of this component to all others components which needs an access to the DB. Then, the fact that I need just *one* instance is not a natural consequence but let's agree with my folks and let's pretend it.

They're solution is the following: instead of inject an instance to any other components, just create a file which exports an instance and use it to obtain a singleton.

This leads to two problems:

- Your project is wasted of files which exports a singleton
- You're still relying on `require` implementation to obtain a singleton.

This looks very bad. The smarter among you (so everybody) have already noticed that is actually not needed to create an additional file while you can simply expose a function which give you a singleton. Here is how you can use such implementation:

```js
const DbComponent = require('DbComponent');
const dbComponentInstance = DbComponent.getSingleton();

/* any code you want... */
```

The problem about this is that is hard to test this connection component with different configurations. You'll always have to mock the `getSingleton` function to change the instance based on a different configuration.

You're even creating a singleton when is not needed at all, just to solve a problem you created!

1. **Require is actually an implementation of a dependency container**

Mario Casciaro explains very well why this is potentially false and which problem you can find but let see this specific one

```js
var Server = function(logger){
    this.logger = logger
    this.logger.debug('Instantiated server');
}
```    

In this simple constructor I'm using DI to inject the logger. The code without DI looks like this:

```js
const loggerConfig = require('loggerConfig');
const logger = new Logger(loggerConfig);
var Server = function(){
    logger.debug('Instantiated server');
}
``` 

I had then the needs to launch the server with a different log level based on a parameter passed from the command line (let's pretend this ok?). So:

```js
var loggerConfig = require('loggerConfig');
loggerConfig.level = isVerbose ? 'debug' : 'error';
const Server = require('Server');
new Server();
```

The problem here is

- What happens if you put the line 3 above the line 2?

This code won't work anymore because the Logger implementation do not react to a later change of the configuration passed to its constructor (it's like this for real for example with Bunyan). This code is far more manageable with the DI version where the instantiations becomes like this:

```js
var loggerConfig = require('loggerConfig');
loggerConfig.level = isVerbose ? 'debug' : 'error';
const Logger = require('Logger');
const logger = new Logger(loggerConfig);
const Server = require('Server');
new Server(logger);
```

The requiring order becomes natural because DI force you to think about which component is needed to create another one.

Then we finally come to why it's a bad idea to rely on the require implementation (others than what already explained). You can use `require` as a dependency container or a singleton provider because internally `require` implement a cache system. Even if this is unlikely to change you should not rely on this fact. Then, that cache system is based on the absolute path of a module which leads to several problems when the same module is provided by different submodule (and so potentially stored under different absolute paths).

1. **DI is not elegant**

Ok, I should not answer to this, really. By the way even if DI is not elegant it apports so many advanteges taht maybe we can stop arguing on what is elegant and what not!

In any case I showed you here a very simple implementation of DI which probably is called `contructor injection`. There are a lot of ways to make it more complicated (dependency resolution), maybe more elegant (dependency injection containers) and other patterns. Just remembers that those patterns are decoration over the simply DI which is always the base to obtain testability and separation of your code

### Conclusions

It's DI going to solve all of my problems? Of course not. Just remember about it because probably it solves some problems you may find and you really do not need to reinvent the wheel.

For the love of truth I have to say I love arguing with my friends about this subjects so I have to say thanks to them afterall!


Why you probably want dependency injection on node.js


It's time to write the guitar tab for this:

<a href="https://tabs.ultimate-guitar.com/tab/cappello-a-cilindro/camera-con-vista-sul-ritorno-chords-1463817" target="__blank">Guitar tab</a>


Camera con vista sul ritorno


## The problem
 Making server to server requests is a common task. You might want to call remote REST services or download  content from other servers. Sometimes instead you want to download large data, such as images or large text files, requesting it directly from your php code. In this scenario you should take care of php script execution limitation expressed in memory and time allowed by your server configuration. Some time you're _even using wordpress_ and its high level interface ([wp\_remote\_request](http://codex.wordpress.org/Function_Reference/wp_remote_request)). What if you've to use wp_remote_request to download a big file in a server to server request? How to avoid a classic error like the one below? 

```php
PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 229901081 bytes)
```
## Some approaches
The reason to keep using to wp\_remote\_request, or wp\_remote\_get or wp\_remote\_post etc., is that your application runs behind a proxy and you want just a single place to configure it, and it has to be at wordpress level. So, the prerequisite is that we have to use wp_remote_request family function. This family functions uses, under the hood, three transports:  curl, streams and fsockopen. All of those transports are implemented in three wordpress   classes and should work the same way, so I'll ignore transport dependant variations. When you download content server side you're code looks like this

```php
$args = array( 'timeout' => 30, 'blocking' => true, 'user-agent' => 'Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:25.0) Gecko/20100101 Firefox/25.0' ); 
$url = 'http://www.otherserver.com/image_very_big.jpg';
$response = wp_remote_get($url, $args);
```

We'are sayng to worpdpress to make a server-to-server request to url defined in $url with arguments. Once we have the response we could retrieve the image and write it onto a file: 

```php
if(! ($response instanceof \WP_Error) ){ 
   $fp = fopen('/path/to/save/file.jpg', "w"); 
   if($fp === false){ 
       return null;
   } 
   fwrite($fp, $response['body']); 
   fclose($fp); 
}
```
The problem here is that, if the file is too big the $response['body'] properties can not contain it, generating the error about too much memory requested. Diving into wordpress code you can land in front of wp\_remote\_request parameters, and you can take a look to 'stream' and 'filename' parameters. On wordpress codex site this two parameters are not documented anywhere or, at least, I wasn't able to find them. They work this way anyway. If you specify: 

```php
$args['stream'] = true; 
$args['filename'] = '/path/to/download/file.jpg';
```

wordpress will use the stream opened by cUrl to write the body content directly to 'filename' argument position instead of populate the body response parameter (see [this](http://core.trac.wordpress.org/browser/tags/3.7.1/src/wp-includes/class-http.php#L1333)). In particular it skips the following line of code:

```php
$this->body .= $data;
```

which is evil! So let's rewrite our code with some fallbacks: 

```php
$attachment_download_path = '/path/to/download/file.jpg'; 
$args['stream'] = true; 
$args['filename'] = $attachment_download_path; $response = wp_remote_get($url, $args); 
if($response instanceof \WP_Error){ 
    $args['stream'] = false; 
    $args['filename'] = null; 
    $response = wp_remote_get($url, $args);
    if($response instanceof \WP_Error){ 
        return null; 
    } 
    $fp = fopen($attachment_download_path, "w");
    if($fp === false){ 
        return null; 
    } 
    fwrite($fp, $response['body']); 
    fclose($fp); 
}
```

If new approach actual download the file everything is ok, otherwise just use old approach and read the body of the response (which can fail of course!). 

## Problems, again
This approach is error prone too. The problem is that, if you specify 'blocking' parameter to false, your file will not be downloaded at all, at least in wordpress 3.6. The 'blocking' parameter, according to documentation act as follow: 

```
The 'blocking' argument allows you to trigger a non-blocking request. The default is true; setting it to false will generally allow PHP to continue execution while the transport is working. The key is that when you set blocking to false, then it will just send the request and won't bother you with the details. This is useful for sending a POST request, where you aren't concerned with whether it succeeded or not, or if you don't want to slow down the processing time of the page. (Note that not all the transports support non-blocking requests, and so you may still be blocked anyway. The alternative of setting an ultra-low timeout is not recommended, since low timeouts may cause the request to not be sent at all with some transports.)
```

I don't know how to expect this to work with stream parameter set to true.  Wordpress code does not download the response if blocking is set to true and I believe this is the right thing to do, according to documentation. So, if you want to use streams to download large file, your request needs to be blocking.


Using streams in wordpress http requests


I'm a web developer. With no time to develop a website of mine!

> But I need one for sure , so let's this wordpress.com do the work for me!

When yesterday I said that I should have known that I would develop it all night! Well, welcome everyone!


Ramiel's Creations