Support nested Switches
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 38/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- react, typescript
- Ambito
- frontend
Direzione di ricerca
La issue nomina solo i componenti Switch e Route, non i file sorgente né i test. Inizia individuando la loro implementazione e i test di routing esistenti; il lavoro è completato quando è possibile comporre Switch annidati e selezionare la prima route o il primo Switch corrispondente, con test che coprano l’esempio raggruppato.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Hi, I've read the docs to see if nested Switches are supported (a longstanding wish), and I think they are not, so I wanted to make a feature proposal.
The idea is that a switch picks the first matching route or switch. A switch matches if one of its routes (or switches) matches. It's basically the Composite pattern.
The use-case is this one:
<Switch>
<Route path="blue/one"/>
<Route path="red/one"/>
<Route path="bread/one"/>
<Route path="apple/one"/>
</Switch>
If I want to create separate route groups for "color" or "food" then it would be great if I can refactor this to
// Switch that renders either ColorsSwitch or FoodsSwitch.
// This approach can be used to clean up switches with many routes.
// It can also be used to reuse switches in different locations.
<Switch>
<ColorsSwitch/>
<FoodsSwitch/>
</Switch>
const ColorsSwitch = () => {
return (
<Switch>
<Route path="blue/one"/>
<Route path="red/one"/>
</Switch>
)
}
const FoodsSwitch = () => {
return (
<Switch>
<Route path="bread/one"/>
<Route path="apple/one"/>
</Switch>
)
}
- Lingua principale
- TypeScript
- Stelle
- 7.9k
- Fork
- 193
- Merge medio
- 9m
- PR unite (30g)
- 1
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di molefrog/wouter
-
Wouter double-decodes search params in `useSearchParams`, which can lead to �Forse già presa @priyas1672 l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 52/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
-
Links using ~ do not respect `base`Forse già presa @molefrog l’ha presa 25 giorni fa. Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
Tutte le issue di molefrog/wouter
Issue simili
-
Replace discontinued crypto-js in the themeForse già presa @aelmanaa l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
PaloAltoNetworks/docusaurus-openapi-docs#1689 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
solana-foundation/solana-web3.js#4015 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
formatSearchQuery drops the :present modifier, so `email:present=true` is sent as `email=true`Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno
-
documentation
Difficoltà 1/5 1-3 ore Idoneità per principianti 90/100
ivopogace/opencode-courier#422 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
chapel-lang/chapel-vscode#158 ·
I maintainer di solito rispondono entro 1 giorno