From f1db0b3c848d2189abc228e03275c6d96898570f Mon Sep 17 00:00:00 2001 From: David Di Biase Date: Sun, 4 Jul 2021 12:43:54 -0400 Subject: [PATCH 1/4] Started first translation document --- documentation/it/guides/getting-started.md | 112 +++++++++++++++++++++ 1 file changed, 112 insertions(+) create mode 100644 documentation/it/guides/getting-started.md diff --git a/documentation/it/guides/getting-started.md b/documentation/it/guides/getting-started.md new file mode 100644 index 000000000..396ca003a --- /dev/null +++ b/documentation/it/guides/getting-started.md @@ -0,0 +1,112 @@ +# Iniziare + +## Prova Solid + +Il modo migliore per imparare Solid è provarlo online. Il nostro REPL su https://playground.solidjs.com è il modo perfetto per sperimentare i concetti fondamentali. Così come https://codesandbox.io/ dove puoi modificare uno qualsiasi dei nostri esempi. + +In alternativa, puoi utilizzare i nostri semplici modelli [Vite](https://vitejs.dev/) eseguendo questi comandi nel tuo terminale: + +```sh +> npx degit solidjs/templates/js my-app +> cd mia-app +> npm i # o yarn o pnpm +> npm run dev # o yarn o pnpm +``` + +O per TypeScript: + +```sh +> npx degit solidjs/templates/ts my-app +> cd mia-app +> npm i # o yarn o pnpm +> npm run dev # o fyarn o pnpm +``` + +## Impara Solido + +Il solido è composto da piccoli pezzi componibili che fungono da elementi costitutivi nelle applicazioni. Questi pezzi sono per lo più funzioni che costituiscono molte API superficiali di alto livello. Fortunatamente, non avrai bisogno di conoscerne la maggior parte per iniziare con la libreria. + +I due principali tipi di blocchi a tua disposizione sono i componenti e le primitive reattive. + +I componenti sono funzioni che accettano un oggetto di props e restituiscono elementi JSX inclusi elementi DOM nativi e altri componenti. Possono essere espressi come elementi JSX in PascalCase: + +```jsx +function MyComponent(props) { + return
Ciao {props.name}
; +} + +; +``` + +I componenti sono leggeri. Non sono stateful di per sé e non hanno istanze. Servono invece come funzioni di fabbrica per gli elementi DOM e le primitive reattive. + +La reattività a grana fine è costruita su 3 semplici primitive: Segnali, Memo ed Effetti. Insieme, formano un motore di sincronizzazione con tracciamento automatico che garantisce che la tua vista rimanga aggiornata. I calcoli reattivi assumono la forma di semplici espressioni con wrapping di funzioni che vengono eseguite in modo sincrono. + +```js +const [first, setFirst] = createSignal("JSON"); +const [last, setLast] = createSignal("Bourne"); + +createEffect(() => console.log(`${first()} ${last()}`)); +``` + +Puoi saperne di più su [Reattività di Solid](https://www.solidjs.com/docs/latest#reactivity) e [Rendering di Solid](https://www.solidjs.com/docs/latest#rendering). + +## Pensa in modo Solid + +Il design di Solid contiene diverse opinioni su quali principi e valori ci aiutano a costruire al meglio siti Web e applicazioni. È più facile imparare e utilizzare Solid quando si è consapevoli della filosofia alla base. + +### 1. Dati dichiarativi + +Declarative data combines the description of data’s behavior to its declaration. This allows for easy composition by packaging all aspects of data’s behavior in a single place. + +### 2. Componenti a scomparsa + +È piuttosto difficile strutturare i componenti senza prendere in considerazione gli aggiornamenti. Gli aggiornamenti Solid sono completamente indipendenti dai componenti. Le funzioni componenti vengono chiamate una volta e poi cessano di esistere. Esistono componenti per organizzare il tuo codice e non molto altro. + +### 3. Lettura/scrittura + +Precise control and predictability make for better systems. We don't need true immutability to enforce unidirectional flow, only the ability to make the conscious decision which consumers may write and which may not. + +### 4. Semplice è meglio che facile + +Ecco una lezione che viene dalla reattività a grana fine. Vale la pena avere convenzioni esplicite e coerenti anche se richiedono uno sforzo maggiore. Lo scopo è fornire strumenti minimi che servano come base su cui costruire. + +## Web Components + +Solid nasce con il desiderio di avere Web Components come cittadini di prima classe. Nel tempo il suo design si è evoluto e gli obiettivi sono cambiati. Tuttavia, Solid è ancora un ottimo modo per creare Web Components. [Solid Element](https://github.com/solidjs/solid/tree/main/packages/solid-element) consente di scrivere e avvolgere i componenti funzione di Solid per produrre componenti Web piccoli e performanti. All'interno delle app Solid Solid Element è ancora in grado di sfruttare l'API di contesto di Solid e Solid Portals supportano lo stile isolato Shadow DOM. + +## Rendering del server + +Solid ha una soluzione di rendering lato server dinamico che fornisce un'esperienza di sviluppo veramente isomorfa. Attraverso l'uso della nostra primitiva Resource, le richieste di dati asincroni vengono facilmente effettuate e automaticamente serializzate e sincronizzate tra client e browser. + +Poiché Solid supporta il rendering asincrono e in streaming sul server, puoi scrivere il tuo codice in un modo e farlo eseguire sul server. Ciò significa che funzionalità come [render-as-you-fetch](https://reactjs.org/docs/concurrent-mode-suspense.html#approach-3-render-as-you-fetch-using-suspense) e code splitting funzionano solo in Solid. + +Per maggiori informazioni, leggi la [Guida al server](https://www.solidjs.com/docs/latest#server-side-rendering). + +## Nessuna compilazione? + +Non ti piace JSX? Non ti dispiace fare il lavoro manuale per avvolgere le espressioni, prestazioni peggiori e avere pacchetti di dimensioni maggiori? In alternativa, puoi creare un'app Solid usando Tagged Template Literals o HyperScript in ambienti non compilati. + +Puoi eseguirli direttamente dal browser utilizzando [Skypack](https://www.skypack.dev/): + +```html + + + + + +``` + +Ricorda che hai ancora bisogno della corrispondente libreria di espressioni DOM affinché funzionino con TypeScript. È possibile utilizzare i valori letterali dei modelli con tag con le espressioni Lit DOM o HyperScript con le espressioni Hyper DOM. From be6e766e5bf7d85f5ae52a4c5e1a881ceef6db4f Mon Sep 17 00:00:00 2001 From: David Di Biase Date: Mon, 12 Jul 2021 10:08:56 -0400 Subject: [PATCH 2/4] Completed translating guide section --- documentation/it/guides/getting-started.md | 6 +- documentation/it/guides/reactivity.md | 95 +++++++ documentation/it/guides/rendering.md | 277 +++++++++++++++++++++ documentation/it/guides/server.md | 135 ++++++++++ 4 files changed, 510 insertions(+), 3 deletions(-) create mode 100644 documentation/it/guides/reactivity.md create mode 100644 documentation/it/guides/rendering.md create mode 100644 documentation/it/guides/server.md diff --git a/documentation/it/guides/getting-started.md b/documentation/it/guides/getting-started.md index 396ca003a..c0402cfe0 100644 --- a/documentation/it/guides/getting-started.md +++ b/documentation/it/guides/getting-started.md @@ -22,9 +22,9 @@ O per TypeScript: > npm run dev # o fyarn o pnpm ``` -## Impara Solido +## Impara Solid -Il solido è composto da piccoli pezzi componibili che fungono da elementi costitutivi nelle applicazioni. Questi pezzi sono per lo più funzioni che costituiscono molte API superficiali di alto livello. Fortunatamente, non avrai bisogno di conoscerne la maggior parte per iniziare con la libreria. +Il Solid è composto da piccoli pezzi componibili che fungono da elementi costitutivi nelle applicazioni. Questi pezzi sono per lo più funzioni che costituiscono molte API superficiali di alto livello. Fortunatamente, non avrai bisogno di conoscerne la maggior parte per iniziare con la libreria. I due principali tipi di blocchi a tua disposizione sono i componenti e le primitive reattive. @@ -99,7 +99,7 @@ Puoi eseguirli direttamente dal browser utilizzando [Skypack](https://www.skypac const App = () => { const [counteggio, impostatoConteggio] = createSignal(0), - timer = setInterval(() => setCount(counteggio() + 1), 1000); + timer = setInterval(() => setConteggio(counteggio() + 1), 1000); onCleanup(() => clearInterval(timer)); return html`
${counteggio}
`; }; diff --git a/documentation/it/guides/reactivity.md b/documentation/it/guides/reactivity.md new file mode 100644 index 000000000..65bd18709 --- /dev/null +++ b/documentation/it/guides/reactivity.md @@ -0,0 +1,95 @@ +# Reattività + +La gestione dei dati in Solid utilizza primitive reattive che sono responsabili di tutti gli aggiornamenti. Utilizza un approccio molto simile a MobX o Vue, tranne per il fatto che non scambia mai la sua granularità con un VDOM. Le dipendenze vengono tracciate automaticamente quando accedi ai tuoi valori reattivi in Effetti e codice JSX. + +Le primitive di Solid sono chiamate `create` che spesso restituiscono tuple. Generalmente il primo elemento è una primitiva leggibile e il secondo è un setter. È comune riferirsi solo alla parte leggibile con il nome primitivo. + +Ecco un contatore di incremento automatico di base che si aggiorna in base all'impostazione del segnale `count`. + +```jsx +import { createSignal, onCleanup } from "solid-js"; +import { render } from "solid-js/web"; + +const App = () => { + const [counteggio, setCounteggio] = createSignal(0), + timer = setInterval(() => setCounteggio(counteggio() + 1), 1000); + onCleanup(() => clearInterval(timer)); + + return
{counteggio()}
; +}; + +render(() => , document.getElementById("app")); +``` + +## Presentazione dei primitivi + +Solid è costituito da 3 primitive primarie, Segnale, Memo ed Effetto. Al centro c'è il pattern Observer in cui i segnali (e i promemoria) vengono tracciati avvolgendo i promemoria e gli effetti. + +I segnali sono la primitiva più semplice. Contengono valore e ottengono e impostano funzioni in modo da poter intercettare quando vengono letti e scritti. + +```js +const [counteggio, setCounteggio] = createSignal(0); +``` + +Gli effetti sono funzioni che forniscono letture del nostro segnale. Viene eseguito nuovamente ogni volta che il valore di un segnale dipendente cambia. Questo è utile per creare effetti collaterali, come il rendering. + +```js +createEffect(() => console.log("L'ultimo conteggio è ", counteggio())); +``` + +Infine, i Memo sono valori derivati memorizzati nella cache. Condividono le proprietà di entrambi i segnali e gli effetti. Tracciano i propri segnali dipendenti, rieseguendoli solo quando questi cambiano e sono essi stessi segnali tracciabili. + +```js +const nome = createMemo(() => `${nomeBattsimo()} ${cognome()}`); +``` + +## Come funziona + +I segnali sono emettitori di eventi che contengono un elenco di abbonamenti. Notificano ai loro abbonati ogni volta che il loro valore cambia. + +Dove le cose si fanno più interessanti è come avvengono questi abbonamenti. Solid utilizza il monitoraggio automatico delle dipendenze. Gli aggiornamenti avvengono automaticamente quando i dati cambiano. + +Il trucco è uno stack globale in fase di esecuzione. Prima che un Effetto o Memo esegua (o riesegui) la sua funzione fornita dallo sviluppatore, si spinge su quello stack. Quindi qualsiasi segnale che viene letto controlla se c'è un listener corrente nello stack e in tal caso aggiunge il listener alle sue sottoscrizioni. + +Puoi pensarla così: + +```js +function createSignal(value) { + const iscritti = new Set(); + + const leggere = () => { + const listener = getCurrentListener(); + if (listener) iscritti.add(listener); + return valore; + }; + + const scrivi = nextValue => { + valore = valoreSuccessivo; + for (const isc of iscritti) isc.run(); + }; + + return [read, scrivi]; +} +``` + +Ora ogni volta che aggiorniamo il segnale sappiamo quali effetti eseguire nuovamente. Semplice ma efficace. L'effettiva implementazione è molto più complicata, ma questo è il succo di ciò che sta accadendo. + +Per una comprensione più dettagliata di come funziona Reattività, questi sono articoli utili (in inglese): + +[A Hands-on Introduction to Fine-Grained Reactivity](https://dev.to/ryansolid/a-hands-on-introduction-to-fine-grained-reactivity-3ndf) + +[Building a Reactive Library from Scratch](https://dev.to/ryansolid/building-a-reactive-library-from-scratch-1i0p) + +[SolidJS: Reactivity to Rendering](https://indepth.dev/posts/1289/solidjs-reactivity-to-rendering) + +## Considerazioni + +Questo approccio alla reattività è molto potente e dinamico. Può gestire le dipendenze che cambiano al volo eseguendo diversi rami di codice condizionale. Funziona anche attraverso molti livelli di indiretto. Viene tracciata anche qualsiasi funzione eseguita all'interno di un ambito di tracciamento. + +Ci sono alcuni comportamenti chiave e compromessi di cui dobbiamo essere consapevoli. + +1. Tutta la reattività viene tracciata direttamente dalle chiamate di funzione. Possono anche essere nascosti sotto getter/proxy e attivati ​​dall'accesso alla proprietà. Ciò significa che è importante dove si accede alle proprietà sugli oggetti reattivi. + +2. I componenti ei callback dai flussi di controllo non tengono traccia degli ambiti. Eseguono solo una volta. Ciò significa che la destrutturazione o l'esecuzione della logica di primo livello nei componenti non verrà rieseguita. È necessario accedere a questi segnali, negozi e oggetti di scena dall'interno di altre primitive reattive o JSX per quella parte del codice da rivalutare. + +3. Questo approccio tiene traccia solo in modo sincrono. Se hai un setTimeout o usi una funzione asincrona nel tuo effetto, verrà eseguito asincrono. Quindi non verrà più tracciato. diff --git a/documentation/it/guides/rendering.md b/documentation/it/guides/rendering.md new file mode 100644 index 000000000..7f8d1ac87 --- /dev/null +++ b/documentation/it/guides/rendering.md @@ -0,0 +1,277 @@ +# Rendering + +Solid supporta 3 tipi di template: JSX, Tagged Template Literals e la variante HyperScript di Solid. JSX è la forma predominante. Perché? JSX è un ottimo DSL creato per la compilazione. Ha una sintassi chiara, supporta TypeScript, funziona con Babel e supporta altri strumenti come l'evidenziazione della sintassi del codice e più carino. Era solo pragmatico usare uno strumento che fondamentalmente ti dà tutto gratuitamente. Come soluzione compilata fornisce un ottimo DX. Abbiamo scelto di non lottare con le sintassi DSL personalizzate e di usarne una ampiamente supportata. + +## Compilazione JSX + +Il rendering prevede la precompilazione di modelli JSX in codice js nativo ottimizzato. I costrutti del codice JSX sono: + +- Elementi template DOM (clonati su ogni istanza) +- Una serie di dichiarazioni di riferimento che utilizzano solo firstChild e nextSibling +- Calcoli a grana fine per aggiornare gli elementi creati. + +Questo approccio è più performante e produce meno codice rispetto alla creazione di ogni elemento individualmente con document.createElement. + +## Attributi e oggetti di scena + +Tentativi solidi di seguire il più possibile le convenzioni HTML, inclusa l'insensibilità alle maiuscole degli attributi. + +La maggior parte di tutti gli attributi sull'elemento nativo JSX sono impostati come attributi DOM. I valori statici sono incorporati direttamente nel modello clonato. Ci sono un certo numero di eccezioni come `class`, `style`, `value`, `innerHTML` che forniscono funzionalità extra. + +Gli elementi personalizzati (ad eccezione dei built-in nativi) sono predefiniti come proprietà quando sono dinamici. Questo serve per gestire tipi di dati più complessi. Esegue questa conversione in base ai nomi degli attributi dei casi di serpente standard dell'involucro del cammello da `some-attr` a `someAttr`. + +È anche possibile controllare questo comportamento direttamente con le direttive dello spazio dei nomi. Puoi forzare un attributo con `attr:` o `prop:` + +```jsx + +``` + +> **Nota:** gli attributi statici vengono creati come parte del modello html che viene clonato. Le espressioni fisse e dinamiche vengono applicate successivamente nell'ordine di associazione JSX. Questo va bene per la maggior parte degli elementi DOM ma ce ne sono alcuni, come gli elementi di input con `type='range'`, dove l'ordine conta. Ricordalo quando leghi gli elementi. + +## Entrata + +Il modo più semplice per montare Solid è importare il rendering da 'solid-js/web'. `render` riceve una funzione come primo argomento e l'elemento di montaggio per il secondo. Restituirà un metodo di smaltimento. Questo `render` crea automaticamente la radice reattiva e gestisce il rendering nel contenitore di montaggio. Per prestazioni ottimali, utilizzare un elemento senza figli. + +```jsx +import { render } from "solid-js/web"; + +render(() => , document.getElementById("main")); +``` + +> **Importante** Il primo argomento deve essere una funzione. In caso contrario, non possiamo tracciare e programmare correttamente il sistema reattivo. Se lo fai in modo errato, i tuoi effetti non verranno eseguiti. + +## Componenti + +I componenti in Solid sono solo funzioni in maiuscolo Pascal. Il loro primo argomento è un oggetto props e restituiscono nodi DOM reali. + +```jsx +const Primo = () => ( +
+ +
Davide
+ +
+); + +const Secondo = props => ( + <> +
{props.saluto}
+ {props.children} + +); +``` + +Tutti i nodi JSX sono nodi DOM effettivi. Non c'è magia qui. I componenti di primo livello li aggiungono al DOM stesso. + +## Oggetti di scena + +Solid consente di definire le proprietà sui componenti per passare i dati ai componenti figlio. Questo è simile a React, Vue, Angular e altri framework. Qui un componente genitore sta passando la stringa "Hello" al componente `Label` tramite una proprietà `greeting`. + +```jsx +const Primo = () => ( +
+ +
David
+ +
+); +``` + +Il valore impostato su "saluto" è statico, ma possiamo anche impostare valori dinamici. Per esempio: + +```jsx +const Primo = () => { + const [saluto, impostareSaluto] = createSignal("Buongiorno"); + return ( +
+ +
Davide
+ +
+ ); +}; +``` + +I componenti possono accedere alle proprietà passate loro tramite un argomento `props`. + +```jsx +const Label = props => ( + <> +
{props.greeting}
+ {props.children} + +); +``` + +A differenza di altri framework, non è possibile utilizzare la destrutturazione degli oggetti sui `props` di un componente. Dietro le quinte l'oggetto `props` si basa su Object getter per recuperare pigramente i valori. L'uso della destrutturazione degli oggetti interrompe la reattività degli "sostegni". Questa è una limitazione naturale e accettabile. + +Questo esempio mostra il modo "corretto" di accedere agli oggetti di scena in Solid: + +```jsx +// Qui, `props.name` si aggiornerà come ti aspetteresti +const MioComponentene = props =>
{props.nome}
; +``` + +Questo esempio mostra il modo sbagliato di accedere agli oggetti di scena in Solid: + +```jsx +// Questo è il male +// Qui, `props.name` non si aggiornerà (cioè non è reattivo) poiché è destrutturato in `name` +const MioComponentene = ({ nome }) =>
{nome}
; +``` + +Mentre l'oggetto props sembra un oggetto normale quando lo usi, in realtà è adeguatamente reattivo, in qualche modo simile a un segnale. Questo ha alcune implicazioni. Gli utenti dattiloscritti riconosceranno che è digitato come un normale oggetto. + +A differenza della maggior parte dei framework JSX, i componenti delle funzioni di Solid vengono eseguiti solo una volta (anziché ogni ciclo di rendering). L'esempio seguente non funzionerà come previsto. + +```jsx +import { createSignal } from "solid-js"; + +const ComponenteBase = props => { + const valore = props.value || "predefinita"; + return
{valore}
; +}; + +export default function Modulo() { + const [valore, impostareValore] = createSignal(""); + return ( +
+ + impostareValore(e.currentTarget.value)} /> +
+ ); +} +``` + +In realtà vogliamo che il `ComponenteBase` mostri il valore corrente digitato nell'`input`. Come promemoria, la funzione `ComponenteBase` viene eseguita solo una volta quando il componente viene creato per la prima volta. A questo punto (durante la creazione), `props.valore` sarà uguale a `''`. Ciò significa che il "valore const" in "BasicComponent" si risolverà in "default" e non si aggiornerà mai. L'accesso agli oggetti di scena mentre l'oggetto `props` è reattivo è al di fuori dell'ambito osservabile di Solid. Quindi verrà automaticamente rivalutato quando cambiano gli oggetti di scena. + +Per risolvere il problema dobbiamo accedere a "props" da qualche parte in cui Solid possa osservarlo. Generalmente questo significa all'interno di JSX o all'interno di un `createMemo`, `createEffect` o thunk(`() => ...`). Ecco una soluzione che funziona come previsto: + +```jsx +const ComponenteBase = props => { + return
{props.valore || "predefinita"}
; +}; +``` + +Questo, equivalentemente, può essere issato in una funzione: + +```jsx +const ComponenteBase = props => { + const valore = () => props.valore || "predefinita"; + + return
{valore()}
; +}; +``` + +Un'altra opzione per calcoli costosi è usare `createMemo`. Per esempio: + +```jsx +const ComponenteBase = props => { + const valore = createMemo(() => props.valore || "predefinita"); + + return
{valore()}
; +}; +``` + +O usando un aiutante + +```jsx +const ComponenteBase = props => { + props = mergeProps({ valore: "predefinita" }, props); + + return
{props.valore}
; +}; +``` + +Come promemoria, i seguenti esempi _non_ funzioneranno: + +```jsx +// cattiva +const ComponenteBase = props => { + const { valore: propValore } = props; + const valore = createMemo(() => propValore || "predefinita"); + return
{valore()}
; +}; + +// cattiva +const ComponenteBase = props => { + const propValore = prop.value; + const valore = createMemo(() => valueProp || "predefinita"); + return
{valore()}
; +}; +``` + +I componenti di Solid sono la parte fondamentale delle sue prestazioni. L'approccio di Solid a far scomparire i componenti è reso possibile dalla valutazione pigra degli oggetti. A differenza della valutazione immediata delle espressioni prop e del passaggio di valori, l'esecuzione viene posticipata fino a quando non si accede al prop nel figlio. In questo modo rimandiamo l'esecuzione fino all'ultimo momento, in genere proprio nei binding DOM, massimizzando le prestazioni. Ciò appiattisce la gerarchia ed elimina la necessità di mantenere un albero di componenti. + +```jsx +; + +// compila approssimativamente a: + +// estraiamo il corpo del componente per isolarlo e prevenire costosi aggiornamenti +untrack(() => + Componente({ + prop1: "statica", + // espressione dinamica quindi avvolgiamo in un getter + get prop2() { + return state.dinamica; + } + }) +); +``` + +Per aiutare a mantenere la reattività, Solid ha un paio di aiutanti: + +```jsx +// oggetti di scena predefiniti +props = mergeProps({ name: "Italiano" }, props); + +// clone +const newProps = mergeProps(props); + +// unire +props = mergeProps(props, otherProps); + +// sdividere gli oggetti di scena in più oggetti di scena +const [locale, altre] = splitProps(props, ["className"]) +
+``` + +## Children + +Solid gestisce JSX Children simile a React. Un singolo figlio è un singolo valore su `props.children` e più figli vengono gestiti tramite un array di valori. Normalmente, li passi alla vista JSX. Se vuoi interagire con loro il metodo suggerito è l'helper `figli` che risolve qualsiasi flusso di controllo a valle e restituisce un memo. + +```jsx +// singolo +const Etichetta = (props) =>
Salve, { props.children }
+ +Michele + +// multipla +const List = (props) =>
{props.children}
; + + +
First
+ {state.expression} + Judith + + +// oggetto bambini +const Elenco = (props) =>
    + {articolo =>
  • {itarticoloem}
    • }     +
