Ekklo

temps que ça arrive.

Je vais le refaire. Ça va bugger. Bonjour et bienvenue dans le Cross Platform Show, le podcast qui explore le... Putain, mais merde, je ne suis pas dedans. Allez. Bonjour et bienvenue sur le Cross Platform Show, le podcast qui parle développement d'applications mobiles avec React Native. Je suis David, développeur chez Wishy Pityoday. Nous sommes en mars 2025.

...

Allez !

Mathis, est-ce que tu peux te présenter succinctement

Mathis est le développeur depuis maintenant 4 ans pour Wishy Pity Today, donc on travaille ensemble. Et depuis maintenant un an je travaille en parallèle sur Eclos, donc une plateforme en ligne pour les coaches.

C'est quoi ton titre ? Developer full stack ? CTO mobile ? oui attends, j'ai vu ! CTO mobile. Est-ce que tu peux être CTO que du mobile ? Est-ce que CTO c'est forcément CTO ou CTO mobile ?

Je suis Citiomobile.

Je pense qu'il peut y avoir plusieurs CTO mais... Si tu mets deux CTO qui font la même chose ça fout le bordel. Donc il faut un sitio...

Ah non bah il faut un VP, il faut un VP of engineering en fait. Je pense que VP of engineering c'est au-dessus du CTO. Très bonne question. Dites-nous, dites-nous, dites-nous, dites-nous les amis. Qui est-ce qui est au-dessus du CTO ? Quand il en a plusieurs, est-ce que des fois il peut y avoir plusieurs ? Si dans les grosses DSI il y a peut-être plusieurs CTO. Mais est-ce que le DSI... Il faudra que je demande à Damien. On va faire un short link pour Damien. Didou.

je sais pas mobile...

Il y a plusieurs CEO il y a plusieurs sitios...

le classement des ordres de puissance dans les développeurs. sera ta tâche. Ok, ok. alors, quand est-ce que tu commencé à faire du rack native ?

Maintenant ça fait 4-5 ans je dirais, donc 2020-2021.

Ok, qu'est-ce que tu t'es dit ? Ouais, ça a l'air cool, faut que j'en fasse.

Parce que j'avais fait du flotteur avant et que la knatiss est plus simple.

C'est vrai que tu fait du flotteur carrément. Plus simple. Ouais, plus simple pourquoi ? Parce que tu as déjà fait de JavaScript avant et où

parce que j'ai fait du flotteur et un petit peu d'android studio et avec ragnative t'as pas tout le bordel d'android studio, les simulateurs tout ça avec expo ça va tellement plus vite que l'expérience de développeur elle est tellement plus efficace ça donne envie de développer quoi

Bonne réponse, j'avoue. Ok, donc alors tu nous as parlé de Declaw, donc on va faire un épisode spécial aujourd'hui. Ça va être spécial performance. On va parler un peu de ton app et on parlera aussi des 10 meilleures pratiques pour optimiser votre application Racknative. Ce guide nous a été offert par Colestack et on l'a lu religieusement. Donc pouvez partager tous les tips si vous n'avez pas le temps de lire les 120 pages, pense beaucoup beaucoup de pages. Beaucoup trop de pages. Donc éclos, éclos, c'est quoi?

beaucoup trop de pages.

C'est une solution pour les coaches sportifs. Avant, c'était beaucoup de paperasse. Je te donne une feuille avec tes séances de sport. Donne-moi tes bilans sur papier, il faut se voir physiquement. Là, c'est un peu une solution pour le coaching en ligne. Tu peux directement attribuer des séances de sport à tes clients, leur assigner des bilans, avoir des retours directement. C'est une plateforme web pour les coaches et une application mobile pour les clients suivant leurs séances.

Ok donc les gens ils donnent une lap. Attends c'est quoi le customer de journée ? non en tant que coach je dis en tant que coach je dis.

Alors, en tant que coach, je crée mes séances de sport et j'invite mes clients. Mon client reçoit un lien pour télécharger l'application, il se connecte et il voit directement les séances. Tu peux télécharger l'application directement sur les stores, mais tu ne verras rien parce que juste Apple oblige la création de compte, un accès à une application alors qu'il a pas de contenu, même si tu as de contenu payant.

Ouais, ok.

Ah oui et si les randoms tu arrives à les avoir, n'as pas une feature genre trouver les coachs autour de moi.

Alors si justement on a un onglet dans le profil, trouver un coach avec une recherche par sport différent, donc musculation, fitness, crossfit, et on peut choisir des coaches dans toute la France. Un coach peut se créer des fiches coach pour être disponible.

Ok, stylé, stylé, stylé. trop bien. donc alors, c'est quoi la stack technique vite fait ?

Alors, pour le web c'est du Nuxt, et pour le mobile du coup c'est Expo, avec des cols API simples, React Query, au niveau du back-end d'Ango. Et après pour tout ce qui est détail, on le verra au niveau de l'optimisation parce qu'on va en parler au niveau des states.

Donc on a 10 stack query, expo et...

native wind pour le style.

Ah pour le style vous avez pris native wind, ok. Ok ok super. Du coup on va faire... on va... pardon, au conseil numéro 1 qui est utiliser le React Compiler. Donc à chaque fois on aura une citation en anglais, Mathis va la traduire car tu un TOEIC de 250.

C'est peu 250.

ouais c'est peu, c'est combien le toic ?

Toi c'est 750 pour l'obtenir, c'est sur 1000 points.

! Et donc t'as eu convert au autoïc ?

760

Bon bah, tonique de 760, attention vérification. utiliser React Compiler. React Compiler est un nouveau conçu pour automatiquement optimiser les applications en utilisant la de mémohisation à la fin du Page 52. Qu'est-ce que ça veut dire, Matisse, ce truc-là ?

