Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#439 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
30/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
À l'abandon
Stack technique
javascript, typescript
Domaine
api

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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; ...

Langage dominant
TypeScript
Étoiles
1.8k
Forks
160
Aucune PR mergée en 30 j

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de messageformat/messageformat

Toutes les issues de messageformat/messageformat

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.