Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[mf2 JS api] Why this `selectKey` design?

Aperta
  • Qualcosa non va?
#439 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
30/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
javascript, typescript
Ambito
api

Direzione di ricerca

Start with the selectKey implementation for Number and trace how repeated calls produce the priority-ordered matches in the MF2 examples. Compare the proposed array and generator alternatives, then define the API behavior and completion criteria before making a change.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Let me start by saying that the way selectKey works is quite confusing. After reading the selectKey implementation for Number, I to took me a while for me to figure out how both these examples return x:

.local $n = {1 :number}
.match $n
one {{ a }}
1 {{ x }}
one {{ c }}
* {{}}

.local $n = {1 :number}
.local $m = {2 :number}
.match $n $m
1 3 {{ a }}
one 2 {{ x }}
* * {{}}

Once it clicked that the way it works is by calling .selectKey multiple times, each time removing the value that "won" the previous time if it didn't lead to a success.

This means that, if I need to normalize my value to check if it's in the set (and for number it's trivial, it's just a String(num), but for other types it can be much more complex), then:

  • the first time I have to normalize it for the "best way"
  • the second time I have to normalize it for the "best way" (to discover it's not in the set anymore) and "second best way"
  • the third time I have to normalize it for the "best way" (to discover it's not in the set anymore), "second best way" (to discover it's not in the set anymore), and "third best way"
  • ... and so on

Why doesn't .selectKey return an array instead, so that it already returns the various matches in priority order and I don't have to re-compute all the previous steps at every call?

If the reason is "because maybe the first match matches, so computing the second and third one is a waste", could it instead return a generator? yield bestMatch; yield secondBestMatch; ...

Lingua principale
TypeScript
Stelle
1.8k
Fork
161
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di messageformat/messageformat

Tutte le issue di messageformat/messageformat

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.