Donc en gros React Compiler c'est un outil qui permet au moment du build d'appliquer selon ton code. Alors il faut bien sûr que le code il respecte les règles de React. Si c'est codé n'importe comment ça va pas fonctionner. Mais en gros ça va appliquer directement au moment du build les useMemo, les Memoize. Tout ce qui fait que l'application va avoir des rendus plus rapides et plus fluides. Et donc ça c'est utilisé par méta, même si en fait c'est encore en bêta.

N'oui, donc.

mais Metal utilise eux, donc je ne pas s'il utilise vraiment en mode test en production et après il repasse dessus pour voir ce qui s'est passé, mais il utilise même si l'application est encore en beta. Donc si Metal utilise, je pense qu'on peut l'utiliser.

Ouais, faut tester en fait, en vrai c'est ça, le truc c'est c'est toujours les sortes, parcs, libraries et ce genre de choses. Moi c'est vrai que j'avais vu des... à chaque fois de toute façon que j'étais tombé sur une stack et que je voyais des use memos et des use callbacks, je me flippais parce que je m'étais dit c'est... c'est très bizarre, il y en a beaucoup de trop, il y en a partout et en fait j'ai l'impression que ça sert un peu à rien. Et donc là en fait...

Oui.

avec le React Compiler, permet d'optimiser de façon optimale au rip cette phrase, mais la magie apparaît sans que vous ayez besoin de manuellement dire spécifier useMU. Et en fait, c'est vrai qu'il a Ludwig dans l'épisode 1 qu'on a vu, qu'il avait essayé sur une de ses apps. Alors je ne sais pas s'il est allé jusqu'au bout. Mais le setup, comment ça fonctionne, c'est que oui, vu que c'est encore en bêta, sur Rack Native, il va falloir faire des optimisations avec Babel et Metro, il me semble.

C'est justement pour que le code soit bien formaté et que le compiler puisse bien fonctionner.

Ouais c'est ça ouais, franchement ça a l'air assez facile où il a trois trucs à faire en fait en vrai. Mais j'aimerais savoir si t'as des erreurs de compilation, comment ça marche ? Tu le vois compiler en local ou comment ça marche ?

C'est l'heure du build donc je pense que tu peux vérifier après.

Ouais c'est lors du build du coup, et après dans IAS peut-être que IAS, Itchi... Hey ! Ça marche pas because... J'aimerais savoir, j'ai pas encore eu le temps de diguer mais... Dites-nous ! Ouais, forcément, bah après tu peux le faire en local et tout pour voir la stack trace mais... On va savoir si... Je pense que les erreurs doivent être assez explicites, ça doit être genre oui ça marche pas plutôt que d'avoir un truc cryptique genre...

pense qu'il faut tester en dev build.

erreur build 65 qu'on connaît et là bah c'est les erreurs d'xcode classique tu sais pas où segmentation fault est là impossible de savoir de où ça vient. Ok conseil numéro 2 optimiser les animations avec RedDirectNative avec reanimated oui parce que use driver hein Mathis, plus l'utiliser on en parlera après sur notre super projet qu'on a fait de l'ondig page tu l'as utilisé Bon ça fonctionne mais il faudrait être reanimated. Donc, page 59. Qu'est que ça veut dire ce truc ?

Donc en gros, Animated de Recreative ça fonctionne mais c'est pas optimisé et c'est limité au niveau des FPS jusqu'à 60. Alors que Reanimated ça utilise le thread du high et donc c'est pas du tout bloqué au niveau des FPS, ça c'est plus que 60 FPS généralement parce que Reanimated est vraiment bien optimisé. Et en gros dans le livre Colestack, il parle de performance au niveau du rendu visuel. Donc la performance ce pas vraiment ce qui se passe à l'intérieur du téléphone et de l'application, c'est surtout ce que l'utilisateur va percevoir parce qu'on peut avoir une application très fluide mais un visuel qui lag alors qu'un visuel qui ne lag pas alors que l'application n'est pas la fluide, l'utilisateur a l'expérience d'une application rapide. Si c'est smooth, il va se dire l'application elle marche trop bien. Donc la performance pour call stack c'est le rendu visuel. Et avec reanimated c'est plus de 60 fps donc l'utilisateur a l'impression d'avoir un truc qui va super vite. Donc c'est pour ça qu'il faut utiliser.

Réanimated, alors attention on précise, Réanimated c'est fait par Software Mention, et pas Callstack. Donc on va faire tiens de... Oh !

Oui. Alors oui, Colstack précise qu'il faut une performance visuelle et Reanimated de Software Mansion offre cette performance visuelle.

C'est beau, on pourra faire un short avec cette phrase là, incroyable, incroyable. Oui, parce que ces deux boîtes qui sont en Pologne et qui travaillent à faire avec Nativ un bon écosystème, ils font des choses différentes. Super super et Réanimated, c'est vrai que moi je l'utilise tout le temps en J'ai fait un short avec, un short, vidéo avec Cataline si ça vous intéresse de diguer un peu le truc, mais ça s'installe super facilement. Vous l'instalez, vous avez même pas besoin de refaire... Il me semble que t'as même pas de refaire... T'as même pas besoin de refaire de dev build. Tu l'installes et boum c'est parti.

Euh non, c'est... ouais c'est direct. Mais du coup je me rends compte qu'on n'a même pas défini ce que c'était la performance parce qu'on parle du top 10 mais qu'est-ce que c'est la performance au final ? Alors j'ai récupéré la phrase. la performance c'est plein de petites choses. Donc ça peut être time to interactive. Donc ça c'est le temps que va mettre l'application entre le moment où on appuie sur le lancement et le temps où l'utilisateur peut faire quelque chose.

