Pourquoi tant de développeurs FlutterFlow se tirent les cheveux avec le Build Context ?
Si vous développez régulièrement sur FlutterFlow, il y a fort à parier que vous avez déjà croisé la question (voire la frustration) autour du fameux Build Context et l’ajout d’imports dans les fonctions personnalisées. Sans parler du dilemme des thèmes de couleurs ou de la génération de UUID dans votre projet… Bienvenue dans la galère des devs FlutterFlow !
Et si on plongeait dans ce serpent de mer pour comprendre ce qui bloque, et voir ce que pourrait apporter une évolution côté FlutterFlow ? Spoiler : préparez vos mugs de café, on va un peu rouspéter, mais surtout vous donner des pistes et une vision claire du sujet.
Petit rappel (pour ceux du fond) : Build Context, à quoi ça sert ?
Avant tout, faisons un rapide tour d’horizon. Si le Build Context vous fait penser à un super-héros masqué de la dev team Flutter, sachez que ce n’est pas si loin de la réalité. Le build context dans Flutter (et donc FlutterFlow) est le sésame qui permet d’accéder :
- Aux thèmes de couleurs
- Aux localisations
- Et à tout ce dont vos widgets raffolent pour briller à l’écran
Sans lui, les fonctions qui doivent réagir au thème utilisateur ou veulent utiliser les goodies du framework se retrouvent… à poil. D’où la frustration de ne pas pouvoir simplement le passer sur une fonction custom.
Le problème des fonctions personnalisées dans FlutterFlow
Reprenons le témoignage de Thomas dans la community FlutterFlow : il aimerait juste pouvoir créer une fonction qui retourne une ColorTheme en fonction du contexte actuel. Mais là, badaboom : ce n’est pas prévu dans FlutterFlow côté Custom Code. C’est comme préparer un gâteau sans œufs, ni beurre, ni lait – reste le saladier.
Et rebelote avec les imports : impossible d’enrichir le haut de votre fonction avec, par exemple, un import 'package:uuid/uuid.dart'; pour générer des identifiants uniques (sans passer par un détournement Action/résultat).
En résumé, la boîte à outils Custom Function de FlutterFlow est verrouillée sur les trucs les plus funs. Plus de 88% de son projet, Thomas les passe à dupliquer, remplacer, bricoler… Un vrai cauchemar de gestion, surtout pour les gros projets où la personnalisation et la simplification du code sont cruciales.
Pourquoi c’est si embêtant, techniquement ?
Thèmes & couleurs globaux : L’impossibilité de mutualiser
L’un des puissants avantages de Flutter, c’est de centraliser tout ce qui touche à l’apparence via le contexte. Adapter dynamiquement un widget à la couleur du thème utilisateur ? Rapide, intuitif… sauf dans FlutterFlow si vous passez par une fonction custom.
Résultat :
- Obligé de répéter des conditions pour chaque widget
- Explosion de la taille du projet
- Maintenance quasi impossible
UUID & Comportements tiers : Le mur invisible des imports
Idem avec les fonctionnalités composables ou externes : impossible d’enrichir vos scripts avec des packages tiers. En gros, si FlutterFlow n’a pas pensé à inclure une fonction Action, vous êtes de retour à l’âge de pierre (informatique).
Y-a-t-il une solution ou de l’espoir ?
Astuces pour s’en sortir (en attendant la mise à jour tant attendue)
- Multi-actions : Contournez certaines limitations en combinant plusieurs actions plutôt que d’essayer d’en faire une seule.
- Appuyez-vous sur les widgets standards : Essayez autant que possible de rester sur les rails des widgets et actions fournis nativement par FlutterFlow.
- Soumission de suggestions : Il existe un canal dédié dans la communauté FlutterFlow pour réclamer (gentiment) des évolutions ! Plus il y a de votes, plus les chances d’intégration sont grandes.
Pour ceux qui aiment rêver : Ce que FlutterFlow pourrait faire évoluer
- Offrir l’option d’ajouter le Build Context comme argument dans la déclaration des fonctions custom
- Autoriser l’ajout libre d’imports au-dessus de chaque fonction personnalisée
- Mieux documenter les contournements possibles (et les limites)
Imaginez la productivité (et la bonne humeur) qui en découlerait ! On arriverait presque à aimer les refactos le lundi matin…
Le point sur la roadmap de FlutterFlow (et la patience du dev)
Certes, les équipes de FlutterFlow bossent fort, leur roadmap déborde d’idées lumineuses, mais la gestion fine du custom code et notamment de la portée du Build Context, c’est toujours en attente d’une officialisation.
Ça laisse malheureusement la communauté sans réponse claire : il faut donc choisir, jongler, ruser… ou croiser les doigts pour une mise à jour à venir. Sans trop y compter dans les 5 prochaines années si l’on en croit la pointe d’ironie de Thomas !
Conclusion : Réinventez vos process, mais… gardez la banane !
Les limitations sur le Build Context et l’ajout d’imports dans les fonctions restent un vrai caillou dans la chaussure du développeur FlutterFlow. Mais la communauté s’active, partage ses astuces et ses coups de gueule. Peut-être qu’en mettant la pression collective (avec humour, café, et emojis 🤷♂️), FlutterFlow finira par écouter les utilisateurs et ouvrir la boîte à outils.
En attendant, adaptez vos méthodes, multipliez les votes sur la communauté, et conservez ce petit esprit bricoleur qui fait la magie du développement mobile no-code/low-code !
Vous aussi, vous avez une astuce de sioux ou une galère épique sur FlutterFlow ? Partagez tout en commentaire, la communauté adore les récits croustillants… et qui sait, peut-être que FlutterFlow piquera quelques idées au passage !