Préférences principales et variantes

Le streamer peut créer des variantes ordonnées, conditionnées par son statut Kappapps et/ou sa catégorie Twitch. La première variante activée dont toutes les conditions sont remplies gagne. Sans correspondance, seules les préférences principales s'appliquent.

La valeur effective est composée des principales et des surcharges de cette unique variante. Les autres variantes ne contribuent pas.

Principales	Variante gagnante	Valeur effective
Couleur violet, titre « Bienvenue »	Couleur orange	Couleur orange, titre « Bienvenue »
Liste de trois manches	Liste d'une manche	La liste d'une manche, sans concaténation
Champ nullable renseigné	Surcharge explicite null	null

Une surcharge reste explicite même si sa valeur est identique aux principales. Retirer la surcharge signifie « hériter à nouveau » ; affecter la même valeur ne la retire pas.

Ce que voit l'appli

kapp.preferences.get() rend les valeurs effectives et hydratées, dans le même format qu'en l'absence de variante. Le code n'a pas à recalculer la variante gagnante ni à fusionner les arbres.

Quand les valeurs effectives changent, les instances concernées reçoivent la mise à jour. Le SDK recharge les préférences avant EVENTS.UPDATED et ordonne ses rafraîchissements pour éviter qu'une ancienne réponse remplace un état récent. Utilise la recette d'application initiale et d'abonnement.

Où écrit set() ?

Pour chaque réglage, une surcharge déjà existante dans la variante gagnante reçoit l'écriture. Sinon, l'écriture modifie les principales. set() n'est donc pas une commande pour créer arbitrairement une nouvelle surcharge.

Les groupes sont parcourus champ par champ ; les collections sont traitées en bloc, identités internes comprises. Une écriture ne changeant pas la valeur effective ne déclenche pas de notification. Les panneaux personnalisés doivent suivre le contrat de KappappsPrefs, plutôt que reproduire cette logique.

Recette

Configurer deux variantes qui peuvent toutes deux correspondre, puis changer leur ordre : seule la première doit gagner. Vérifier un champ surchargé, un champ hérité et une collection. Modifier un réglage principal hérité puis observer l'instance ouverte ; enfin retirer une surcharge et vérifier que la valeur principale réapparaît.

Pour une nouvelle version de l'appli, tester aussi les surcharges existantes : les migrations doivent préserver leur provenance, pas seulement les valeurs principales.