vas-y. Vas-y.

Ouais, tu t'y vois.

Il y a certaines boîtes qui utilisent le TSS, Time to Specific Screen, feature. ça, c'est admettons combien de temps je vais prendre pour aller jusqu'à mon édition de nom dans mon compte. certaines personnes vont mesurer ça. Si c'est une feature qui beaucoup plus utilisée, combien de temps j'ai pour y accéder. Parce que du coup, ça fait de la rétention d'utilisateurs. Et donc au niveau de la perspective utilisateur, j'ai dit mais un peu difficilement, donc c'est le temps que met une application à monter, faire voir un splash screen, un skeleton ou un jeu en étant prêt à être utilisé. Donc c'est le ready to use, il faut que ce soit rapide pour l'utilisateur.

Ouais. Comment tu dis monte Monté ? L'application est montée ? C'est très bizarre, je ne sais pas.

Ouais si... ouais... euh... Ouais si... Franchement je sais pas comment dire...

Non mais si c'est ça, en fait ça va rien. Je peux pas être à cap. Mounted, ok, got it. Mais l'application est montée et... Qu'est-ce que vous dites ? Dites-moi, dites-nous. Dites-nous sur les réseaux sociaux tout ça. Qu'est-ce que vous dites dans votre ad unit ? On attend... We are only to wait that the app is mounted. Ou alors on attend que l'application ait... Trois petits points. Ok, super donc...

Rendu.

compiler, on a fait compiler, a fait animation. Ouais rendu ouais, ouais rendu, mais... Ouais, ok. Donc troisième conseil, appliquer le view flattening. Donc view flattening c'est Reduce Signisted Views Can Significantly Improve Rendering Performance, page 113. Qu'est-ce que c'est le View flattening ?

En gros c'est vraiment le let's use more, c'est au lieu de faire beaucoup d'imbrications, donc une joue pour ce style là, ce style là, ce style là, on va essayer d'optimiser au maximum, donc c'est un peu le principe de faire le maximum de composants possible, c'est de réutiliser plutôt que de dupliquer. Comme ça on évite cette imbrication et le rendu. Donc en fait on va voir aussi après avec les autres conseils que le rendu c'est là où la performance est le plus absorbée. Donc plus il a de rendu, moins on a de performance. Donc il limiter ce rendu et limiter le nombre de views. Et ça marche avec d'autres balises que les views par exemple.

Parce que vu que c'est direct native, ça compile, si vous mettez des vues abriquées, plein de vues abriquées, derrière ça crée des composants natifs, ça utilise les composants natifs et donc si on a trop, ça sert à rien. ça, il faut une bonne gestion des composants et en fait le truc c'est qu'il faut factoriser... au max et avoir des primitives de base, vois genre ce que l'utilise. Ouais en fait les styles c'est vrai que c'est l'enfer en fait c'est pour ça que style sheet moi ça me rend ouf je préfère carrément Shopify. C'est quoi le truc du Shopify déjà pour le thème ?

C'est surtout au niveau des styles.

style.

Restyle, ouais Restyle comme ça on a des primitives super simples et après tu peux faire CVI avec Tailwind, ouais je sais pas je me rends pas compte avec Nativewind si ça fout plus le bordel ou pas quoi, c'est assez compliqué à suivre. Tu utilises CVI pour euh... ouais.

Euh... ouais. Si vieille avec note, il vous en prie.

Parce là, ça limite, ça vous fait des variants et ça vous limite pas, ça vous force à faire, pas dupliquer 50 fois la même chose. Donc... flattening, bah non, moi en fait c'est vrai qu'en ce moment je suis sur Tamagui et Tamagui pareil, le fait en fait. Quand il compile, il y a une phase de compilateur et avant d'envoyer au compilateur, t'as un compilateur juste pour le thème en fait et voilà il fait du view flattening aussi. Ok conseil numéro 4 fait des numéros pour ceux qui n'ont que l'audio avec la vidéo. Gérer l'état efficacement. Nous on a mis avec juste The Stand et Legend State. que nous c'est ce que j'utilise. Breaking State into Smaller Independent Atoms Reduces Unnecessary Rerenders. Page 42. Explique nous.

Alors du coup j'ai mis The Stand et Legend State. Legend State n'est pas mentionné dans le livre de Colstack mais je l'ai mis parce que je pense que Legend State a un peu émergé après l'écriture de ce livre.

Bah en fait, pas vraiment de ça, c'est plus qu'il est pas trop utilisé. Moi c'est parce qu'en vrai, on connaît Jay et Jay connaît Jamon et en fait voilà, c'est juste pour ça que... En fait je croyais que c'était plus ça, mais c'est que moi dans l'histoire que j'ai avec les State Manager, c'est que j'ai fait du rien, du Redux. Après j'ai fait du GraphQL donc comme Mathieu de chez Swan, l'épisode d'avant, il disait que... Quand tu fais du GraphQL, n'as plus vraiment besoin de State Manager puisqu'il est géré dans ton client GraphQL. Et après, j'ai refait du Redux et après du Rtk Query, parce qu'Rtk Query c'était vraiment beaucoup plus simple. Et là, il fallait en reprendre un pour la dernière app que j'ai faite et il fallait un binding offline. Et Legend State, il l'a. Donc c'est en fait dans l'histoire, dans le state of Rack Native, Il y a deux ans il y avait les John State, l'année dernière il l'ont retiré et cette année ils l'ont remis. Donc moi je sais que j'aime bien. Mais c'est que les gens, j'ai l'impression que The Stand est plus populaire.