; + +// mmodificare e mappare i bambini usando l'helper +const Elenco = (props) => { + // l'assistente dei bambini memorizza il valore e risolve tutte le reattività intermedie + const memo = bambini(() => props.children); + createEffect(() => { + const bambini = memo(); + bambini.forEach((c) => c.classList.add("elenco-bambino")) + }) + return
    + {item =>
  • {item}
    • }     +
; +``` + +**Importante:** Solid tratta i tag inferiori come espressioni costose e li racchiude allo stesso modo delle espressioni reattive dinamiche. Valutano pigramente l'accesso "prop". Fai attenzione ad accedervi più volte o a destrutturare prima del punto in cui li useresti nella vista. Solid non ha il lusso di creare nodi DOM virtuali in anticipo e poi di differenziarli. La risoluzione di questi "sostegni" deve essere pigra e deliberata. Usa l'helper `bambini` se desideri farlo mentre li memorizza. diff --git a/documentation/it/guides/server.md b/documentation/it/guides/server.md new file mode 100644 index 000000000..2f0172a3c --- /dev/null +++ b/documentation/it/guides/server.md @@ -0,0 +1,135 @@ +# Server di rendering + +Solid gestisce il rendering del server compilando i modelli JSX in un codice di aggiunta di stringhe ultra efficiente. Questo accade con il plugin o il preset Babel passando in `generate: "ssr"`. Con client e server è necessario passare `hydratable: true` per generare il codice compatibile con l'idratazione. + +I runtime `solid-js` e `solid-js/web` vengono scambiati con versioni non reattive durante l'esecuzione in un ambiente nodo. Per altri ambienti sarà necessario raggruppare il codice del server con esportazioni condizionali impostate su "nodo". La maggior parte dei bundler ha un modo per farlo. Raccomandiamo anche di usare le condizioni di esportazione `solid` così come si consiglia alle librerie di spedire i loro sorgenti sotto l'export `solid`. + +Costruire per SSR richiede sicuramente un po' più di configurazione. Genereremo 2 bundle separati. La voce client dovrebbe usare "idrato": + +```jsx +import { hydrate } from "solid-js/web"; + +hydrate(() => , document); +``` + +_Nota: è possibile renderizzare e idratare dalla radice del documento. Questo ci permette di descrivere la nostra visione completa in JSX._ + +La voce del server può utilizzare una delle quattro opzioni di rendering offerte da Solid. Ciascuno produce l'output e un tag di script da inserire nell'intestazione del documento. + +```jsx +import { + renderToString, + renderToStringAsync, + renderToNodeStream, + renderToWebStream +} from "solid-js/web"; + +// Rendering di stringhe sincrone +const html = renderToString(() => ); + +// Rendering di stringhe asincrone +const html = await renderToStringAsync(() => ); + +// Node Stream API +pipeToNodeWritable(App, res); + +// Web Stream API (come esempio Cloudflare Workers) +const { readable, writable } = new TransformStream(); +pipeToWritable(() => , writable); +``` + +Per semplicità `solid-js/web` esporta un flag `isServer`. Ciò è utile in quanto la maggior parte dei bundler sarà in grado di eseguire il treeshake di qualsiasi cosa sotto questo flag o le importazioni utilizzate solo dal codice sotto questo flag dal tuo bundle client. + +```jsx +import { isServer } from "solid-js/web"; + +if (isServer) { + // solo per server +} else { + // solo nel browser +} +``` + +## Script di idratazione + +Per idratarsi progressivamente direttamente prima del caricamento del runtime di Solid, è necessario inserire uno script speciale nella pagina. Può essere generato e inserito tramite `generateHydrationScript`o incluso come parte di JSX utilizzando il tag ``. + +```js +import { generateHydrationScript } from "solid-js/web"; + +const app = renderToString(() => ); + +const html = ` + + + 🔥 Solid 🔥 + + + + ${generateHydrationScript()} + + ${app} + +`; +``` + +```jsx +import { HydrationScript } from "solid-js/web"; + +const App = () => { + return ( + + + 🔥 Solid 🔥 + + + + + + {/*... resto dell'app */} + + ); +}; +``` + +Fai attenzione quando ti idrati. Anche l'inserimento di risorse che non sono disponibili nell'esecuzione del client può rovinare le cose. Solid fornisce un componente `` i cui figli funzioneranno normalmente sul server. Questo non è per idratare nel browser. + +```jsx + + {manifesta.map(m => ( + + ))} + +``` + +## Asincrono e streaming SSR + +I meccanismi sono costruiti sulla conoscenza di Solid di come funziona la tua applicazione. Usando Suspense e l'API delle risorse sul server, invece di recuperare in anticipo e quindi eseguire il rendering. Solid recupera mentre esegue il rendering sul server in modo simile al client. Il codice e i modelli di esecuzione sono scritti esattamente allo stesso modo. + +Il rendering asincrono attende la risoluzione di tutti i limiti di Suspense. Quindi invia i risultati o li scrive su un file nel caso di Static Site Generation. + +Lo streaming inizia a scaricare il contenuto sincrono nel browser, rendendo immediatamente i tuoi Suspense Fallback sul server. Quindi, quando i dati asincroni terminano sul server, inviano lo stesso flusso al client per risolvere Suspense. Questo è quando il browser termina il lavoro e sostituisce il fallback con contenuto reale. + +Il vantaggio: + +- Il server non deve attendere che i dati asincroni rispondano. Le risorse possono iniziare a caricarsi prima nel browser e l'utente può iniziare a vedere i contenuti prima. +- Rispetto al recupero del client come JAMStack, il caricamento dei dati inizia immediatamente sul server e non deve attendere il caricamento di JavaScript del client. +- Tutti i dati vengono serializzati e trasportati automaticamente dal server al client. + +## Avvertenze SSR + +La soluzione SSR isomorfa di Solid è molto potente. Puoi scrivere il tuo codice principalmente come base di codice singola che funziona in modo simile in entrambi gli ambienti. Tuttavia ci sono aspettative che questo metta su idratazione. Principalmente che la vista renderizzata nel client è la stessa che sarebbe resa sul server. Non ha bisogno di essere esatto in termini di testo. Strutturalmente il markup dovrebbe essere lo stesso. + +Usiamo i marcatori resi nel server per abbinare elementi e posizioni delle risorse sul server. Per questo motivo Client e Server dovrebbero avere gli stessi componenti. Questo non è in genere un problema dato che Solid esegue il rendering allo stesso modo su client e server. Attualmente non esiste un metodo per rendere qualcosa sul server che non si idrata sul client. Non è possibile idratare parzialmente un'intera pagina e non generare indicatori di idratazione per essa. L'idratazione parziale è qualcosa che vogliamo esplorare in futuro. + +Infine, tutte le risorse devono essere definite nell'albero `render`. Vengono automaticamente serializzati e prelevati nel browser. Funziona perché i metodi `render` o `pipeTo` tengono traccia dell'avanzamento del rendering. Non possiamo fare nulla se vengono creati in un contesto isolato. Allo stesso modo non c'è reattività sul server. Non aggiornare i segnali durante il rendering iniziale e aspettarti che si riflettano più in alto nell'albero. Ci sono limiti di Suspense ma l'SSR di Solid viene elaborato dall'alto verso il basso. + +## Iniziare con SSR + +Le configurazioni SSR sono complicate. Abbiamo alcuni esempi nel pacchetto [solid-ssr](https://github.com/solidjs/solid/blob/main/packages/solid-ssr). + +È in lavorazione un nuovo antipasto [SolidStart](https://github.com/solidjs/solid-start) che mira a rendere questa esperienza molto più fluida. + +## Iniziare con la generazione di siti statici + +[solid-ssr](https://github.com/solidjs/solid/blob/main/packages/solid-ssr) viene fornito anche con una semplice utility per la generazione di siti statici o prerenderizzati. Leggi il README per maggiori informazioni. From 06aeabe1911de99bc18964a2b7b7e88acd87978b Mon Sep 17 00:00:00 2001 From: David Di Biase Date: Sat, 17 Jul 2021 18:49:15 -0400 Subject: [PATCH 3/4] Added largest piece of the translation --- documentation/it/api.md | 1308 ++++++++++++++++++++ documentation/it/guides/getting-started.md | 4 +- 2 files changed, 1310 insertions(+), 2 deletions(-) create mode 100644 documentation/it/api.md diff --git a/documentation/it/api.md b/documentation/it/api.md new file mode 100644 index 000000000..17f863e72 --- /dev/null +++ b/documentation/it/api.md @@ -0,0 +1,1308 @@ +# Reattività + +## `createSignal` + +```ts +export function createSignal( + value: T, + options?: { name?: string; equals?: false | ((prev: T, next: T) => boolean) } +): [get: () => T, set: (v: T) => T]; +``` + +La primitiva reattiva più elementare utilizzata per tracciare un singolo valore che cambia nel tempo è createSignal. La funzione create restituisce una coppia di funzioni get e set per accedere e aggiornare il segnale. + +```js +const [leggereValore, assegnaValore] = createSignal(valorePredefinito); + +// assegna il valore con un setter di funzioni +leggereValore(); + +// assegna il valore con un setter di funzioni +assegnaValore(valoreSuccessivo); + +// assegna il valore con un setter di funzioni +assegnaValore(assegnaValore => assegnaValore + successivo); +``` + +Remember to access signals under a tracking scope if you wish them to react to updates. Tracking scopes are functions that are passed to computations like `createEffect` or JSX expressions. + +> Per memorizzare una funzione in un segnale utilizzerai il modulo funzione: +> +> ```js +> assegnaValore(() => ilFunzione); +> ``` + +## `createEffect` + +```ts +export function createEffect(fn: (v: T) => T, value?: T, options?: { name?: string }): void; +``` + +Questo creerà un nuovo calcolo che tiene traccia automaticamente delle dipendenze. Viene eseguito dopo ogni rendering in cui è cambiata una dipendenza. È ideale per l'utilizzo di `ref`s e la gestione di altri effetti collaterali. + +```js +const [a, assegnaA] = createSignal(valorePredefinito); + +// effetto che dipende dal segnale `a` +createEffect(() => altroAffetto(a())); +``` + +La funzione effetto viene chiamata con il valore restituito dall'ultima esecuzione della funzione effetto. Questo valore può essere inizializzato come secondo argomento opzionale. Questo può essere utile per differenziare senza creare una chiusura aggiuntiva. + +```js +createEffect(prev => { + const somma = a() + b(); + if (somma !== prev) console.log(somma); + return somma; +}, 0); +``` + +## `createMemo` + +```ts +export function createMemo( + fn: (v: T) => T, + value?: T, + options?: { name?: string; equals?: false | ((prev: T, next: T) => boolean) } +): () => T; +``` + +Crea un segnale derivato di sola lettura che ricalcola il suo valore ogni volta che le dipendenze del codice eseguito vengono aggiornate. + +```js +const ottenereValore = createMemo(() => calcoloImpegnativo(a(), b())); + +// leggere valore +ottenereValore(); +``` + +La funzione memo viene chiamata con il valore restituito dall'ultima esecuzione della funzione memo. Questo valore può essere inizializzato come secondo argomento opzionale. Questo è utile per ridurre i calcoli. + +```js +const somma = createMemo(somma => input() + somma, 0); +``` + +## `createResource` + +```ts +type ResourceReturn = [ + { + (): T | undefined; + loading: boolean; + error: any; + }, + { + mutate: (v: T | undefined) => T | undefined; + refetch: () => void; + } +]; + +export function createResource( + fetcher: (k: U, getPrev: () => T | undefined) => T | Promise, + options?: { initialValue?: T; name?: string } +): ResourceReturn; + +export function createResource( + source: U | false | null | (() => U | false | null), + fetcher: (k: U, getPrev: () => T | undefined) => T | Promise, + options?: { initialValue?: T; name?: string } +): ResourceReturn; +``` + +Crea un segnale in grado di gestire le richieste asincrone. Il `fetcher` è una funzione asincrona che accetta il valore di ritorno della `sorgente` se fornito e restituisce una Promessa il cui valore risolto è impostato nella risorsa. + +Il recuperatore non è reattivo. Usa il primo argomento opzionale se desideri che venga eseguito più di una volta. Se l'origine si risolve in false, null o undefined, non verrà recuperato. + +```js +const [data, { mutate, refetch }] = createResource(getQuery, fetchData); + +// leggere valore +data(); + +// controlla se stai caricando +data.loading; + +// controlla se sbagli +data.error; + +// impostare direttamente il valore senza creare promesse +mutate(valoreOttmista); + +// recupera l'ultima richiesta solo perché +refetch(); +``` + +"loading" ed "error" sono getter reattivi e possono essere tracciati. + +# Cicli vitali + +## `onMount` + +```ts +export function onMount(fn: () => void): void; +``` + +Registra un metodo che viene eseguito dopo che tutti gli elementi di rendering iniziali sono stati montati. Questo è l'ideale per usare `ref`s e gestire altri effetti collaterali di una volta. È equivalente a un `createEffect` che non ha dipendenze. + +## `onCleanup` + +```ts +export function onCleanup(fn: () => void): void; +``` + +Registra un metodo di pulizia che viene eseguito in caso di eliminazione o ricalcolo dell'ambito reattivo corrente. Può essere utilizzato in qualsiasi componente o effetto. + +## `onError` + +```ts +export function onError(fn: (err: any) => void): void; +``` + +Registra un metodo del gestore degli errori che viene eseguito in caso di errori nell'ambito figlio. Vengono eseguiti solo i gestori di errori di ambito più vicini. Rilancia per attivare la linea. + +# Utilità reattive + +Questi helper offrono la possibilità di pianificare più facilmente gli aggiornamenti. Controllano anche come viene tracciata la reattività. + +## `untrack` + +```ts +export function untrack(fn: () => T): T; +``` + +Ignora il rilevamento delle dipendenze nel blocco di codice in esecuzione e restituisce il valore. + +## `batch` + +```ts +export function batch(fn: () => T): T; +``` + +Trattiene il processo di commit degli aggiornamenti. Qualunque cosa sia dichiarata all'interno del blocco viene conservata fino a quando la funzione non si risolve per evitare ricalcoli non necessari. La lettura dei valori sulle righe successive all'interno del blocco non verrà quindi aggiornata consecutivamente. + +Nota: Solid Store, un modello di dati più avanzato disponibile in Solid, avvolge automaticamente i metodi set ed Effect con batch. + +## `on` + +```ts +export function on any> | (() => any), U>( + deps: T, + fn: (input: T, prevInput: T, prevValue?: U) => U, + options: { defer?: boolean } = {} +): (prevValue?: U) => U | undefined; +``` + +"on" è progettato per essere passato in un calcolo per rendere esplicite le sue dipendenze. Se viene passato un array di dipendenze, allora "input" e "prevInput" saranno array. + +```js +createEffect(on(a, v => console.log(v, b()))); + +// è equivalente a: +createEffect(() => { + const v = a(); + untrack(() => console.log(v, b())); +}); +``` + +Puoi anche impedire l'esecuzione immediata del calcolo. È possibile specificare di assegnare la modifica impostando l'opzione di rinvio su true. + +```js +// non viene eseguito immediatamente +createEffect(on(a, v => console.log(v), { defer: true })); + +setA("new"); // ora funziona +``` + +## `createRoot` + +```ts +export function createRoot(fn: (dispose: () => void) => T): T; +``` + +Crea un nuovo contesto non tracciato. Inoltre non è auto-smaltato. Ciò è utile per i contesti reattivi nidificati che non si desidera rilasciare quando il genitore rivaluta. Questo può essere usato come un potente modello per la memorizzazione nella cache. + +Tutto il codice Solid dovrebbe essere racchiuso in uno di questi livelli superiori in quanto assicurano che tutta la memoria/i calcoli siano liberati. Normalmente non devi preoccuparti di questo dato che `createRoot` è incorporato in tutte le funzioni di immissione di `render`. + +## `mergeProps` + +```ts +export function mergeProps(...sources: any): any; +``` + +Un metodo di "unione" reattivo. È utile per impostare gli oggetti di scena predefiniti per i componenti nel caso in cui il chiamante non li fornisca. È anche utile per clonare l'oggetto props con proprietà reattive. + +Questo metodo funziona utilizzando un proxy e risolvendo le proprietà in ordine inverso. Ciò consente il tracciamento dinamico delle proprietà che non sono presenti quando l'oggetto prop viene unito per la prima volta. + +```js +// proprietà predefinite +props = mergeProps({ nome: "Davide" }, props); + +// proprietà del clone +newProps = mergeProps(proprietà); + +// proprietà unite +props = mergeProps(props, altreProprieta); +``` + +## `splitProps` + +```ts +export function splitProps(props: T, ...keys: Array<(keyof T)[]>): [...parts: Partial]; +``` + +Questo è un sostituto della destrutturazione. Divide un oggetto reattivo per chiavi mantenendo la reattività. + +```js +const [locale, altre] = splitProps(props, ["children"]); + +<> + +
{locale.children}
+ +``` + +## `useTransition` + +```ts +export function useTransition(): [() => boolean, (fn: () => void, cb?: () => void) => void]; +``` + +Utilizzato per eseguire in batch gli aggiornamenti asincroni in una transazione rinviando il commit fino al completamento di tutti i processi asincroni. Questo processo è legato a Suspense e tiene traccia solo delle risorse lette sotto i limiti di Suspense. + +```js +const [sospeso, inizio] = useTransition(); + +// controlla se stai effettuando la transizione +sospeso(); + +// avvolgere in transizione +inizio(() => setSignal(nuovoValore), () => /* la transizione è fatta */) +``` + +## `observable` + +```ts +export function observable(input: () => T): Observable; +``` + +Un metodo che prende un segnale e produce un semplice osservabile. Puoi consumarlo dalla libreria Observable di tua scelta. Questo di solito accade con l'operatore `from`. + +```js +import { from } from "rxjs"; + +const [s, set] = createSignal(0); + +const obsv$ = from(observable(s)); + +obsv$.subscribe(v => console.log(v)); +``` + +## `mapArray` + +```ts +export function mapArray( + list: () => readonly T[], + mapFn: (v: T, i: () => number) => U +): () => U[]; +``` + +Un aiutante di mappa reattivo che memorizza nella cache ogni elemento per riferimento. Questo viene utilizzato per ridurre la mappatura non necessaria sugli aggiornamenti. Esegue la funzione di mappatura solo una volta per valore, quindi la sposta o la rimuove secondo necessità. L'argomento index è un segnale. La funzione mappa stessa non sta tracciando. + +Questo è un helper sottostante per il componente del flusso di controllo integrato ``. + +```js +const mapped = mapArray(source, (modella) => { + const [nome, assegnaNome] = createSignal(modella.nome); + const [modella, assegnaDescrizione] = createSignal(modella.modella); + + return { + id: model.id, + get nome() { + return nome(); + }, + get descrizione() { + return descrizione(); + } + assegnaNome, + assegnaDescrizione + } +}); +``` + +## `indexArray` + +```ts +export function indexArray( + list: () => readonly T[], + mapFn: (v: () => T, i: number) => U +): () => U[]; +``` + +È simile a `mapArray` tranne che mappa per indice. L'elemento è un segnale e l'indice è ora la costante. + +Helper sottostante per il flusso di controllo ``. + +```js +const mapped = indexArray(source, (modella) => { + return { + get id() { + return modella().id + } + get firstInitial() { + return modella().nome[0]; + }, + get fullName() { + return `${modella().nome} ${modella().cognome}`; + }, + } +}); +``` + +# Stores + +Queste API sono disponibili su `solid-js/store`. + +## `createStore` + +```ts +export function createStore( + state: T | Store, + options?: { name?: string } +): [get: Store, set: SetStoreFunction]; +``` + +Questa utility crea un albero di Segnali come proxy. Consente di tenere traccia dei singoli valori in strutture dati nidificate. La funzione create restituisce un oggetto proxy di sola lettura e una funzione setter. + +```js +const [state, setState] = createStore(initialValue); + +// legerre valore +state.unValore; + +// set value +setState({ merge: "questoValore" }); + +setState("percorso", "verso", "valore", nuovoValore); +``` + +Poiché gli oggetti Store sono proxy, tengono traccia solo dell'accesso alla proprietà. All'accesso, Store produce in modo ricorsivo oggetti nidificati su dati nidificati. Questo tuttavia avvolge solo array e oggetti semplici. Le classi non sono chiuse. Elementi come "Data", "HTMLElement", "Regexp", "Mappa", "Set" non sono granularmente reattivi. + +Si noti che l'oggetto di stato di livello superiore non può essere tracciato senza accedere a una proprietà su di esso. Non è adatto per le cose su cui si esegue l'iterazione poiché l'aggiunta di nuove chiavi o indici non può attivare gli aggiornamenti. Quindi dovresti mettere qualsiasi elenco su una chiave di stato piuttosto che provare a usare l'oggetto di stato stesso. + +```js +// metti la lista come chiave sull'oggetto di stato +const [state, setState] = createStore({ elenco: [] }); + +// accedere alla proprietà `elenco` sull'oggetto stato +{articolo => /*...*/} +``` + +### Getters + +Gli oggetti Store supportano l'uso di getter per memorizzare i valori calcolati. + +```js +const [state, setState] = createStore({ + user: { + nome: "Davide", + cognome: "Italiano", + get nome() { + return `${this.nome} ${this.cognome}`; + } + } +}); +``` + +Questi sono semplici getter. È comunque necessario utilizzare un Memo se si desidera memorizzare nella cache un valore: + +```js +let nomeECognome; +const [stato, assegnareStato] = createStore({ + user: { + nome: "Davide", + cognome: "Italiano", + get nomeECognome() { + return nomeECognome(); + } + } +}); +nomeECognome = createMemo(() => `${state.nome} ${state.cognome}`); +``` + +### Aggiornamento dei negozi Store + +Le modifiche possono assumere la forma di funzioni che forniscono lo stato precedente e restituiscono un nuovo stato o un valore. Gli oggetti sono sempre uniti in modo superficiale. Imposta i valori su "non definito" per eliminarli dallo Store. + +```js +const [stato, assegnareStato] = createStore({ nome: "John", cognome: "Azzuro" }); + +assegnareStato({ nome: "Davide", middleName: "Paolo" }); +// ({ nome: 'Davide', middleName: 'Paolo', cognome: 'Italiano' }) + +assegnareStato(stato => ({ nomePreferito: state.nome, cognome: "Azzuro" })); +// ({ nome: 'Davide', nomePreferito: 'Davide', middleName: 'Paolo', cognome: 'Azzuro' }) +``` + +Store supporta percorsi inclusi array di chiavi, intervalli di oggetti e funzioni di filtro. + +In questo esempio, assegnareStato supporta anche l'impostazione nidificata in cui è possibile indicare il percorso della modifica. Quando nidificato, lo stato che stai aggiornando potrebbe essere altri valori non Object. Gli oggetti vengono ancora uniti ma gli altri valori (inclusi gli array) vengono sostituiti. + +```js +const [stato, assegnareStato] = createStore({ + counter: 2, + elenco: [ + { id: 23, titolo: 'Uccelli' } + { id: 27, titolo: 'Pesce' } + ] +}); + +assegnareStato('counter', c => c + 1); +assegnareStato('elenco', l => [...l, { id: 43, titolo: 'Marsupiali' }]); +assegnareStato('elenco', 2, 'legerre', true); +// { +// counter: 3, +// elenco: [ +// { id: 23, titolo: 'Uccelli' } +// { id: 27, titolo: 'Pesce' } +// { id: 43, titolo: 'Marsupiali', read: true } +// ] +// } +``` + +Il percorso può essere costituito da chiavi stringa, array di chiavi, oggetti iterativi ({da, a, per}) o funzioni di filtro. Dà un incredibile potere espressivo per descrivere i cambiamenti di stato. + +```js +const [stato, assegnareStato] = createStore({ + compiti: [ + { compito: 'Finito di lavorare', fatto: false } + { compito: 'Andare a fare la spesa', fatto: false } + { compito: 'Preparare la cena', fatto: false } + ] +}); + +assegnareStato('todos', [0, 2], 'completato', true); + +// { +// compiti: [ +// { compito: 'Finito di lavorare', fatta: true } +// { compito: 'Andare a fare la spesa', fatta: false } +// { compito: 'Preparare la cena', fatta: true } +// ] +// } + +assegnareStato('todos', { from: 0, to: 1 }, 'fatta', c => !c); + +// { +// compiti: [ +// { compito: 'Finito di lavorare', fatta: false } +// { compito: 'Andare a fare la spesa', fatta: false } +// { compito: 'Preparare la cena', fatta: true } +// ] +// } + +assegnareStato('compiti', compiti => compiti.fatta, 'compito', t => t + '!') + +// { +// compiti: [ +// { compito: 'Finito di lavorare', fatta: false } +// { compito: 'Andare a fare la spesa', fatta: true } +// { compito: 'Preparare la cena', fatta: true } +// ] +// } + +assegnareStato('compiti', {}, compiti => ({ marked: true, fatta: !todo.fatta })) +// { +// compiti: [ +// { compito: 'Finish work', fatta: true, marked: true } +// { compito: 'Go grocery shopping!', fatta: false, marked: true } +// { compito: 'Make dinner!', fatta: false, marked: true } +// ] +// } +``` + +## `produce` + +```ts +export function produce( + fn: (state: T) => void +): (state: T extends NotWrappable ? T : Store) => T extends NotWrappable ? T : Store; +``` + +API ispirata a "Immer" per oggetti Solid's Store che consente la mutazione localizzata. + +```js +setState( + produce(s => { + s.utente.nome = "Franco"; + s.lista.push("Matita"); + }) +); +``` + +## `reconcile` + +```ts +export function reconcile( + value: T | Store, + options?: { + key?: string | null; + merge?: boolean; + } = { key: "id" } +): (state: T extends NotWrappable ? T : Store) => T extends NotWrappable ? T : Store; +``` + +Questa utility rileva la modifica dei dati differenziali quando non è possibile applicare aggiornamenti granulari. Utile per quando si tratta di dati immutabili da negozi o risposte API di grandi dimensioni. + +La chiave viene utilizzata quando disponibile per abbinare gli elementi. Per impostazione predefinita, `merge` false esegue controlli referenziali ove possibile per determinare l'uguaglianza e sostituisce laddove gli elementi non sono referenziali uguali. `merge` true spinge tutte le differenze alle foglie e trasforma efficacemente i dati precedenti nel nuovo valore. + +```js +// subscribing to an observable +const anulla = store.subscribe(({ todos }) => ( + setState('compiti', reconcile(todos))); +); +onCleanup(() => anulla()); +``` + +## `createMutable` + +```ts +export function createMutable( + state: T | Store, + options?: { name?: string } +): Store { +``` + +Crea un nuovo oggetto proxy Store mutabile. Registra solo gli aggiornamenti dei trigger in caso di modifica dei valori. Il tracciamento viene gestito intercettando l'accesso alla proprietà e traccia automaticamente l'annidamento profondo tramite proxy. + +Utile per l'integrazione di sistemi esterni o come livello di compatibilità con MobX/Vue. + +> **Nota:** uno stato mutabile può essere passato e mutato ovunque. Può rendere più difficile da seguire e più facile interrompere il flusso unidirezionale. In genere si consiglia di utilizzare invece createStore. Il modificatore di produzione può dare molti degli stessi benefici senza nessuno degli svantaggi. + +```js +const stato = createMutable(initialValue); + +// legerre valore +stato.valore; + +// assegna valore +stato.valore = 5; + +stato.lista.push(altroValore); +``` + +I mutabili supportano i setter insieme ai getter. + +```js +const persona = createMutable({ + nome: "John", + cognome: "Smith", + get nome() { + return `${this.nome} ${this.cognome}`; + }, + set cognome(value) { + [this.nome, this.cognome] = valore.split(" "); + } +}); +``` + +# API dei componenti + +## `createContext` + +```ts +interface Context { + id: symbol; + Provider: (props: { value: T; children: any }) => any; + defaultValue: T; +} +export function createContext(defaultValue?: T): Context; +``` + +Il contesto fornisce una forma di iniezione di dipendenza in Solid. Viene utilizzato per evitare di dover passare dati come oggetti di scena attraverso componenti intermedi. + +Questa funzione crea un nuovo oggetto di contesto che può essere utilizzato con `useContext` e fornisce il flusso di controllo `Provider`. Il contesto predefinito viene utilizzato quando nella gerarchia non viene trovato alcun "provider". + +```js +export const ContestoContatore = createContext([{ conta: 0 }, {}]); + +export function Fornitrice(props) { + const [stato, assegnaStato] = createStore({ conta: props.conta || 0 }); + const store = [ + stato, + { + incremento() { + assegnaStato("conta", c => c + 1); + }, + decremento() { + assegnaStato("conta", c => c - 1); + } + } + ]; + + return {props.children}; +} +``` + +Il valore fornito al provider viene passato a "useContext" così com'è. Ciò significa che il wrapping come espressione reattiva non funzionerà. Dovresti passare direttamente a Segnali e Negozi invece di accedervi in JSX. + +## `useContext` + +```ts +export function useContext(context: Context): T; +``` + +Utilizzato per acquisire il contesto e consente il passaggio profondo degli oggetti di scena senza doverli passare attraverso ciascuna funzione del componente. + +```js +const [stato, { incremento, decremento }] = useContext(ContestoContatore); +``` + +## `children` + +```ts +export function children(fn: () => any): () => any; +``` + +Utilizzato per semplificare l'interazione con `props.children`. Questo helper risolve qualsiasi reattività nidificata e restituisce un memo. È l'approccio consigliato per utilizzare `props.children` per qualsiasi cosa diversa dal passaggio diretto a JSX. + +```js +const list = children(() => props.children); + +// fare qualcosa con loro +createEffect(() => lista()); +``` + +## `lazy` + +```ts +export function lazy>( + fn: () => Promise<{ default: T }> +): T & { preload: () => Promise }; +``` + +Utilizzato per caricare lentamente i componenti per consentire la suddivisione del codice. I componenti non vengono caricati fino al rendering. I componenti caricati pigri possono essere usati come la loro controparte importata staticamente, ricevendo oggetti di scena ecc... I componenti pigri attivano `` + +```js +// avvolgere l'importazione +const ComponenteA = lazy(() => import("./ComponentA")); + +// utilizzare in JSX +; +``` + +# Primitive secondarie + +Probabilmente non ti serviranno per la tua prima app, ma questi utili strumenti per avere. + +## `createDeferred` + +```ts +export function createDeferred( + source: () => T, + options?: { timeoutMs?: number; name?: string; equals?: false | ((prev: T, next: T) => boolean) } +): () => T; +``` + +Crea un readonly che notifica le modifiche downstream solo quando il browser è inattivo. `timeoutMs` è il tempo massimo di attesa prima di forzare l'aggiornamento. + +## `createComputed` + +```ts +export function createComputed(fn: (v: T) => T, value?: T, options?: { name?: string }): void; +``` + +Crea una proprietà di sola lettura che notifica le modifiche downstream solo quando il browser è inattivo. `timeoutMs` è il tempo massimo di attesa prima di forzare l'aggiornamento. + +## `createRenderEffect` + +```ts +export function createRenderEffect( + fn: (v: T) => T, + value?: T, + options?: { name?: string } +): void; +``` + +Crea un nuovo calcolo che tiene traccia automaticamente delle dipendenze. Viene eseguito anche durante la fase di rendering poiché gli elementi DOM vengono creati e aggiornati ma non necessariamente collegati. Tutti gli aggiornamenti DOM interni vengono eseguiti in questo momento. + +## `createSelector` + +```ts +export function createSelector( + source: () => T, + fn?: (a: U, b: T) => boolean, + options?: { name?: string } +): (k: U) => boolean; +``` + +Questo crea un segnale condizionale che notifica agli abbonati solo quando entrano o escono dalla loro chiave che corrisponde al valore. Utile per lo stato di selezione delegata. Poiché esegue l'operazione O(2) invece di O(n). + +```js +const selezionata = createSelector(selectedId); + + + {item =>
  • {articolo.nome}
    • } +    ; +``` + +# Rendering + +Queste importazioni sono esposte da `solid-js/web`. + +## `render` + +```ts +export function render(code: () => JSX.Element, element: MountableElement): () => void; +``` + +Questo è il punto di ingresso dell'app del browser. Fornisce una definizione o una funzione del componente di primo livello e un elemento su cui montare. È consigliabile che questo elemento rimanga vuoto poiché la funzione di eliminazione restituita cancellerà tutti i figli. + +```js +const smaltire = render(App, document.getElementById("app")); +``` + +## `hydrate` + +```ts +export function hydrate(fn: () => JSX.Element, node: MountableElement): () => void; +``` + +Questo metodo è simile a "render" tranne che tenta di reidratare ciò che è già stato reso al DOM. + +```js +const dispose = hydrate(App, document.getElementById("app")); +``` + +## `renderToString` + +```ts +export function renderToString( + fn: () => T, + options?: { + eventNames?: string[]; + nonce?: string; + } +): string; +``` + +Esegue il rendering in una stringa in modo sincrono. La funzione genera anche un tag script per l'idratazione progressiva. Le opzioni includono nomi di eventi da ascoltare prima che la pagina venga caricata e riprodurre su Hydratio. Come bonus viene fornito un nonce da mettere sul tag script. + +```js +const html = renderToString(App); +``` + +## `renderToStringAsync` + +```ts +export function renderToStringAsync( + fn: () => T, + options?: { + eventNames?: string[]; + timeoutMs?: number; + nonce?: string; + } +): Promise; +``` + +Uguale a `renderToString` tranne che attenderà che tutti i limiti di `` vengano risolti prima di restituire i risultati. I dati delle risorse vengono serializzati automaticamente nel tag script e vengono idratati al caricamento del client. + +```js +const html = await renderToStringAsync(App); +``` + +## `pipeToNodeWritable` + +```ts +export type PipeToWritableResults = { + startWriting: () => void; + write: (v: string) => void; + abort: () => void; +}; +export function pipeToNodeWritable( + fn: () => T, + writable: { write: (v: string) => void }, + options?: { + eventNames?: string[]; + nonce?: string; + noScript?: boolean; + onReady?: (r: PipeToWritableResults) => void; + onComplete?: (r: PipeToWritableResults) => void | Promise; + } +): void; +``` + +Questo metodo esegue il rendering in un flusso Node. Esegue il rendering del contenuto in modo sincrono, inclusi eventuali segnaposto di fallback di Suspense. Quindi continua a trasmettere i dati da qualsiasi risorsa asincrona man mano che viene completata. + +```js +pipeToNodeWritable(App, res); +``` + +L'opzione `onReady` è utile per scrivere nel flusso attorno al rendering dell'app principale. Ricorda se usi "onReady" per chiamare manualmente "startWriting". + +## `pipeToWritable` + +```ts +export type PipeToWritableResults = { + write: (v: string) => void; + abort: () => void; + script: string; +}; +export function pipeToWritable( + fn: () => T, + writable: WritableStream, + options?: { + eventNames?: string[]; + nonce?: string; + noScript?: boolean; + onReady?: (writable: { write: (v: string) => void }, r: PipeToWritableResults) => void; + onComplete?: (writable: { write: (v: string) => void }, r: PipeToWritableResults) => void; + } +): void; +``` + +Questo metodo esegue il rendering in un flusso web. Esegue il rendering del contenuto in modo sincrono, inclusi eventuali segnaposto di fallback di Suspense. Quindi continua a trasmettere i dati da qualsiasi risorsa asincrona man mano che viene completata. + +```js +const { readable, writable } = new TransformStream(); +pipeToWritable(App, writable); +``` + +L'opzione `onReady` è utile per scrivere nel flusso attorno al rendering dell'app principale. Ricorda se usi "onReady" per chiamare manualmente "startWriting". + +## `isServer` + +```ts +export const isServer: boolean; +``` + +Ciò indica che il codice viene eseguito come server o bundle del browser. Poiché i runtime sottostanti esportano, questo valore fornisce un valore booleano costante e consente ai bundler di eliminare il codice e le importazioni utilizzate dai rispettivi bundle. + +```js +if (isServer) { + // Non arriverò mai al bundle del browser +} else { + // Non verrà eseguito sul server; +} +``` + +# Controllo del flusso + +Solid utilizza componenti per il controllo del flusso. Affinché la reattività sia performante, dobbiamo controllare come vengono creati gli elementi. Ad esempio con le liste una semplice `mappa` è inefficiente. Mappa sempre tutto. Ciò significa funzioni di supporto. + +Il wrapping di questi in componenti è un modo conveniente per modelli concisi e consente agli utenti di comporre e costruire i propri flussi di controllo. + +Questi flussi di controllo integrati verranno importati automaticamente. Tutti tranne "Portal" e "Dynamic" vengono esportati da "solid-js". Quei due che sono specifici del DOM vengono esportati da `solid-js/web`. + +> Nota: tutte le funzioni figlio di callback/render del flusso di controllo non sono tracciabili. Ciò consente la creazione dello stato di nidificazione e isola meglio le reazioni. + +## `` + +```ts +export function For(props: { + each: readonly T[]; + fallback?: JSX.Element; + children: (item: T, index: () => number) => U; +}): () => U[]; +``` + +Semplice flusso di controllo del ciclo con chiave referenziale. + +```jsx +Loading...
    }> + {item =>
    {item}
    } + +``` + +Il secondo argomento opzionale è un segnale di indice: + +```jsx +Caricamento in corso...
    }> + {(articolo, numero) => ( +
    + #{numero()} {articolo} +
    + )} + +``` + +## `` + +```ts +function Show(props: { + when: T | undefined | null | false; + fallback?: JSX.Element; + children: JSX.Element | ((item: T) => JSX.Element); +}): () => JSX.Element; +``` + +Il flusso di controllo Show viene utilizzato per il rendering condizionale di parte della vista. È simile all'operatore ternario (`a ? b : c`) ma è ideale per creare modelli JSX. + +```jsx + 0} fallback={
    Caricamento in corso...
    }> +
    I miei contenuti
    +     +``` + +Show può anche essere usato come un modo per inserire blocchi in un modello di dati specifico. Ad esempio, la funzione viene rieseguita ogni volta che il modello utente viene sostituito. + +```jsx +Caricamento in corso...
    }> + {persona =>
    {persona.nome}
    } + +``` + +## ``/`` + +```ts +export function Switch(props: { fallback?: JSX.Element; children: JSX.Element }): () => JSX.Element; + +type MatchProps = { + when: T | undefined | null | false; + children: JSX.Element | ((item: T) => JSX.Element); +}; +export function Match(props: MatchProps); +``` + +Il componente Switch è utile quando sono presenti più di 2 condizioni di mutua esclusione. Può essere usato per fare cose come un semplice routing. + +```jsx +Non trovato}> + + + + + + + +``` + +Match supporta anche i figli di funzione per fungere da flusso con chiave. + +## `` + +```ts +export function Index(props: { + each: readonly T[]; + fallback?: JSX.Element; + children: (item: () => T, index: number) => U; +}): () => U[]; +``` + +Questo componente viene utilizzato per l'iterazione di elenchi senza chiave (righe con chiave per l'indice). Questo è utile quando non c'è una chiave concettuale. Ad esempio se i dati sono primitivi ed è l'indice che è fisso piuttosto che il valore. + +L'oggetto è un segnale: + +```jsx +Caricamento in corso...}> + {articolo =>
    {articolo()}
    } +     +``` + +Il secondo argomento facoltativo è un numero di indice: + +```jsx +Caricamento in corso...}> + {(articolo, numero) => ( +
    + #{numero} {item()} +
    + )} +     +``` + +## `` + +```ts +function ErrorBoundary(props: { + fallback: JSX.Element | ((err: any, reset: () => void) => JSX.Element); + children: JSX.Element; +}): () => JSX.Element; +``` + +Contiene errori non rilevati e rende il contenuto di fallback. + +```jsx +Qualcosa è andato terribilmente storto}> + + +``` + +Supporta anche il modulo di callback che passa per errore e una funzione di ripristino. + +```jsx +
    Error: {err}
    }> + +     +``` + +## `` + +```ts +export function Suspense(props: { fallback?: JSX.Element; children: JSX.Element }): JSX.Element; +``` + +Un componente che tiene traccia di tutte le risorse lette sotto di esso e mostra uno stato segnaposto di fallback fino a quando non vengono risolte. Ciò che rende "Suspense" diverso da "Show" è che non è bloccante in quanto entrambi i rami esistono contemporaneamente anche se non sono attualmente nel DOM. + +```jsx +Caricamento in corso...}> + + +``` + +## `` (Experimental) + +```ts +function SuspenseList(props: { + children: JSX.Element; + revealOrder: "forwards" | "backwards" | "together"; + tail?: "collapsed" | "hidden"; +}): JSX.Element; +``` + +`SuspenseList` coordina più componenti paralleli `Suspense` e `SuspenseList`. Controlla l'ordine in cui il contenuto viene rivelato per ridurre il thrashing del layout e ha un'opzione per comprimere o nascondere gli stati di fallback. + +```jsx + + + Caricamento post...}> + + + Caricamento di fatti divertenti...}> + + + +``` + +SuspenseList è ancora sperimentale e non ha il pieno supporto SSR. + +## `` + +```ts +function Dynamic( + props: T & { + children?: any; + component?: Component | string | keyof JSX.IntrinsicElements; + } +): () => JSX.Element; +``` + +Questo componente ti consente di inserire un Componente o un tag arbitrario e gli passa gli oggetti di scena. + +```jsx + +``` + +## `` + +```ts +export function Portal(props: { + mount?: Node; + useShadow?: boolean; + isSVG?: boolean; + children: JSX.Element; +}): Text; +``` + +Questo inserisce l'elemento nel nodo di montaggio. Utile per inserire Modali al di fuori del layout di pagina. Gli eventi si propagano ancora attraverso la Gerarchia dei componenti. + +Il portale è montato in un `
    ` a meno che la destinazione non sia l'intestazione del documento. "useShadow" posiziona l'elemento in una Shadow Root per l'isolamento dello stile e "isSVG" è richiesto se si inserisce in un elemento SVG in modo che "
    " non sia inserito. + +```jsx + +
    My Content
    +     +``` + +# Special JSX Attributes + +Solidi tentativi di attenersi il più possibile alle convenzioni DOM. La maggior parte degli oggetti di scena viene trattata come attributi su elementi nativi e proprietà su Web Components. Tuttavia, alcuni di loro hanno un comportamento speciale. + +Per gli attributi dello spazio dei nomi personalizzati con TypeScript è necessario estendere lo spazio dei nomi JSX di Solid: + +```ts +declare module "solid-js" { + namespace JSX { + interface Directives { + // use:____ + } + interface ExplicitProperties { + // prop:____ + } + interface ExplicitAttributes { + // attr:____ + } + interface CustomEvents { + // on:____ + } + interface CustomCaptureEvents { + // oncapture:____ + } + } +} +``` + +## `ref` + +`Refs` sono un modo per accedere agli elementi DOM sottostanti nel nostro JSX. È vero che si potrebbe assegnare un elemento a una variabile. È più ottimale lasciare i componenti nel flusso di JSX. I riferimenti vengono assegnati al momento del rendering ma prima che gli elementi siano collegati al DOM. Sono disponibili in 2 gusti. + +```js +// compito semplice +let mioDiv; + +// usa onMount o createEffect per leggere dopo esserti connesso a DOM +onMount(() => console.log(mioDiv)); +
    + +// o funzione di callback (chiamata prima della connessione al DOM) +
    console.log(el)} /> +``` + +`Refs` può essere utilizzato anche sui componenti. Devono ancora essere attaccati dall'altra parte. + +```jsx +function MyComp(props) { + return
    ; +} + +function App() { + let mioDiv; + onMount(() => console.log(mioDiv.clientWidth)); + return ; +} +``` + +## `classList` + +Funzione di supporto che sfrutta `element.classList.toggle`. Prende un oggetto le cui chiavi sono nomi di classe e le assegna quando il valore risolto è vero. + +```jsx +
    +``` + +## `style` + +L'helper di stile di Solid funziona con una stringa o con un oggetto. A differenza della versione di React, Solid usa `element.style.setProperty`. Ciò significa che può supportare CSS vars. Significa anche che usiamo le versioni inferiori delle proprietà con trattini. Ciò porta effettivamente a prestazioni e coerenza migliori con l'output SSR. + +```jsx +// string +
    + +// object +
    + +// css variabile +
    +``` + +## `innerHTML`/`textContent` + +Questi metodi funzionano come i loro equivalenti di proprietà. Imposta una stringa e verranno impostati. **Fai attenzione!!** Impostando `innerHTML` con tutti i dati che potrebbero essere esposti a un utente finale in quanto potrebbe essere un vettore per attacchi dannosi. `textContent`, anche se generalmente non è necessario, è in realtà un'ottimizzazione delle prestazioni quando si sa che i bambini saranno solo testo poiché ignora la routine di diffing generica. + +```jsx +
    +``` + +## `on___` + +I gestori di eventi in Solid in genere assumono la forma di "onclick" o "onClick" a seconda dello stile. Il nome dell'evento è sempre minuscolo. Solid utilizza la delega di eventi semi-sintetici per eventi dell'interfaccia utente comuni composti e bolle. Ciò migliora le prestazioni per questi eventi comuni. + +```jsx +
    console.log(e.currentTarget)} /> +``` + +Solid supporta anche il passaggio di un array al gestore eventi per associare un valore al primo argomento del gestore eventi. Questo non usa `bind` o crea una chiusura aggiuntiva, quindi è un modo altamente ottimizzato per delegare gli eventi. + +```jsx +function handler(itemId, e) { + /*...*/ +} + +
      + {item =>
    • } +
    ; +``` + +Gli eventi non possono essere rimbalzati e le associazioni non sono reattive. In genere è più costoso collegare/scollegare gli ascoltatori. Poiché gli eventi vengono chiamati naturalmente, non è necessaria la reattività, è sufficiente scorciatoia per il gestore se lo si desidera. + +```jsx +// se definito chiamalo, altrimenti no. +
    props.handleClick?.()} /> +``` + +## `on:___`/`oncapture:___` + +Per tutti gli altri eventi anche con nomi insoliti. Forse anche gli eventi che non desideri vengano delegati agli eventi dello spazio dei nomi. Questo aggiunge semplicemente un listener di eventi alla lettera. + +```jsx +
    alert(e.detail)} /> +``` + +## `use:___` + +Queste sono direttive personalizzate. In un certo senso questa è solo sintassi zucchero su `ref` ma ci consente di collegare facilmente più direttive a un singolo elemento. Una direttiva è semplicemente una funzione con la seguente firma: + +```ts +function directive(element: Element, accessor: () => any): void; +``` + +Queste funzioni vengono eseguite in fase di rendering e puoi fare quello che vuoi in esse. Crea segnali ed effetti, registra funzioni di pulizia, qualunque cosa desideri. + +```js +const [name, setName] = createSignal(""); + +function model(el, value) { + const [field, setField] = value(); + createRenderEffect(() => (el.value = field())); + el.addEventListener("input", e => setField(e.target.value)); +} + +; +``` + +Per registrarlo con TypeScript, assicurati di estendere lo spazio dei nomi JSX. + +```ts +declare module "solid-js" { + namespace JSX { + interface Directives { + model: [() => any, (v: any) => any]; + } + } +} +``` + +## `prop:___` + +Questo obbliga a trattare il prop come una proprietà invece che come un attributo. + +```jsx +
    +``` + +## `attr:___` + +Forza l'oggetto a essere trattato come un attributo anziché come una proprietà. Utile per i componenti Web in cui si desidera impostare gli attributi. + +```jsx + +``` + +## `/* @once */` + +Il compilatore di Solid utilizza una semplice euristica per il wrapping reattivo e la valutazione pigra delle espressioni JSX. L'elemento in questione contiene una chiamata di funzione, un accesso a una proprietà o forse JSX? Se sì, lo avvolgiamo in un getter quando viene passato ai componenti o in un effetto se passato agli elementi nativi. + +Sapendo questo, possiamo ridurre il sovraccarico di cose che sappiamo non cambieranno mai semplicemente accedendovi al di fuori del JSX. Una variabile semplice non verrà mai racchiusa. Possiamo anche dire al compilatore di non avvolgerli iniziando l'espressione con un decoratore di commenti `/_ @once _/. + +```jsx + +``` + +Funziona anche sui bambini. + +```jsx +{/*@once*/ stato.nonAggionerò} +``` diff --git a/documentation/it/guides/getting-started.md b/documentation/it/guides/getting-started.md index c0402cfe0..f24ae4e11 100644 --- a/documentation/it/guides/getting-started.md +++ b/documentation/it/guides/getting-started.md @@ -98,8 +98,8 @@ Puoi eseguirli direttamente dal browser utilizzando [Skypack](https://www.skypac import html from "https://cdn.skypack.dev/solid-js/html"; const App = () => { - const [counteggio, impostatoConteggio] = createSignal(0), - timer = setInterval(() => setConteggio(counteggio() + 1), 1000); + const [counteggio, assegnaValore] = createSignal(0), + timer = setInterval(() => assegnaValore(counteggio() + 1), 1000); onCleanup(() => clearInterval(timer)); return html`
    ${counteggio}
    `; }; From f307a741808e8ba17d159d964c543608293cee9d Mon Sep 17 00:00:00 2001 From: David Di Biase Date: Sat, 17 Jul 2021 19:39:47 -0400 Subject: [PATCH 4/4] Completed remaining documentation --- documentation/it/comparison.md | 69 ++++++++++++++++++++++++++++++++++ documentation/it/faq.md | 67 +++++++++++++++++++++++++++++++++ 2 files changed, 136 insertions(+) create mode 100644 documentation/it/comparison.md create mode 100644 documentation/it/faq.md diff --git a/documentation/it/comparison.md b/documentation/it/comparison.md new file mode 100644 index 000000000..b749c08da --- /dev/null +++ b/documentation/it/comparison.md @@ -0,0 +1,69 @@ +# Confronto con altre biblioteche + +Questa sezione non può sfuggire a qualche pregiudizio, ma penso che sia importante capire dove si trova la soluzione di Solid rispetto ad altre librerie. Non si tratta di prestazioni. Per uno sguardo definitivo alle prestazioni, non esitare a consultare il [JS Framework Benchmark](https://github.com/krausest/js-framework-benchmark). + +## React + +React ha avuto una grande influenza su Solid. Il suo flusso unidirezionale e la segregazione esplicita di lettura e scrittura con l'API Hooks hanno informato l'API di Solid. Solid ha opinioni forti su come affrontare la gestione dei dati nello sviluppo di applicazioni, ma non cerca di vincolarne l'esecuzione. + +Tuttavia, per quanto Solid si allinei con la filosofia di design di React, funziona in modo fondamentalmente diverso. React utilizza un DOM virtuale e Solid no. L'astrazione di React si basa sulla partizione del componente dall'alto verso il basso in cui i metodi di rendering vengono chiamati ripetutamente e le differenze calcolate. Solid, invece, rende ogni Template una volta nella sua interezza, costruendo il suo grafico reattivo e solo allora esegue le istruzioni relative alle modifiche a grana fine. + +#### Consigli per la migrazione: + +Il modello di aggiornamento di Solid non è come React o anche React + MobX. Invece di pensare ai componenti della funzione come alla funzione "render", pensa a loro come a un "costruttore". Fare attenzione alla destrutturazione o all'accesso anticipato alla proprietà che perde la sua reattività. Le primitive di Solid non hanno restrizioni come le regole Hook. Sei libero di annidarli come meglio credi. Non hai bisogno di chiavi esplicite sulle righe dell'elenco per avere un comportamento "con chiave". Infine, non esiste un VDOM, quindi API VDOM imperative come `React.Children` e `React.cloneElement` non hanno senso. Incoraggio a trovare modi diversi per risolvere i problemi che li utilizzino in modo dichiarativo. + +## Vue + +Solid non è particolarmente influenzato da Vue dal punto di vista del design. Entrambi sono comparabili nel loro approccio alla reattività. Entrambi usano i proxy con il tracciamento automatico basato sulla lettura. È qui che finiscono le somiglianze. Il rilevamento delle dipendenze a grana fine di Vue alimenta un DOM virtuale e un sistema di componenti meno dettagliati. Solid mantiene la sua granularità fino agli aggiornamenti diretti del DOM. + +Vue valorizza la semplicità dove Solid valorizza la trasparenza. Sebbene la nuova direzione di Vue con Vue 3 si allinei maggiormente all'approccio adottato da Solid. Queste librerie potrebbero allinearsi maggiormente nel tempo a seconda di come continuano ad evolversi. + +#### Consigli per la migrazione: + +La migrazione da Vue dovrebbe sembrare molto familiare e facile data la vicinanza di entrambe le soluzioni. I componenti di Solid sono simili all'etichettatura del modello alla fine della funzione `setup` di Vue. Fai attenzione a non sovrapporre le derivazioni di stato con i calcoli. Prova una funzione. La reattività è pervasiva. I proxy di Solid sono intenzionalmente di sola lettura. Non giudicarlo prima di provarlo. + +## Svelte + +Svelte ha aperto la strada alla struttura precompilata che scompare che Solid impiega anche in una certa misura. Entrambe le librerie sono veramente reattive e possono produrre bundle di codice di esecuzione davvero piccoli. Svelte è il vincitore qui per le piccole demo. Solid richiede un po' più di chiarezza nelle sue dichiarazioni e si affida meno all'analisi implicita del compilatore, ma questo fa parte di ciò che offre a Solid prestazioni superiori. Solid mantiene anche di più nel runtime che si adatta meglio alle app più grandi. L'implementazione della demo RealWorld di Solid è del 25% più piccola di quella di Svelte. + +Entrambe le librerie mirano ad aiutare i loro sviluppatori a scrivere meno codice ma ad affrontarlo in modo completamente diverso. Svelte 3 si concentra sull'ottimizzazione della facilità di gestione dei cambiamenti localizzati concentrandosi sull'interazione di oggetti semplici e sul legame bidirezionale. In contrasto Solid si concentra sul flusso di dati abbracciando deliberatamente CQRS e un'interfaccia immutabile. Con composizione modello funzionale. In molti casi Solid consente agli sviluppatori di scrivere ancora meno codice di Svelte, sebbene la sintassi del modello di Svelte sia decisamente concisa. + +#### Consigli per la migrazione: + +L'esperienza degli sviluppatori è diversa da Solid e Svelte. Mentre alcune cose sono analoghe, è un'esperienza molto diversa. I componenti in Solid sono economici, quindi non esitare ad averne di più. + +## Knockout.js + +Solid deve la sua esistenza a Knockout. La modernizzazione del suo modello per il rilevamento granulare delle dipendenze è stata la motivazione per questo progetto. Knockout è stato rilasciato nel 2010 e supporta Microsoft Explorer su IE6 mentre gran parte di Solid non supporta affatto IE. + +I collegamenti di Knockout sono solo stringhe in HTML che vengono esaminate in fase di esecuzione. Dipendono dal contesto di clonazione ($genitore ecc...). Considerando che Solid utilizza JSX o Tagged Template Literals per la creazione di modelli optando per un'API JavaScript. + +La differenza più grande potrebbe essere che l'approccio di Solid alle modifiche in batch che garantisce la sincronicità mentre Knockout ha deferUpdates che utilizza una coda di microtask differita. + +#### Advice for migrating: + +Se ti senti a tuo agio con Knockout, i primitivi di Solid potrebbero sembrarti strani. La separazione lettura/scrittura è intenzionale e non solo per complicare la vita. Cerca di adottare un modello mentale stato/azione (Flusso). Sebbene le librerie abbiano un aspetto simile, promuovono best practice diverse. + +## Lit & LighterHTML + +Queste librerie sono incredibilmente simili e hanno avuto una certa influenza su Solid. Il codice compilato di Solid utilizza un metodo molto simile per eseguire il rendering iniziale del DOM in modo efficiente. La clonazione degli elementi del modello e l'utilizzo dei segnaposto dei commenti sono qualcosa che Solid e queste librerie condividono. + +La differenza più grande è che, sebbene queste librerie non utilizzino il Virtual DOM, trattano il rendering allo stesso modo: dall'alto verso il basso. Al contrario, Solid utilizza il suo grafico reattivo a grana fine per aggiornare solo ciò che è cambiato e così facendo condivide questa tecnica solo per il suo rendering iniziale. Questo approccio sfrutta la velocità iniziale disponibile solo per il DOM nativo e offre anche l'approccio più efficiente agli aggiornamenti. + +#### Advice for migrating: + +Queste librerie sono piuttosto minimali e facili da costruire sopra. Tuttavia, tieni presente che `` non è solo HTMLElement (array o funzione). Cerca di mantenere le tue cose nel modello JSX. "Hoisting" funziona per la maggior parte, ma è meglio pensare mentalmente a questo ancora come a una libreria di rendering e non a una fabbrica HTMLElement. + +## S.js + +S.js ha avuto la maggiore influenza sul design reattivo di Solid. Solid ha utilizzato S.js internamente per un paio d'anni fino a quando il catalogo delle funzionalità non li ha posizionati su percorsi diversi. S.js è una delle librerie reattive più efficienti fino ad oggi. Modella tutto in base a fasi temporali sincrone come un circuito digitale e garantisce coerenza senza dover eseguire molti dei meccanismi più complicati presenti in librerie come MobX. + +La reattività di Solid alla fine è un ibrido tra S e MobX. Ciò gli conferisce prestazioni maggiori rispetto alla maggior parte delle librerie reattive (Knockout, MobX, Vue) pur mantenendo la facilità del modello mentale per lo sviluppatore. S.js in definitiva è ancora la libreria reattiva più performante, anche se la differenza è appena percettibile in tutti i benchmark sintetici più estenuanti. + +## RxJS + +RxJS è una libreria reattiva. Sebbene Solid abbia un'idea simile dei dati osservabili, utilizza un'applicazione molto diversa del modello dell'osservatore. I segnali sono come una semplice versione di un osservabile (solo il prossimo). Il modello di rilevamento della dipendenza automatica supera il centinaio di operatori RxJS. Solid avrebbe potuto adottare questo approccio, ma nella maggior parte dei casi è più semplice scrivere la propria logica di trasformazione in un calcolo. Laddove gli Observable sono avviabili a freddo, unicast e basati su push, molti problemi sul client si prestano all'avvio a caldo e al multicast che è il comportamento predefinito di Solid. + +## Others + +Angular e alcune altre librerie popolari mancano in particolare da questo confronto. La mancanza di esperienza con loro impedisce di fare confronti adeguati. In generale, Solid ha poco in comune con i framework più grandi ed è molto più difficile confrontarli frontalmente. diff --git a/documentation/it/faq.md b/documentation/it/faq.md new file mode 100644 index 000000000..c61677541 --- /dev/null +++ b/documentation/it/faq.md @@ -0,0 +1,67 @@ +# FAQ + +### 1. JSX senza VDOM? Questo è vaporware? Ho sentito altri autori riconosciuti dire che non era possibile. + +È possibile quando non hai il modello di aggiornamento di React. JSX è un modello DSL come un altro. Solo uno che è più flessibile in certi modi. L'inserimento di JavaScript arbitrario può essere difficile a volte, ma non è diverso dal supportare gli operatori di diffusione. Quindi no, questo non è impossibile, ma un approccio che si è dimostrato uno dei più performanti. + +Il vero vantaggio è quanto è estensibile. Hai il compilatore che lavora per te dandoti aggiornamenti DOM nativi ottimali ma hai tutta la libertà di una libreria come React per scrivere componenti usando tecniche come Render Props e Higher Order Components insieme ai tuoi "ganci" reattivi. Non ti piace come funziona il flusso di controllo di Solid? Scrivi il tuo. + +### 2. How is Solid so performant? + +È difficile individuare qualcosa di specifico. È davvero la combinazione di molte decisioni più specificamente: + +1. Reattività granulare in modo che vengano tracciate solo le cose che dovrebbero essere reattive. +2. Compilare tenendo presente la creazione iniziale. Solid utilizza l'euristica per ridurre la granularità. Ciò riduce il numero di calcoli effettuati, ma mantiene gli aggiornamenti chiave granulari e performanti. +3. Le espressioni reattive sono solo funzioni. Ciò consente la "scomparsa dei componenti" con valutazione pigra delle prop che rimuove wrapper non necessari e sovraccarico di sincronizzazione. + +Queste sono attualmente tecniche uniche in una combinazione che danno a Solid un vantaggio rispetto alla concorrenza. + +### 3. Esiste una funzionalità di compatibilità di React? + +No, e probabilmente non ci sarà mai. Sebbene le API siano simili e i componenti spesso possano essere spostati con piccole modifiche, il modello di aggiornamento è fondamentalmente diverso. React Components esegue il rendering più e più volte quindi il codice al di fuori di Hooks funziona in modo molto diverso. Le chiusure e le regole dei ganci non solo non sono necessarie, ma possono essere utilizzate in modi che qui non funzionano. + +La compatibilità con Vue potrebbe tuttavia essere più realistica. Sebbene non ci siano piani da implementare attualmente. + +### 4. Perché la destrutturazione non funziona? Mi sono reso conto che posso risolverlo avvolgendo l'intero componente in una funzione. + +La reattività si verifica all'accesso alla proprietà con oggetti Prop e Store. Il loro riferimento al di fuori di un calcolo vincolante o reattivo non verrà registrato. La destrutturazione è perfettamente a posto all'interno di quelli. + +Annidare l'intero componente in una funzione non è quello che vuoi fare in modo irresponsabile. Solid non ha un VDOM. Quindi qualsiasi modifica tracciata eseguirà nuovamente l'intera funzione ricreando tutto. Non farlo. + +### 5. Puoi aggiungere il supporto per i componenti della classe? Trovo che i cicli di vita siano più facili da ragionare. + +Non è intenzione di supportare i componenti della classe. I cicli di vita di Solid sono legati alla programmazione del sistema reattivo e sono artificiali. Potresti farne una classe, ma in pratica tutto il codice del gestore non di eventi viene fondamentalmente eseguito nel costruttore, inclusa la funzione di rendering. + +Raggruppa i dati e i relativi comportamenti anziché i cicli di vita. Questa è una best practice reattiva che funziona da decenni. + +### 6. Non mi piace molto JSX! C'è qualche possibilità per un modello DSL? Oh, vedo che hai taggato Template Literals/HyperScript. Forse userò quelli... + +Non farlo. Ti fermerò proprio lì. Usiamo JSX nel modo in cui Svelte usa i suoi modelli: per creare istruzioni DOM ottimizzate. Le soluzioni Tagged Template Literal e HyperScript possono essere davvero impressionanti di per sé, ma a meno che tu non abbia una vera ragione come un requisito di non compilazione, sono inferiori in ogni modo. Si traduce in bundle più grandi, prestazioni più lente e la necessità di valori di wrapping per soluzioni alternative manuali. + +È bello avere opzioni, ma JSX di Solid è davvero la soluzione migliore qui. Fidati di noi! Anche un modello DSL sarebbe fantastico. Potrebbe essere un po' più restrittivo, ma JSX ci dà così tanto valore. TypeScript, Parser esistenti, Evidenziazione della sintassi, TypeScript, Più carino, Completamento del codice e, ultimo e non meno importante, TypeScript. + +Altre librerie hanno aggiunto il supporto per queste funzionalità, ma questo è stato uno sforzo enorme ed è ancora imperfetto e un costante mal di testa per la manutenzione. Questo è davvero puntare sul pragmatismo. + +### 7. Quando uso un Signal vs Store? Perché questi sono diversi? + +Gli archivi contengono valori nidificati che lo rendono ideale per strutture di dati profonde e per cose come i modelli. Per la maggior parte delle altre cose, i segnali sono leggeri e portano a termine il lavoro. + +Sfortunatamente, poiché non è possibile eseguire il proxy delle primitive, queste idee non possono essere combinate. Le funzioni sono l'interfaccia più semplice e qualsiasi espressione reattiva (incluso l'accesso allo stato) può essere racchiusa in una durante il trasporto, quindi questo fornisce un'API universale. Puoi nominare i tuoi segnali e dichiarare come preferisci e rimane minimo. L'ultima cosa che vorresti fare è forzare la digitazione `.get()` `.set()` o anche peggio `.value`. Almeno il primo può essere alias per brevità, mentre il secondo è solo il modo meno conciso per chiamare una funzione.1 + +### 8. Perché non posso semplicemente assegnare un valore a Solid's Store come posso fare in Vue. Svelto o MobX? Dov'è il "2-way binding"? + +### 8. Perché non posso semplicemente assegnare un valore a Solid's Store come posso fare in Vue. Svelto o MobX? Dov'è il "binding a 2 vie"? + +La reattività è uno strumento potente ma anche pericoloso. MobX lo sa e ha introdotto la modalità Strict e le azioni per limitare dove/quando si verificano gli aggiornamenti. Non hai bisogno di essere effettivamente immutabile fintanto che fornisci i mezzi per avere lo stesso contratto. + +Avere la possibilità di aggiornare lo stato è probabilmente ancora più importante che decidere di passare lo stato. Quindi essere in grado di separarlo è importante. Anche se la lettura è immutabile. Inoltre, non dobbiamo pagare il costo dell'immutabilità se possiamo ancora aggiornare granulare. Fortunatamente ci sono tonnellate di arte precedente qui tra ImmutableJS e Immer. Ironicamente Solid agisce principalmente come un Immer inverso con i suoi interni mutevoli e l'interfaccia immutabile. + +### 9. Posso usare la reattività di Solid da sola? + +Ovviamente. Anche se non ho esportato un pacchetto autonomo, è facile installare Solid senza il compilatore e utilizzare solo le primitive reattive. Uno dei vantaggi della reattività granulare è che è indipendente dalla libreria. Del resto, quasi tutte le librerie reattive funzionano in questo modo. Questo è ciò che ha ispirato [Solid](https://github.com/solidjs/solid) ed è alla base della [libreria DOM Expressions](https://github.com/ryansolid/dom-expressions) in primo luogo per creare un renderer puramente dal sistema reattivo. + +Per elencarne alcuni da provare: [Solid](https://github.com/solidjs/solid), [MobX](https://github.com/mobxjs/mobx), [Knockout](https://github .com/knockout/knockout), [Svelto](https://github.com/sveltejs/svelte), [S.js](https://github.com/adamhaile/S), [CellX](https: //github.com/Riim/cellx), [Derivable](https://github.com/ds300/derivablejs), [Sinuous](https://github.com/luwes/sinuous) e anche recentemente [Vue ](https://github.com/vuejs/vue). Per creare una libreria reattiva è necessario molto di più che taggarla su un renderer come [lit-html](https://github.com/Polymer/lit-html) per esempio, ma è un buon modo per avere un'idea. + +### 10. Solid ha una libreria Next.js o Material Components che posso usare? + +Non a mia conoscenza. Se sei interessato a costruirne uno, siamo prontamente disponibili sul nostro [Discord](https://discord.com/invite/solidjs) per aiutarti a costruirli. Abbiamo le basi e dobbiamo solo costruirci sopra.