Aller au contenu
useffect.sh
Planifier 30 min avec un senior
Tous les articles
La veille du collectif

Lucent : écrire du natif depuis un sous-ensemble de TypeScript

2 min de lectureReact Native · Expo

TypeScript comme langage d’entrée d’un compilateur natif

Lucent (nouvelle fenêtre) explore une autre manière d’écrire des modules natifs : un sous-ensemble de TypeScript est compilé vers C++20, avec une intégration JSI. Le projet se présente comme expérimental. Il faut donc distinguer cette proposition d’un programme TypeScript ordinaire exécuté par le moteur JavaScript de l’application.

Le vocabulaire reste familier, mais le modèle d’exécution change. Un compilateur natif doit connaître les opérations et les types qu’il peut traduire ; toute la souplesse du JavaScript dynamique ne se transpose pas automatiquement. Une dépendance npm arbitraire ne devient pas une bibliothèque C++ simplement parce que son appel est écrit dans un fichier .ts.

Une piste pour un module ciblé

Le cas intéressant serait un petit calcul ou une intégration native isolée, avec une entrée et une sortie clairement définies. Le coût à regarder comprend la compilation, le code généré, la liaison au projet et les erreurs remontées au développeur. Réduire la quantité de Swift ou de Kotlin écrite à la main peut être utile, mais une panne du build reste une panne native à comprendre.

Les bibliothèques appelées depuis l’interface doivent aussi avoir une durée de vie explicite. Qui possède un objet natif après le démontage de l’écran ? Quand son travail est-il annulé ? Ces questions restent présentes même si la syntaxe du module ressemble au code React Native voisin.

Lucent mérite donc un essai borné, avec un chemin de retour simple vers l’implémentation existante. Son statut expérimental ne permet pas d’en faire une recommandation générale pour remplacer les modules Expo ou les TurboModules d’une application distribuée.

Un de ces sujets se pose dans votre app ? Un senior du collectif peut en parler avec vous.