Oui c'est ça, c'est deux solutions assez similaires mais elles font la même chose donc il faut juste choisir la solution qui convient le mieux, celle où on est plus à l'aise. Je sais que sur Legend State on peut directement aller sur le site voir les rendus. avec un bouton et plein de petits Jus on peut cliquer sur un bouton d'un côté en React Native UState Basique et de l'autre côté avec Legend State et on peut voir un peu comment ça se passe les rendus.

Pouce en plein.

Et pareil si vous l'utilisez dans votre application mobile avec les DevTools, on peut voir tout ce qui se passe au niveau des rendus à chaque clic. Et en utilisant les JohnStakes, ça fait dix rendus en moins. Donc plein d'utilisations de les JohnStakes partout dans l'application, ça va faire une performance qui va très vite être optimisée. Donc utilisez un gestionnaire d'état.

Ouais celui que... C'est qu'on y arrive assez rapidement en plus... Assez rapidement ils sont tous... Ils sont tous optimisés donc oui c'est vrai que...

faut pas se dire on met des use state au début pour attendre et après on met trois autres choses parce que ça va très vite. J'ai pas mal d'écran où il a des dizaines de states et au final je fais bon faut migrer ça maintenant. Comment on fait ?

Ouais.

c'est ce que t'as eu avec les clous là ?

Il a des écrans où par exemple il faut gérer le state d'une série de répétitions, d'un exercice, un chronomètre, donc très vite des écrans, a 10-12 states et si on ne gère pas ça et on ne les reset pas à chaque fois, ça peut très vite faire un bordel ou mal update les states justement.

Ah bah ouais, bah oui.

En plus, application mobile, c'est pas pareil que sur du web. n'es pas tout le temps online, tu n'as pas tout le temps... Tu peux pas tout le temps... Il faut avoir une expérience plus asynchrone que sur du web, où tu arrives vite. Et là, coup, dans l'app de Clos, vous allez... Donc là t'en as pas pour l'instant, t'as pas de solution, t'as RTK query, enfin React query, t'as un stack query, sorry, pour tout ce qui est data, source de vérité du serveur. Mais en local t'as quoi sur le téléphone ?

On va passer sur Legend State, pour l'instant il n'y a pas encore tout qui est migré. Oui, ça marche, il faut faire petit à petit parce qu'il a trop de morceaux à migrer d'un coup.

Ok.

Pour l'instant juste, juste ça marche.

Ouais, pour la migration, je dirais...

Mais du coup, le meilleur conseil, c'est de mettre un gestionnaire dès le début de l'application.

C'est toujours pareil, sinon tu serais... Ouais. Mais maintenant tu sais, c'est ton coup d'apprentissage, Mathis. Tu vas passer quelques points à refactor, mais... c'est ça. Pourquoi c'est important ? Parce que, oui, l'a dit, vrai que ça réduit le nombre de rerenders, surtout sur les grandes listes. Et en plus, il a tout le maintenant avec Nati.

Merci à

Avec les nouveaux specs de logging, expo les DevTools, ça fonctionne très bien. Conseil numéro 5, minimiser la taille du bundle JavaScript. que analyser le size et utiliser 3 treeshaking aide à éliminer le code Page 142. Moi, me rend ouf. Quand il a du code pas utilisé.

aussi mais en fait ça dépend de vos pratiques parce que là minimiser la taille on peut déjà le faire avec des pratiques comme ESLint qui vont nous indiquer le code inutilisé et après avant de push le code on fait un petit coup de lint et on vérifie ce qui peut être enlevé ou pas. Mais sinon il d'autres solutions, on peut vérifier la taille des bundles avec React Native Bundle Visualizer et on peut voir quelles sont les fichiers qui sont les plus gros dans notre application. On peut aussi activer le tree shaking, donc ça va être dans la config métro où on ajoute une ligne de code et ça va supprimer le code inutilisé au moment du build, comme ça ça réduit la taille de l'application.

Merci.

Et tu sais si ça marche avec Storybook ? Faudrait que j'essaye en fait ça.

Alors non, pour l'instant dans le livre, je n'ai pas cherché plus que ça, mais il parle juste d'applications à inclinatif de base, donc pas de storybook ou de test.

Parce que je vais le mettre. vous dirais quoi. Je vous dirais quoi parce qu'en fait en vrai le code il n'est pas shippé. Alors je ne pas s'il est shippé. aucune idée. Je ne suis pas sûr. toute façon il n'y a pas 50 000 choses non plus mais less is more donc on va essayer. Et pour activer le tree shaking, allez dans Metro, vous Transformer, Minifer, Config, Compress. Un use true. Ok, tu des exemples de...

Euh non, trois, enfin question de trois

Question 3, du coup remplacer les bibliothèques lourdes. là il a un exemple, y avait Moments qui fait 70 kilobits contre DIGS qui fait 2 kilobits, Redux, TheStent, plein de choses comme ça. il a aussi, il me semble que ça s'appelle du barrel import. C'est le fait de tout importer, c'est import étoile from l'audace par exemple.

Merci, sir.

oui, ouais ouais ouais ouais

En fait, sélectionner juste la fonctionnalité dont on a besoin et import, je sais pas...

Ouais c'est ça, moi sur l'Odash je n'importe jamais l'Odash. Quand j'utilise l'Odash je fais import, mettons take from l'Odash take. Du coup, avec sur VS Code vous avez Bundle Visualizer, ça vous dit direct combien le bundle import. Et moi je sais que ça je le fais déjà et dans le guide ils disent de...

