Fonctionnalité en construction
Cette fonctionnalité n'est pas encore disponible. Voici ce qui est prévu, pour que vous puissiez juger si elle couvrira votre besoin — et nous dire si ce n'est pas le cas.
État — conception arbitrée
Disponibilité prévue — mode serveur uniquement
En résumé
Lancer depuis le code du projet une véritable application Shiny, Streamlit, Dash ou Gradio, et l’utiliser dans un onglet de Linkr — sans jamais manipuler de numéro de port ni ouvrir un terminal à côté. L’application tournerait dans son propre processus, donc sans bloquer votre session de code.
Le besoin
Une application interactive reste le bon outil pour certaines choses : un formulaire de relecture, un simulateur de score, un explorateur sur mesure que ni un tableau de bord ni un notebook ne remplacent.
Aujourd’hui, la lancer depuis Linkr ne fonctionne pas. Un shiny::runApp() exécuté dans l’IDE bloque la session jusqu’à ce que le délai d’exécution l’interrompe, au bout de deux minutes — et l’IDE avec elle. La seule solution actuelle est de sortir de Linkr, lancer l’application sur son poste, et gérer soi-même l’accès aux données.
À savoir dès maintenant
Ne lancez pas d’application web depuis l’IDE : elle occupera votre session sans jamais s’afficher, jusqu’à l’interruption automatique. C’est précisément ce que cette fonctionnalité vise à corriger.
Ce qui est prévu
Lancer depuis le bouton Exécuter
Une entrée Exécuter comme application web apparaîtrait dans le menu du bouton Exécuter lorsque le fichier ouvert ressemble à une application — un app.R, un ui.R, ou un script qui importe Streamlit, Dash, Gradio, Panel ou Marimo.
Pour les cas non reconnus, une option Commande personnalisée permettrait de fournir sa propre ligne de commande.
L’application dans un onglet
Elle s’ouvrirait comme un onglet de l’IDE, avec l’application affichée à l’intérieur, une pastille d’état — démarrage, prête, échec —, des boutons Redémarrer et Arrêter, un accès aux journaux en cas de problème, et la possibilité de l’ouvrir dans une fenêtre séparée.
Fermer l’onglet n’arrêterait pas l’application : elle resterait listée dans le panneau des tâches, où on peut l’arrêter.
Sans bloquer votre travail
C’est l’exigence centrale. L’application tournerait dans son propre processus, séparé de vos sessions R et Python. Votre console reste disponible, vos variables sont intactes, et vous pouvez continuer à coder pendant que l’application tourne.
Mode serveur uniquement
Une installation en mode navigateur n’a pas de processus à lancer : la fonctionnalité ne pourra pas y exister. Voir Modes de déploiement.
Ce qui est déjà tranché
L’application ne sera pas partageable par un lien, au moins dans un premier temps. La raison est de sécurité : l’application s’affichant dans Linkr, son code aurait accès au jeton de connexion de la personne qui la consulte. Tant qu’une séparation stricte n’est pas en place, seule la personne qui a lancé l’application pourra y accéder.
C’est une limite assumée : mieux vaut une fonctionnalité restreinte qu’un partage qui expose des identifiants.
Une application qui ignore le chemin fourni par Linkr ne fonctionnera pas. Les applications qui construisent des URL absolues en dur, sans tenir compte de l’adresse à laquelle elles sont servies, ne seront pas prises en charge.
Ce qui n’est pas encore tranché
Plusieurs points de conception restent ouverts. Ils sont listés ici parce que votre avis peut encore les faire pencher.
Plusieurs applications à la fois ?
Faut-il autoriser deux applications sur un même projet, ou est-ce toujours le signe d’un oubli d’arrêt ? Une limite de deux applications simultanées par utilisateur est envisagée.
Redémarrage à l’enregistrement
Faut-il relancer l’application quand un fichier est enregistré, ou laisser le framework gérer lui-même son rechargement et fournir seulement un bouton ?
Une application comme widget de tableau de bord
Intégrer une application Shiny dans un tableau de bord est hors périmètre pour l’instant : cela suppose la séparation de sécurité évoquée plus haut.
Consommation de mémoire
Aucun plafond de mémoire ou de processeur n’est prévu pour l’instant — une application gourmande pourrait peser sur l’instance. Les sessions de code ont aujourd’hui la même limite.
Des valeurs sont envisagées sans être arrêtées : arrêt automatique après une heure sans utilisation, et une minute pour qu’une application démarre avant d’être déclarée en échec.
En attendant
- IDE — écrire le code de l’application, et l’exécuter autrement qu’en application web.
- Tableaux de bord — ce qui couvre déjà beaucoup de besoins d’interactivité.
- Widgets de code — du R ou du Python qui produit un affichage dans un tableau de bord.