d'utiliser Remeda au lieu de l'Odash. Ça j'avais jamais entendu parler quoi, j'en ai marre, dites-moi. Pourquoi il faut encore changer ? Mais je pense qu'en fait en vrai je sais pourquoi, c'est parce que l'Odash ça a été fait... Lo-dash release date ? C'était féquent Mathis, Lo-dash à ton avis ? Comme ça comme ça sans regarder sur internet. Première release. Première release 2012, 2012 tu vois ? 2012 c'était où ?

2017 ? là, non, j'ai rien trouvé.

J'étais mit 12, wesh. J'faisais pas de code.

Je faisais pas de code. Du coup, pense que Remeda c'est la solution. Ils ont tout refait avec TypeScript et je pense que tout le legacy, ils ne pas l'avoir. C'est toujours pareil, tu as des nouvelles librairies qui émergent, qui sont plus efficientes parce qu'il y a moins de legacy qui doivent être supportées en fait. Ok super donc oui ça c'est pareil si vous utilisez le bundle visualizer, npx-rec-native-bundle-visualizer-love vous allez voir accès aux librairies qui prennent de la place. Donc vous pouvez virer celles qui servent à rien. Je pense qu'aussi vector-icons ça vaut le coup de diguer le truc et de ne tout importer. Parce que vector-icons il y a quand même pas mal de fontes qui sont importées de symboles tout ça. Ok, est-ce que tu as un autre conseil pour minimiser la taille du bundle ?

utiliser Xpo Optimize avec les images. que les assets ça prend de la taille, c'est gourmand et donc il faut les optimiser pour l'affichage sur le mobile surtout que sur le mobile on n'a pas besoin d'image avec une aussi grande qualité que sur le web vu que l'affichage est plus petit.

J'ai juste essayé de faire. J'ai fait chouer sur le projet de cache au bose. Je NPX Expo Optimize Proceed Yes Optimize asset. Donc ok ça crée un super dossier asset. Et à ton avis, quel est notre copain qui pète un câble

les images. Est-ce que tu connais une librairie qui est assez ennuyeuse quand on gère des images ? Ça commence par un S, ça finit par un P. Sharp. Tu rappelles Sharp ? Le fameux. Donc en fait il faut juste l'installer de façon globale, c'est ce que je viens de faire. Et là du coup il a optimisé, il a sauvé 320 kilobytes. Et ben...

bah oui, sharp, ok.

Ok, donc il doit à mon avis, il doit run un algorithme d'optimisation d'images, c'est vrai qu'il faudrait que je regarde avec imageoptime, parce que moi j'ai un logiciel sur Mac qui s'appelle imageoptime qui optimise les images et jpeg mini aussi. Alors je sais pas quel algo ils utilisent, faudrait regarder. Bon, au là, il n'y a pas besoin d'installer de sort part logiciel, vous faites ça, hop, ça marche direct, je viens de le faire. Ça m'a pris 30 secondes. comptant l'installation de Sharp. il n'y a vraiment aucune excuse. Faites NPX Expo Optimize Today pour économiser de la bande passante et procurer de la joie aux utilisateurs qui sont dans les transports en commun. Enfin, quoique non, les transports en commun ça marche plus. Il y a du réseau avec les transports en commun. Ok, donc le conseil numéro 6. éviter les rerenders inutiles avec React Memo et Use Callback. Donc c'est quand pas ce qu'on a dit. Every unnecessary rerender slows down your app, page 13. Ok, là on aurait... Donc vas-y, explique déjà qu'est-ce que c'est React Memo.

c'est pour éviter de rerender un composant donc ça le stoc entre guillemets en local pour éviter de faire un rerender quand on update un state par exemple un clic d'un bouton pour incrémenter un nombre

Mais du coup c'est un peu vrai, c'est vrai qu'en fait ils disent de l'utiliser mais en même temps ils disent de pas l'utiliser parce que du coup il y a React Compiler qui va le faire.

On peut utiliser Red Compiler mais on n'est pas obligé de faire des React Memos si on utilise The Stand ou Legend State. On va faire un Rewinder de seulement du bouton sur lequel on appuie.

Après, c'est comme les conseils en sécurité. En vrai, on suit 100 % des conseils en sécurité, au bout d'un moment, on baisse dans les stats parce qu'il a des conseils qui se clashent entre deux et ça ne pas. Tout ça, il vous faire avoir en fonction de vos problématiques. Si vous lancez votre app avec Expo, vous appuyez sur J. vous ouvrez le flame graph et là il diguer en fait. Si à un moment vous vous rendez compte que oui mais là dans ma scroll view horizontale il y a une vidéo et juste ce composant là je vais être sûr que il n'y a pas de render et vous foutez un rec memo comme ça au moins vous êtes sûr quoi. Je pense que ReacomPyler ça fait plein d'optimisation que toi t'as pas conscience en fait. Et donc useCallback. Qu'est que c'est ?

c'est pour éviter de recréer une nouvelle fonction à chaque render. c'est juste, j'ai une fonction getDate. Si j'appuie sur un bouton d'un écran et à chaque fois sans le useCallback, ça va refaire un getDate. Donc, on évite de réappeler cette fonction. Ouais, c'est ça.

un peu.

Ouais pour le part, fait ça dépend comment tu mets ta... Comment tu encapsules... Eh c'est beau ! T'es composer mais ça se suit sur le part.

Ok donc le conseil numéro 7, charger du code à distance uniquement lorsque c'est nécessaire. Donc do not load out code at launch, it on demand. Page 163. Comment on fait ça pour fetch on demand ?

on utilise react lazy. Donc en fait, le principe c'est on affiche seulement les composants nécessaires au début et tout ce qui se voit pas, admettons on est dans une liste ou une scroll view, tout ce qu'on ne voit pas au début on le laisse en lazy. Comme ça l'utilisateur a directement un aperçu d'éléments et il peut voir le reste après. Comme on a dit au début, le plus important c'est la performance visuelle, c'est pas vraiment la... réperformance, que le temps que l'utilisateur voit quelque chose, il est content. Et avec TrackLazy, on fait charger plus rapidement les autres composants en laissant les composants qu'on ne voit pas au début, chargés en arrière-plan.

Et c'est précisé si tu peux le faire entre sur des screens entiers.

Il faudrait aller revoir dans le livre, là tout de suite je pourrais pas donner de réponse.

En fait je me demande si tu un navigateur entier, tu lui fais un REC NAILSY sur l'intégralité d'un navigateur, il ne jamais charger tout ce qu'il y a à l'intérieur tu vois en vrai. donc je me demande, possibilité que sur la navigation ça fonctionne pas ce genre de truc.

Oui.

Moi je sais que je l'avais déjà fait en React Web.

Mais en règle native, ça, je ne sais pas du tout comment ça se comporte. de rétester. en attendant ils disent pas... Peut-être que je sais pas comment elle fonctionne à la pléidora clési. Tu peux mettre des skeletons ou ce genre de choses où ça les load direct.

Justement, il me semble que c'est ce qui est fait. Parce qu'il disait aussi que même si on a des squelettons, l'utilisateur voit qu'il se passe quelque chose. C'est un peu le principe de l'activity indicator. C'est le temps qu'on voit quelque chose sur notre écran, on sait qu'il se passe la magie derrière des requêtes ou du chargement, donc on reste.

Ok.

Ouais.

Ouais c'est ça, c'est mieux d'utiliser l'activity indicator de RECNATIVE parce que comme ça de base c'est le spinner de l'OS et comme ça les utilisateurs ils ont l'impression que c'est le téléphone qui se galère, c'est l'OS qui galère et pas votre app. Ok, donc faudrait creuser... J'ai serré, j'ai serré, tiens, truc là, comment ça fonctionne vraiment. Conseil numéro 8 accélérer l'interface avec concurrent react. Perceive performance is often more important than actual performance. Page 46. c'est quoi react concurrent mode ? Je crois que c'est ça la définition exacte.

en gros, va permettre d'accélérer l'interface parce qu'on va précharger des choses ou appeler des fonctions pour faire des transitions. Donc, par exemple, useDiffirT value dans un state, on va pouvoir utiliser l'ancienne valeur le temps que la nouvelle se charge et se met à jour. Ça permet d'éviter d'avoir un blanc ou une skeleton.

S C'est quelle version de React ça ?

euh 18 depuis le règne 18

Et donc RAC18, parce que là on est en SDK 52 Expo, RAC Native 077 et c'est encore la 18 aussi. Ok, ok, parce que...

Et pareil, l'utilisation de ce spence pour charger le contenu progressivement.

Parce que ceux là, c'était les use different value, use transition, ou que là, moi perso je ne les ai jamais utilisés. Parce que j'ai toujours pensé que c'était que sur le web en fait.

Et en plus, quand je les avais vus, React Native, il y un petit délai entre les versions de React généralement. Ça dépend des fois, il n'y pas de stats universels là-dessus. Mais ok, est-ce que sur Eclos tu vas mettre des useDifferedValues ? Non.

Nnnooo- C'est pas un truc auquel je suis habitué. Après il faut tester mais j'ai plein d'autres optimisations à faire avant d'arriver sur les différentes values.

J'avoue, j'avoue, j'avoue. Mais donc... Ok, ouais, donc ce genre de hook ça permet d'empêcher l'Ui de freezer. C'est vrai que je teste, moi, c'est vrai que j'ai des trucs un peu compliqués. Non, mais moi ils sont déjà dans le state, et déjà dans le legend, donc c'est déjà optimisé. Moi c'est juste un peu lent parce que je fais opération Bluetooth, donc... pourrais pas utiliser ce genre de choses, malheureusement. Ok ouais c'est donc... vas-y

Alors, une petite information en plus, viens de vérifier. vrai que j'aurais dû le mentionner, mais pour utiliser concurrent React, coup, il faut la nouvelle architecture.

Ah ! Bonne précision ! Bonne précision ! Parce que moi je suis pas encore passé New Arch... Éclos ou pas ?

Ouais, depuis peu.

Bravo, c'est beau.

Mais en fait il faut vérifier si vous avez une nouvelle architecture et qu'on vous dit unsupported package, par exemple Stripe, ça dit que c'est pas supporté mais selon les fonctionnalités que vous utilisez, ça peut être supporté. Donc globalement il a la moitié des fonctionnalités de Stripe qui ne sont pas disponibles dans la nouvelle architecture mais comme nous on ne les utilise pas, ça fonctionne quand même.

Ouais ok. Ok ok moi je suis encore sur Old Arch, j'ai voulu le faire, ça a bugué. En fait je crois que Tama Guaï il y a des... faut que je vérifie le setup en fait. Il me semble qu'il y a des trucs qui fonctionnent pas encore. Puis moi j'ai voulu tout faire d'un coup en mode allez vas-y, let's go. Mais bizarrement j'avais des... si c'est ça je sais, c'est MMKV. En fait j'ai voulu passer... Ah c'est ça ! En fait j'ai voulu passer MMKV, le concurrent d'Async Storage, est plus rapide, sur la version 3. Et la version 3, faut New Arch, et du coup je New Arch, et en fait pour ça il faut que je checke Tabak Uai. Et du coup j'ai fait un rollback, parce que je me suis dit ouh là, je vais pas dig leur habit, oh le 2 ! De tout vérifier et pas le temps donc... même qu'il v2 pour l'instant. Et ça marche très bien, donc je ne pourrai pas bénéficier du concurrent mode React. Tristesse. Mais grâce au conseil numéro 9, qui est désactiver la compression du bundle JavaScript. donc Disable JavaScript Bundle Compression Can Improve Execution Speed, page 175. Alors ça, j'ai dû lire trois phrases. J'ai dû lire trois fois la phrase. que j'avoue j'ai pas compris.

En gros, tu peux désactiver la compression parce que la compression elle fait, en fait elle augmente la taille de l'APK et elle augmente le time to interactive. Donc en fait, c'est pas optimisé pour Android et si tu désactives cette compression dans le buildgradle Android, donc ça ça doit être dans le package sur expo au niveau de l'app config. tu peux avoir jusqu'au moins 16 % sur le Time To Interactive.

C'est ce qu'ils ont mesuré. Franchement stylé. Là je suis en train de regarder. App Config, Android. donc là je vais mettre virgule. Je fais Control Space. Vu que j'ai le VS Code extension Expo, me modifie les choses que je peux modifier. Et attention, Android, Android Resources, runtime version. C'est dans quoi t'as dit ? Android,

et dans le livre c'est dans Android, Android Resources, No Compress mais je pense qu'il ne le mentionne pas pour Expo, c'est ça.

Peut-être qu'il n'est pas encore documenté. Je suis quasi sûr qu'on peut l'ajouter, mais c'est peut-être pas encore documenté. J'ai Bundle Pass, Manifest Pass... A voir. Je suis certain qu'il a moyen. Il a toujours un moyen.

Mais de base il le mentionne pour le buildgrad de l'android, donc pas pour expo.

Ouais ok ok mais même c'est pareil il faut que je vérifie je peut-être pas à jour de toutes mes extensions. Ok intéressant tu vois tu désactives un truc pour tu désactives la compression pour que ça aille plus vite. Intéressant.

et la Team Rack Native est en train de le mettre par défaut.

Ah ok, c'est ça. Après, faut vous tester, vous mettez un petit commentaire, delete that later. voilà, ça va bien se passer. Ok, et le dernier, numéro 10, c'est utiliser flashlist au lieu de flatlist. Because flatlist is performant but flash... Putain, je vais la refaire. Flatlist is performant but flashlist is even faster. Page 40.

Donc flashlist c'est de Shopify, flatlist c'est de Reat-native donc c'est performant, mais pour les lists de moins de 1000 éléments, donc ça arrive quand même très souvent, flashlist de Shopify c'est beaucoup mieux. C'est plus performant, c'est moins de lag, c'est fluide, mais à partir d'un certain nombre d'éléments dans des trop grandes listes ça lag, donc il faut utiliser flatlist.

Ouais, j'avoue. Après, moi j'aurais mis aussi...

Legendiste.

Ben je regarde, je regarde s'il a mis 1.0, Il a...

En fait, c'est faux. Ouais c'est comme The Stance

Ah c'est pas encore précisé. C'est pas encore précisé. Oui en fait il a plein. y a aussi la personne Jay, on lui fait un big up, big up Jay. Il travaille aussi sur un composant qui s'appelle LegendList et qui est encore plus rapide que FlashList. Parce que lui c'est qu'une approche que JavaScript. FlashList, c'est les optimisations pour des composants natifs. Mais ce qui est fou, c'est que LegendList, c'est plus rapide en utilisant que du JavaScript. Mais pour l'instant, c'est pas encore stable. C'est pour ça que tu fais bien de ne le préciser. Mais c'est vrai que je trouve ça dingue qu'il y ait trois composants différents pour faire des FlatLists. Mais ce qui bien, c'est qu'ils ont tous la même Surface API. Je pense. Non, c'est vrai que ce que tu dit c'est que Flashlist de Shopify, peux lui mettre une prop Estimated Item Size et du coup tu lui dis mettons 25 items estimés du coup ça va être plus rapide. A scroller ou à render ? Oui c'est pareil ça ne rende que ce qui est visible.

C'est pour ça, essayez les trois.

Il faut essayer les trois de nous dire quel est le plus rapide. que après c'est bien précisé, les journalists ils disent que c'est expérimental et bon c'est pas production ready. Donc moi je partirai pas là dessus. Si je veux vraiment faire l'optimisation sur une app en prod, je mettrai plutôt Shopify. En plus c'est vraiment no brainer. Il y a juste à installer la lib, changer l'import, terminé. Il n'y a pas de changement plus ça à faire. Donc ça c'est bien. Ok super. Donc on a vu nos 10 conseils. Est-ce que... Est-ce que il a... Donc j'ai une question quand tu travailles dans ton day to day c'est quoi ton setup ?

C'est à dire...

combien tu as d'écran ?

Bonne réponse, déjà ça marche. Faudra prendre une photo de ton setup. plus aussi, tu quoi pour debug sur Android comme téléphone ? C'est quoi la marque ?

Oula alors moi j'ai un Honor 8x qui doit dater de 2016 ou 2017 donc c'est très bien parce que du coup quand je dev, si ma fonctionnalité fonctionne sur ce téléphone, même avec du lag, c'est qu'elle fonctionne partout ailleurs.

C'est bien, well done. Bonne réponse. Moi c'est un Samsung... Je ne sais plus lequel, je le chercherai. Je le dirai Samsung S10.

Si vous voulez optimiser vos applications, utilisez des vrais téléphones parce que les simulateurs, ment !

oui, ça oui, mais clairement, oui, mais simulateur, bah oui, si tu loupes sur un Mac M3 Max, c'est pas du tout la réalité quoi. Est-ce que tu eu des différences à gérer entre Android et iOS sur l'app Euclid?

ce qui est un peu de... les modal, c'est des trucs un peu natifs où sur iPhone c'est un peu beau, tu peux les customiser mais sur Android t'as la petite pop-up blanche un peu moche qui lag beaucoup.

Ouais, tu as utilisé la modal que de React Navigation. T'as pas utilisé le modal modal ou le screen modal ?

Moodle Moodle

oui, modal from ragnative. oui, ça c'est... Ça fait longtemps que je n'ai pas utilisé celle-là, j'avoue.

Oui, c'est ça. Merci.

Donc ça pour la performance, n'est pas top.

Ouais... oui parce que... Attends ça arrête d'aller...

En fait c'est fluide sur iPhone, tu peux avoir des belles modales, tu peux les rendre un peu plus mousses avec des transitions alors que sur Android tu peux pas faire ça et c'est directement une modale qui pop sur ton écran et qui... t'as pas vraiment de l'interaction visible comme sur iPhone.

Ouais ok, super. Et est-ce que tu as un sujet que tu auras aimé aborder ?

Non, on a fait le tour de toutes les optimisations là. Ah si ! C'est quoi ton optimisation que tu mets en place sur tes applications toi ?

Ça c'est...

à la mienne. Il faut que je regarde parce que j'ai un Mind Nod. Je vais sur Reka, je vais faire MS Performance Checklist. J'ai une performance checklist de la Moirte. La première je dirais. Ouais si, moi de libérer qui ne à rien, mettre à jour toutes les briéries, mettre à jour tous les SDK. ce genre de truc quoi et tout le code d'aide avec S-Line Prétyre tout le en fait. que ça de base je le mets parce que ça me rafle déjà quand moi je l'installe qui est librairie qui ne à rien. C'est vraiment le truc que j'ai en place et après ça dépend vraiment parce que chaque projet est différent donc tu peux pas vraiment dire euh... tu vois genre là si on prend le truc des flatlists bah là projet pour lequel je bosse en fait il n'y a pas. Enfin y en a une. Donc en fait euh... y a 10 items dedans enfin c'est pas... c'est pas un feed à l'instagram quoi. Donc qu'on conseille, il sert à rien. Après euh...

Merci.

Par contre le conseil de bundle size et tout ça dans toutes les apps, y est c'est sûr. là on parlait de conseil numéro 3 c'était le view flattening. là pareil je le fais pas parce que j'utilise Tamagui et Tamagui il le fait pour moi. Donc il n'y a pas vraiment de liste ultimate à mettre en place. Ça dépend vraiment des problématiques du chacun comme on l'a vu.

Merci.

Superbe !

Je pense que la prochaine étape c'est peut-être optimiser la navigation. Prochain épisode.

la neuve ! Qu'est-ce t'entends par optimiser la navigation ?

quand tu interagis pour aller sur un nouvel écran, si tu as des grosses tâques de navigation, ça peut être plus long à charger, comment faire pour optimiser ça quoi. Je sais qu'avec export à hauteur, tu as les slots qui permettent le rendu.

Ah oui comment tu... Ouais Comment tu fais pour, avoir une expérience fluide, fetch les data de l'autoscreen, c'est vrai que t'as plein de solutions ce genre de trucs. C'est que... un épisode spécial navigation et performance où vous n'avez juste la navigation. Franchement en vrai, y'a rien de quoi faire. Juste un épisode pour la navigation, mais laisse tomber, on peut en faire pendant trois heures parce qu'il faut expliquer tout ce qui est... Toutes les...

c'est ça

...

les solutions de navigation qui existaient avant, solutions qui existent après et actuelles. Ouais, il faudrait. À ton avis, qui c'est que je devrais inviter dans le podcast pour... à une prochaine émission.

Dans la prochaine émission, on essaie de vous trouver un membre de l'équipe Ornicart car oui, la semaine prochaine on va à React Native Connection et le regagnant du Ticket Bonus est un membre de l'équipe Ornicart.

J'avoue. Et donc il ne sait pas encore mais il passera dans le podcast. Oui oui donc Ornicard ils font le code, c'est ça, c'est le code de la route. Ok ils ont une app mobile et tout à mon avis et pour réviser le code. Trop bien, j'aurais kiffé avoir ça quand j'étais au lycée plutôt que... Non bah non moi j'allais en sortant du...

Voilà.

Oui c'est ça.

Au lieu d'avoir ton petit livre.

On va faire les sessions de code sur place.

Après le bus, en bus direction Guine, bien hop, je m'arrêtais à Coulogne pour aller de 18h30 à 19h30 au code avec les manettes qui étaient de la taille de trois Game Gear, tu Du coup, mieux tu j'aurais préféré, il faudrait faire ça dans le bus déjà. Ok. Bon, c'était cool. Mathis, où est-ce qu'on peut te retrouver ?

Sur Twitter, BlueSky, partout sous le même pseudo, Matisse Dev.

On mettra ça dans les notes de l'émission, moi c'est Flexbox, pareil un peu partout, sinon vous pouvez aller sur Wishy Pity Today. Et n'hésitez pas à lâcher 5 étoiles et à nous dire dans les stars... 5 étoiles et nous dire votre conseil performance. Ça, ce serait une bonne idée pour partager avec la communauté sur Apple Podcasts. Et Spotify, je pense pas que tu puisses lâcher dire... Je pense que tu peux juste mettre des étoiles sur Spotify. ouais ? bah allez, on va utiliser la feature parce que je sais que ça tombe. J'ai un feed dans le backend du Spotify Creator, j'ai les commentaires. Du coup, voilà. Et vous serez featured au prochain épisode. Ça c'est beau, c'est beau, c'est Bon bah super. J'espère que cet épisode vous a plu et on se retrouve la fois prochaine. Ciao !

Non, tu peux mettre des commentaires.

Ciao !