C'est vraiment difficile de faire des choses à 100%.
Et donc, quand nous avons sorti de toutes ces conclusions,
nous avons dit, ok, c'est assez clair que
la chose idéale de faire est une migration de la Grande-Bang.
Ce n'est pas que ça va être facile,
c'est juste que nous pensons que ça pourrait être un peu plus facile
et que ça sera une meilleure expérience pour tous les ingénieurs à Stripe,
qui est la priorité de tout le monde.
Bonjour, bienvenue à la podcast de DevTools FM.
C'est un podcast sur les tools de développeur et les gens qui les font.
Je suis Andrew et c'est ma co-host Justin.
Salut tout le monde!
Aujourd'hui, nous sommes jointes par Tyler Kruppika.
Tyler est sur la team de l'expérience de développeur à Stripe,
et nous sommes heureux de lui nous joindre à nous parler de son rôle
et de sa récent expérience en m'a aidée à migrer à Stripe's codebase
de la type script de Flow.
Mais avant de nous en avoir, Tyler,
Would you like to tell our audience a a little more about your time?
Sure, thank you for having me.
So I'm on the JavaScript infrastructure team at Stripe.
Broadly, we're kind of focused on improving developer productivity
for any front end applications across the company.
And like Justin mentioned, my focus most recently has been migrating us
from Flow to TypeScript, which has been quite a long process.
So what exactly does that team do,
other than like the project we're going to talk about mainly?
What are some other initiatives that this team has led?
Yeah, that's a great question.
So I'm inside of the developer productivity organization at Stripe.
And so for a little bit of background,
there's there's probably over 10 teams in developer productivity there.
And like some of them could be some of our what we consider like core build code
testing teams.
So that's like our build infrastructure,
GitHub, source control or developer environments.
But there's also like language and developer specific teams.
So specifically, my team is focused on JavaScript,
but we also have teams that support like the Ruby API,
Java services, data science, things like that.
And so as far as like my team goes,
we're really focused on like build times
or other things that could really slow down front end development.
So the type system is a big thing,
but we've also done projects around dramatically speeding up
the build times or improving the reliability of tests or things like that.
So is all the code in like one code base?
Is that kind of why you have to have have these teams?
Yeah, so Stripe is very close to a monorepo,
not quite a monorepo,
because some of our code has different like compliance requirements.
There are some like separate repos.
And so we have some of our front end code in one repo,
but the majority of it all is within one big monorepo,
just in different directories.
So when you have that going on
and you have some like huge applications all in that monorepo,
there's a lot of extra tooling you need in place
to make that all work nicely and orchestrate everything.
We use Bazel pretty heavily for kind of breaking up this big monobild.
I think actually recently,
the one of the engineers who works on our Bazel implementation
put up a blog post on the Stripe Engineering blog
about how that is all set up.
But that's definitely like one of the big focuses.
A lot of engineers that develop our productivity help with.
What do you use as a repository provider?
Is it like or a source control?
Is it like Perfor?
We use GitHub.
We have an enterprise GitHub instance
and a team that manages that as well,
which, yeah, it is always,
it seems like they always have a lot of work to do as well,
just making sure that GitHub experience works well
when you have a huge code base
with lots of pull requests open against it.
Yeah, monorepo is in Git,
like really big monorepo in Git can be.
Yeah, just even the Git command line
can get pretty slow sometimes
unless you have people actually focusing on optimizing it.
Yeah, it seems like Git is a lot better at scaling
to many different repos
than it is for scaling to like a monorepo.
But it's definitely doable
and a lot of people have their work cut out
for them making that happen.
Do you know how they optimize it at all?
Parce que si je faisais ce problème
de l'optimiser le Git repo,
je serais comme, je ne sais pas,
de retirer les gros files.
Je pense que le plus important que nous devons travailler avec
est de mettre un ton de branches à l'open,
qui font des problèmes.
Vous pouvez imaginer si vous avez
des milliers de enjeuners qui travaillent,
ils créent beaucoup de branches,
pas tous les enjeuners sont fermés,
il y a aussi des branches automatiques et des trucs comme ça.
Donc, de garder ces enjeuners en check
est une chose que je sais au bout de ma tête,
ça m'a aidé beaucoup.
Et il y a des trucs que vous pouvez faire
sur la ligne de commande,
par exemple,
on essaie d'avoir un bon nom pour les branches,
donc je prépare toujours avec mon nom de user
et il y a aussi des flags CLI
que vous pouvez mettre
pour que vous ne faites que des branches
pour que vous puissiez commencer avec votre nom de user
sans que vous les faîtes explicitement.
Et ça aussi t'aidera
quand vous êtes en train de faire un master,
vous ne faites pas de la waiting
pour quelques minutes et quelques minutes
pour que ça soit en train de faire un peu de travail.
C'est bien.
C'est un tip utile.
Je vais devoir le faire,
parce que nous faisons la même chose
où c'est notre nom de user
sur une ligne de commande.
Donc, on va nous faire
la migration de typescript.
On va commencer par pourquoi.
Pourquoi aller de cette base de code
d'exploitation
à un code de code de typescript?
Ça semble être un nombre immense
de travail
et peut nous permettre
d'avoir un nombre immense de problèmes.
Donc pourquoi même faire ça en premier?
Oui, c'est une question très grande.
Et donc, une petite background
sur le niveau de flow que nous avons.
Stripe a commencé à utiliser le flow
assez rapidement
dans sa usage,
qui est à la fin de 2016.
Et je pense que ça a été
aussi en train de se faire
beaucoup plus gravement
en utilisant React.
Ce qui est assez commonly
que les gens ont fini de utiliser le flow.
Et à la fois,
c'était
une chose vraiment raisonnable
et Stripe est en train de
faire un type de sécurité.
Stripe aussi maintien
Sorbet,
qui est le type checker
pour Ruby.
Et donc,
comme tous nos Ruby
ont aussi ça.
Et donc, ça a été
en use pour assez de temps.
Nous avons
créé toutes les applications
de la front-end.
Et donc, entre tous les
des codes de type flow
de 5 millions de lignes,
dans la compagnie,
3,5 millions de lignes
sont juste le dashboard Stripe,
mais, vous savez,
les éléments Stripe
ou les Strype JS SDK,
ou toutes les
des flows de payments
et des choses comme ça.
Ce sont tous les éléments Stripe
et les flows aussi.
Et je pense que, à la première
fois,
le type script et le flow
ont eu beaucoup de paroles.
Vous savez,
il y avait beaucoup de choses
dans le système de réaction
qui avaient de support de flow
à l'arrivée,
mais en temps en temps
c'est certainement
dévergé
où,
comme vous voulez,
une troisième partie de
des definitions de type
pour
tout,
comme
tout a support de type script,
quasiment tout a support de flow.
Je pense que le document de type script
a aussi
vraiment été un long tour de la vie.
Juste,
il y a des types de utilité
que je ne suis pas sûr
que le document soit encore
sur le site de flow.
Et donc,
le type script a évidemment
investi beaucoup
en le faire vraiment bien.
C'est un long tour.
Donc, c'est utile.
Je pense aussi
que
le moyen où les choses vont
presque tous les nouveaux outils
qui viennent
tenter de soutenir le syntaxe type
de type script
de la box.
Et donc,
quand vous pensez
en commençant à utiliser
la prochaine génération,
construire des outils
et des choses comme ça,
vous voulez que
votre code soit compatible.
Et puis, je pense que l'un des plus
plus grands choses
que ça a aussi
kind de nous a dépassé
pour priorité
était
à la fin de mai de 2021,
le team de flow
a mis un poste
qui a basically dit
que nous allons être
focussé un peu plus
sur le engagement de la communauté.
Et,
vous savez,
ils ont un ton de développeurs
sur Facebook
qui utilisent le flow.
Et donc,
ils sont vraiment
mettre le roadmap
pour faire
les choses belles
pour tous ces ingénieurs.
Mais,
ce qui veut dire
que les réquisitions de feature
de la communauté
ou d'autres entreprises
vont être prioritées.
Et donc,
TypeScript
a été vraiment bon
pour avoir
cette
vraiment
publique
communauté
élevée
dans le roadmap
et dans le cycle de tests
et tout.
Donc,
ça a été vraiment utile.
Et puis,
le autre
probablement
la dernière chose
est
les ingénieurs d'éditer
aussi.
Donc,
TypeScript et VS Code
sont juste
comme
les ingénieurs d'VS Code
sont parfaitement paires.
Il y a beaucoup de nouveaux features
qui sont venus pour cela.
Et Flow
a bien fait
l'effort
pour
improving
leur
ingénieurs d'éditer
en temps
mais
il y a encore
des moyens
et donc,
en étant
capable de
poursuivre
les impôts
pour

stock J.S.
formatant
tout ce qui est
vraiment bon
dans le code VS.
Toutes ces features
sont
vraiment réquises
et vraiment bonnes.
Je pense que c'est vraiment
intéressant
d'étudier un étudiant
pour comparer
le cycle de vie
de Flow
et TypeScript.
Donc,
Facebook a
cette
très common
chose
où ils
construirent
les projets d'études
pour leur utilisation interne
et ils font
un point très explicant.
C'est pour nous
et
nous avons un
point de vue
pour ce qui est
l'opinion
ou quelque chose.
Vous pouvez l'utiliser
et l'utiliser
mais nous sommes
construits pour nous.
Et React
est très fameux.

ils ne sont pas
réellement
des features
que ils ont
d'intérêts
pour des années
jusqu'à
s'ils sont
stabilisés
ou quelque chose.
Mais Microsoft
tend
à
produire
l'opinion
d'études
pour sure.
Donc,
TypeScript,
d'aujourd'hui,
a été
formulé
par des produits
qu'ils ont
travaillé sur.
Ils ont sorti
de la manière
qui est
une des
années
où
la différence
que ça fait
un de mes
collègues
de l'article
Orda Thierox
était sur le Team TypeScript
pour un peu d'un moment.
En travaillant sur l'opinion,
c'est
principalement
ce qu'il a fait.
C'est que
j'ai envie de
l'expérience
d'être
plus belle.
C'est
une faible
priorité
pour

un peu
de l'expérience
d'être


cet œil.

balco�
sont
mentioning
la
de façon sur le top. Ils ont des versions sélectionnées, des exemples, tout ça.
Il y a été un grand investissement.
Un grand shoutout à Orda, parce qu'il a inventé un tout technologie stagiaire pour
faire cela possible. C'est vraiment cool.
Oui, oui, oui.
Je vais vous dire une question pour les deux de vous. Vous n'avez même pas
pensé à la flotte de votre livre, je suis curieux.

Je l'ai fait quand j'étais le premier à commencer à se mettre en JavaScript.
Je pense que comme les gens qui ont l'architecture théoretique de Flot,
c'était plus intéressant de voir comment il a fait la check-in type et qui sort de
un graphiste comme celui-ci, sous la couche.
Et ça semble être le plus correct de la façon de l'approcher type.
Donc, à l'initialité, j'ai aimé Flot mieux que TypeScript.
Et il y avait des choses qui, en les jours plus tard, n'étaient pas
nécessairement bien documentées avec TypeScript.
Et c'était un peu difficile de se faire en sorte que...
Et il y avait un peu de priorité à l'initialité, envers React.
Oui, oui, absolument.
Je pense que le point qui a vraiment commencé à changer
c'était la soutenir de la communauté.
C'est exactement ce qui a vraiment commencé à faire Flot.
Et puis, le type-engin pour TypeScript a juste continué à se mettre
plus et plus et plus et plus.
Donc, c'est comme...
Lorsque le façon d'interprimer les typeshack,
TypeScript a devenu un usage vaste ou supérieur.

Et je pense que, Andrew, si vous n'avez pas utilisé Flot avant,
l'une des choses les plus intéressantes de la première fois que vous essayez de l'envers,
c'est différent de TypeScript.
Il y a beaucoup d'autres features qui sont construits en inference, je pense.
Donc, si vous...
En TypeScript, si vous allez et vous définissez votre première fonction,
les paramètres de fonction doivent être expliqués.
Donc, vous avez la paramètre A, c'est un string,
et vous dites cela quand vous déclarent.
Avec Flot, si vous allez et vous déclarent une fonction,
vous n'avez pas de donner ce type de paramètres.
Et puis, quand vous collez la fonction,
si vous passez un numéro,
alors, ça va et ça plage.
Qu'est-ce que ce soit un numéro?
Et il déclare la fonction et il dit,
maintenant vous appelez la fonction spécifique de la string,
et ça vous met en retard.
Donc, vous avez un numéro,
et vous avez un numéro,
et vous avez un numéro,





et vous avez un numéro,
et vous avez un numéro,
et vous avez un numéro,
et vous avez un numéro,
et vous avez un numéro,
et vous avez un numéro,
et vous avez un numéro,
et vous avez un numéro,



et la version d'Arte que vous avez
et constater que votre menu n'a que des items de menu comme un enfant.
Vous pouvez faire ça en type script, mais ce que vous avez dans l'endement
n'est pas ce que vous voulez, même si c'est le genre de chose que vous voulez.
Oui, c'est l'une des zones principales que j'ai vu à FloExcel.
Il y a quelques choses aussi.
Dans les types scripts, il y a toujours un couple de petits rouges
autour des types de retour fonctionnel ou quelque chose.
Vous ne pouvez pas juste retourner au React.ReactNode
et des nul et des nul et des nul à l'intérieur de votre component fonctionnel.
Et depuis que React & Flo sont tous en train de travailler ensemble,
un peu plus que ceci fonctionne un peu plus rapidement.
Mais tout autre que les standards de JavaScript et les syntaxes
et les types pour le DOM et tout, est vraiment, vraiment exhaustif en type script.
Donc, il y a beaucoup de percs.
Oui, la dernière chose que je vais dire est toujours le nom de l'Ondres.
Il y a 40 ans de l'expérience de la building de la langue.
Ça pourrait venir avec un bon sens, un sens de domaine.
C'est certain.
Oui, oui, c'est sûr.
En revanche, en passant par cette migration,
j'ai dû faire des grands types de migration,
et ils sont toujours intéressants.
Juste les migrations de code-base, qui sont intéressantes,
et qui ont leurs propres challenges uniques.
Quelle est votre approche à ça et comment avez-vous vérifié
que nous avons fait ce correctement ?
Oui, c'est une bonne question.
Donc, je pense que le plan initial pour la migration
a vraiment pris place, comme il y a presque un an,
à ce point et à ça.
Et c'était vraiment juste une discussion
sur si nous serions allés prendre ça,
ça semble comme si ça ne va jamais être completé.
Comment pensons-nous sur ça
dans une manière dont nous pouvons en faire ?
Et donc, je pense que initialement,
une migration partiale était un peu plus appuyée.
On peut prendre une grande app,
comme le dashboard,
le faire couper les subcomponents,
et faire un peu de petites migrations
et faire un cadence en faisant ça.
Et ça semble être une bonne idée à l'arrivée.
Et je pense que si, si vous venez d'un code-base un peu typique,
sur un type,
je pense que ça va travailler très bien.
Vous ne vous en avez pas perdu de quelque chose
par avoir des files typiques.
Vous avez des types où vous n'avez pas fait,
et tout peut être mieux.
Mais, dès que vous vous regardez
une migration partiale entre les types,
tout commence à devenir plus compliqué.
Donc, surtout,
nos bases de code peuvent être interdépendantes.
Vous n'aurez pas de bonnes boundaries
entre les modules différentes
dans le code base.
Certaines types de utilité peuvent être séparés
partout, des choses comme ça.
Et donc, si vous allez migrer
partie de la base de code,
comment vous approchez de la sécurité typique
dans le code base ?
Vous devez donc
avoir de la chance
de faire de l'aussi bien,
de la sécurité typique,
et de l'essayer de la réchauffer.
Ou de faire un peu d'extrême travail
pour que les types auto-générent
soient en place pour dire
que le code de code de code
peut générer le type,
que le code de code de code
peut générer le flow.
Et ça fait presque double le travail
parce que à ce point,
vous devez construire des outils
pour aller de l'autre côté de la conversion.
Et je pense que l'autre chose
qui a été étendue en pensant
est aussi
au niveau de l'aspect technique.
Si vous êtes un ingénieur
travaillant dans une base de code
partially migrée,
dis-vous que vous essayez
de faire une feature
qui est en type script
dans un partenariat et le flow
dans l'autre partenariat.
Comment va votre code VS
vous déterrir ?
Vous devez avoir
d'autres édits ou integrations
qui vont utiliser
beaucoup de mémoire.
Vous devez avoir de la régenerer
les types de la base
en travaillant.
Il y a juste beaucoup de questions
sur comment vous faites
ce type de bon expérience
et les traitements.
Et ce que nous sommes venus
c'est qu'il y a un
réel loss
dans la vitesse de développement
si nous sommes dans un
étendu en partie inconsistant.
Il y a une chance
de rester
dans un étendu en fin de compte.
Vous avez travaillé
dans des bases de code large.
Comment est-il souvent
que l'immigration
a fait 100 % ?
C'est...
Oui, oui.
C'est probablement
5 % de la time
ou quelque chose.
C'est vraiment difficile
de faire 100 % de choses.
Et...
Et donc
quand nous avons sorti
toutes ces conclusions
nous avons dit
OK, c'est assez clair
que
l'idéal chose
de faire
est une migration de la Big Bang.
Ce n'est pas que
ce soit facile.
Ce juste signifie
que nous pensons
que ça pourrait être
un peu plus facile
et que ce soit une meilleure expérience
pour tous les ingénieurs
à Stripe
qui est
la priorité de la whole chose.
Les gens veulent vraiment
des types de code
mais ils veulent
suffire
d'être en mode
vraiment inconsistant
pour 6 mois
ou quelque chose comme ça.
Et donc,
quand nous savions
que la Big Bang
était plus de focus
nous pouvons commencer
à planter sur ça
et dire
OK,
qu'est-ce que nous pouvons
automiser
ce que
ce qui a été déjà fait?
Peut-on regarder
l'open source
et trouver des blogs
à autre company
qui ont fait migrations
et voir
comment ils se scaleent
jusqu'à la complexité
de notre base de code?
Une autre chose
que nous avons considérée
à la fois
pour essayer de faire les choses
plus facile
était peut-être
augmenter le flow
encore plus
ou prendre plus de temps
sur ça
parce que
le temps est passé
sur le flow
a fait
un peu de features
qui
font un peu plus
de la behavior de type script.
Une des différences

que vous vous verrez
c'est que les objets
sont exactement
par défaut.
Donc,
tu as un component réact
et tu as des propres
pour cela.
C'est-à-dire
quand ce component
est utilisé
tous ces propres
sont typeés
mais les propres
que tu as
sont juste typeés
parce que le object est exact
et tu peux expérer
avec aucun extra field.
En fait,
les gens peuvent dire
qu'ils sont exacts
et ils peuvent ajouter
un petit marqueur
pour le flow
pour dire
que tu as été exact
mais en pratique
les gens ne m'ont pas remis
pour faire ça
ou pour avoir d'autres raisons
pour ne pas le faire.
Et ça
est un exemple
d'un feature
où
c'est assez clair
à l'heure
comme
si tu fais
beaucoup de components réactes
tu aimerais
être strictement
typeé
comme si
quelqu'un
m'a mis les propres
tu aimerais
l'underline
ça
en fait
en disant
oh, c'est un nouveau propre
je vais juste le donner
à tout
et donc
le flow a ajouté
un peu de frais
qui
rachentait
la stricté
comme si
il y avait un mode exact
en default
il y a un autre mode
qui s'appelle
type 1
qui est comme
n'importe où
où il fait
cette
inférence
qui va vous forcer
pour vous annoter
et c'est aussi
une grande performance
aussi
parce que
ça n'a pas
qu'à faire
et donc
on a
regardé
un peu de ces upgrés
et on est comme
peut-être
qu'on peut
mettre nos syntaxes
plus près
de type script
et ça
va le faire
et ce qu'on a trouvé
c'est
qu'il y avait
des bénéfices margénaux
comme c'était bien
de faire des performances
des bombes
quand on a
réveillé
mais en général
le nombre de travail
qu'il y avait
pour aller
comme
sur les types exacts
et tout
va prendre
des mois et des mois
et ce sont les mois
que nous pouvons
plutôt
focuser
sur juste
faire un type script
et
en déterminant
en même temps
donc
il y avait beaucoup de décisions
qui ont passé
mais
c'était assez clair
que nous devions
l'entraîner
et
que nous pouvions
laisser
nos types de flow
comme ils étaient
et juste travailler
avec les gens
donc
qu'est-ce que l'une des solutions

que vous avez
passé
que vous avez trouvé
une libraire d'opensours
qui pourrait faire
beaucoup de travail pour vous
ou
avez-vous
fait quelque chose
donc
Lee
je veux dire
c'était au septembre
de l'année dernière
j'ai commencé à regarder
les différentes
implementations d'opensours
et juste à les essayer
et nous savions
que la première chose
qu'on a besoin
de convertir
dans la compagnie
était juste
le système de design
le système de design
est la subdépendance
de
tout
et
il y avait aussi
besoin de
soutenir
les types de flow
pendant la migration
parce que
il y avait des nouvelles
features
et
ça a fait
tout un peu plus
tricky
mais nous savions
que si on voulait
convertir
tout l'application
ils ont tous
utilisé le système de design
assez
et donc
j'ai commencé à essayer
des autres
les les les les les
et les deux
maines
j'ai regardé
où l'académie de con
qui
arrive
très rapidement
si vous
juste cherchez
pour faire
des types de flow
je suis très sûr
que le nom de package
est
Flow 2 TS
et
ceci
a travaillé très bien
je pense que
j'ai regardé
des types de flow

surtout pour
juste des types de conversion
de type de conversion
de types de utilité
ils ont beaucoup
travaillé
le autre
qui j'ai regardé
était
des tables d'air
ils ont
récemment
ouvert
je pense
que quand nous
nous sommes
regardés
ils ont un poste medium
sur comment ils
migraient
leur code base
très large
je veux dire
c'était
des lines millions
en utilisant
et
j'ai
trouvé
avec leur code mod
la foundation
de ça
était
vraiment clé
donc
en place
de la
corruption



supernatural


on
prophet
et
éviter
l'interruptes

du
tout
?
Trouble, mais il a été clair très vite que c'était nécessaire.
Comme, par exemple, la code de code de code, je ne pense pas que ça
facilite de renommer l'extension de l'extension, parce que c'est
focusé sur la transformation à l'intérieur de l'application, pas de renommer l'application.
Et donc, c'était une chose de la même manière que ça a été fait.
On était comme, oh, oui, comment vous faites ça ?
C'est pas vraiment focusé sur ça, mais il y avait un bunch de
autres petites choses que nous pouvons faire, comme on pourrait
prescanter l'application et se figure à la fin de la déclaration et
comme, on peut le faire ou on pourrait faire un autre, comme, de la scanner.
C'est un file JSEX renommer à dot TSX.
Donc, il y avait des optimisations que vous pouvez faire là-bas.
Et puis, le autre cool chose qu'ils ont fait, c'était que, dans tous
ces cas où le flow est en train de faire un type de paramètre ou quelque chose
où il est nécessaire dans le type script, les ingénieurs d'air table
ont écrit un processus sub qui basically
fait le flow dans l'arrivée.
Et puis, il fait le flow, ce commande qui s'appelle type at position.
Et ça juste donne le position de ce type que vous êtes en train de regarder.
Et ça fait que le flow a fait le type infert pour vous.
Donc, pour vraiment simple, c'est un type vraiment simple comme
ce n'est pas un numéro ou un nom, c'est quelque chose qui peut vous donner
ceci de retour de flow et on peut le mettre en place et on peut le
faire dans nos conversions normales.
Nous avons fait un ton d'enjeux pour l'implementation en temps.
Mais le combination de pouvoir passer les files bien
et de la flow de query était une bonne foundation très obvious pour commencer.
Donc, c'est là où nous avons basé tout ce qu'on commence.
Et on a commencé par tester contre component après component
dans le système de design et en commencent à travailler sur le.
Ou nos ingénieurs ne m'ont pas appris.
Vous pouvez parler un peu de la code Shift J.S.
parce que nous avons mentionné ça.

Oui, je peux parler un peu de la code
de la texture et de ce qui se passe.
So J.S.
Code Shift est un tool vraiment bon que vous pouvez
aller et passer un file de code.
Et ce qui vous donne, c'est ce qu'on appelle un T.S.
Ce qui est juste ce grand grapho de représentation de l'enjeu.
Et vous avez des fonctions que vous pouvez utiliser pour traverser.
Donc, vous voulez trouver toutes les fonctions
de la déclaration, et faire des modifications en particulier.
So qu'il y ait plein d' êtres,
vous pouvez voir les abonnés se prie sur la hele Holyfiles de la utiliser.


maisEnd-shot c'estございます.
Alors, pour d'autres liens,




et si vousgovernissez,

d'unstring pressionner.
Vous devez mettre un comment à la fin de chaque file qui dit à flow.
Vous pouvez aussi mettre un app no flow à la fin de la vidéo,
pour dire pas de checker,
mais c'est ce qui fait que le type système sait que ce file doit être checké.
Et donc, on sort de la vue, on regarde pour ça.
Et puis, on utilise Babel et un autre package
appelé Recast, où on a Babel, on passe le code bloc et on nous donne tous ces nodes.
Et puis, on a un petit peu de transforms qui disent
« Allez à chaque déclaration de variable.
Check si cette déclaration de variable a un type de annotation.
Si ça fait,
mettre le type de fonction qui va essayer de trouver l'équivalent en type script
et convertir.
Et chaque fois qu'on fait un changement,
un grand graph de l'AST de file,
Recast traite ça.
Et donc, à la fin de faire tous les changements,
on dit Recast,
aller à la fin de la file avec tous les changements.
Et ça fait ça.
Donc, c'est la structure de la base de la version de Outworks.
Et je pense que dans ceci,
on a 8 ou 9 types de transforms différents.
Donc, il y a un file qui regarde toutes les classes
et qui transforment pour eux et leurs méthodes
ou qui regardent tous les importations et les transforms pour eux.
Et c'est ça qui fait tout ça.
Oui, c'est vraiment cool.
Quand j'ai commencé à enlever les codes mod,
c'est juste que
c'est juste un code automatique
pour modifier
le programme, pour modifier votre code.
Quand j'ai commencé à enlever,
je pensais que c'était vraiment...
Je ne sais pas.
C'était assez scère.
C'est comme ça, ça a été très compliqué
de l'extérieur.
Mais il y a un outil là-bas
qui s'appelle AST Explorer,
qui est probablement
l'un des meilleurs,
si pas les meilleurs,
tools pour apprendre comment les codes mod work.
Parce que c'est comme un playground
avec ces panneaux.
Et c'est comme,
votre code source,
et puis votre code mod,
et puis ce que ça génère
dans l'AST,
et ça vous donne
une bonne expérience
de
presque toutes les codes,
si vous êtes en train de
enlever les codes,
les JavaScript,
les flow, ou tout ça.
Donc si vous êtes intéressés
à apprendre comment enlever les codes mod,
ou juste voulez jouer avec ça,
ASTExplorer.net
c'est votre ami.
Oui, c'est ça.
On utilise ça beaucoup
sur le set BabelParser.
Oui, pour nos listeners
qui peuvent entendre AST
et sembler en peur,
c'est un topic de la fête

à l'époque.
Mais quand vous comprenez
ça,
ça le déclare beaucoup.
Comme recently,
j'ai utilisé ASTExplorer
pour regarder le code AST
pour mon code réact
et puis utiliser
pour savoir
qu'il y avait une relation
entre deux components.
Donc on a un bouton icon
dans notre système de design.
Et pour un bouton icon,
il n'y a pas de texte.
Vous voulez qu'il y ait un
label Aria ou un tip de tool.
Avec AST,
je peux juste voir
les boutons icon
et ensuite vérifier
si ça a un certain propos.
Non, on va aller sur le traitement.
C'est-il un tip de tool?
Non, c'est un erreur.
C'est très utile.
Et ça ouvre
beaucoup de
l'obligation d'accroître
vos outils.
Oui, et c'est comme
les plugins ESLint
et
beaucoup d'autres
même comme
ce qu'on appelle
c'est le système de construction de CSS.
Comme certains de ces plugins.
Poste CSS.
Poste CSS.
Ceux-ci aussi
ont un AST
pour CSS.
Et donc, oui,
vous pouvez
vous pouvez faire
beaucoup de
très bons programmes.
Et l'autre chose qui est vraiment bon
pour les codes
est que c'est un des places
où vous pouvez presque
toujours faire
développement test.
Ce n'est pas toujours le cas,
surtout
quand vous travaillez
avec l'interface user
code ou code JavaScript.
Mais c'est bon
où vous pouvez dire
OK, je vais faire ce petit programme.
C'est ce que j'espère
pour le transformer.
Réparer le transformateur
ne peut pas se faire.
Et vous pouvez les faire
toutes les cases test
bien.
Et c'était un truc
que nous avons focussé
beaucoup dans nos codes.
Je pense qu'il n'y a pas
beaucoup de
coverage test
disponible
pour le type script
conversion
juste par les projets.
Et donc, avec nous,
chaque changement
que nous avons fait
a un cas test
pour ça.
Et nous devons
définir
des choses qui ont été
détruites en temps
si nous n'avons pas
tout le suite.
C'est drôle de
retourner
au test de développement
quand vous ne le faites
pas prédominantement.
Un autre package
que moi et Tyler
travaillent sur
pendant que nous travaillions
pour le code
de CSS
et tout le temps
je voulais ajouter
quelque chose de ce package.
Je vais juste aller
au test de développement
et j'ai juste envie de travailler
et de l'accéder
au code
jusqu'à la passée de test.
C'est un bon sens.
Oui.
Je pense que c'est
le plus pur de ce programme.
Tu sais, c'est comme
tu as des outils et des outils
et c'est comme ça.
Tu sais, c'est comme ça.
Je me sens comme si j'avais
toujours promis
dans la school
que c'était
comment je pouvais
faire mon développement
et que c'est la meilleure chose
et puis
en pratique,
un peu de choses
ne peuvent pas
être testées
facilement.
Surtout quand tu parles
des applications
ou des choses comme ça.
Oui.
Donc, en revanche,
le code mod,
est-ce parfait?
Comme,
il y a des situations
où il y avait de la bale
et tu as dit
que c'est trop compliqué de code.
Je vais juste commencer
à mettre des ouverteurs
ou de faire des commentaires.
Et là,
une structure de code
que je ressens
peut être très difficile
de faire
parce que
j'ai connu
avec eux beaucoup
des generaux
comme convertir
un type de système
de generaux
à un autre type de système
de generaux
semble être un
problème non-trivile
même plus non-trivile
que convertir
3,5 millions de codes.
Oui.
Oui, donc le code
est,
surprenant,
pas parfait.
Et
on a fait
beaucoup d'improvements
en temps en temps,
mais
je pense que c'est très difficile
de faire
pour les raisons
que tu as juste dit.
Il y a des places
où,
surtout comme
des types de utilité,
donc,
type script
a beaucoup de types de utilité
comme omit,
pick,
ou quoi-même.
Et tu peux changer
ensemble
pour faire
des requirements
assez compliqués.
Le flow
a des mêmes sortes
de choses disponibles,
mais les types de utilité
peuvent aussi
faire
plus de l'influence
avec eux
ce qui les fait
plus difficile
de la map.
Donc,
il y a un
appel
object map
où je suis sûr
que ça fonctionne
comme tu passes
un objet
et cet objet
a des clés
et les valeurs sont
fonctionnes.
Et ça
va vous donner
une type de
qui a la clé
et ensuite
le type
de ce que
la fonction
va retourner
quand tu passes
le type
de la valeur.
Et donc c'est comme
inferrer
le type
de la fonction
et retourner
les types de utilité.
Et
il n'y a pas de
qu'il y a de la
force
pour convertir
un peu
de ce que

et donc
des choses
qui restent
ou comme
nous convertir
les les meilleurs
que nous pouvons
mais
ils ne vont pas
aller
sur le plan
les choses
que nous pouvons
faire
sont
identifiées
comme
des patterns
vraiment communes
dans le code,
surtout
autour
d'un code réacte
donc
quelque chose
autour
de la compagnie
des propres
pour les compagnie
ou
des choses pour
les types
type les API
ou les
des graphes
QL
ou des choses
comme ça
donc
focusing
sur
ça
c'est
comme
nous approchons
d'interpréter
sur le code
de la
mode
c'est
que nous
avons commencé
avec ce système de design
donc
nous avons commencé
avec des compétences
et nous avons
travaillé
sur les compétences
plus compliquées
probablement
faire
une ou deux
patchs
par component
à l'époque
pour soutenir
des syntaxes différentes
et puis
nous avons
déménagé
sur une app
que
c'était
probablement
un couple
de milles
de codes
donc
pas super
compliqués
mais
on a
des choses
dans ce
digital
c'est


représente
de











β
ou
comme, ok, ce n'est pas manuellement fixable anymore.
Si nous sommes en train de scale-up à des bases de code plus grandes,
on ne va pas pouvoir en prendre un peu de temps
à regarder tous les types.
Mais nous pouvons nous concentrer sur les choses
les plus priorités que nous l'avons vu,
et un couple de choses nous avons aidées
au long de la façon dont nous avons trouvé ça.
Le codemod a un argument de command line
qui va prendre tous les erreurs de type script,
les sortir par code d'error, les sortir par file,
et ensuite les mettre dans une spreadsheet pour vous.
Vous pouvez donc très facilement l'exprimer
et se dire,
« On a un grand bloc de... »
« Ceci est indifféable ou un grand bloc de
erreurs de parlement à la classe. »
« Qu'est-ce qui se passe ici? »
Et donc, en utilisant ça, vous pouvez commencer à narrower
sur les zones que le codemod n'est pas converti très bien.
Et puis, on est en train de triage les erreurs.
Pour vous donner une idée sur la base de code grand,
quand nous avons été à la base de Stripe,
nous avons été en train de faire un codemod de 100 000
typescript-error.
Et donc, nous avons eu un codemod de spreadsheet
pour commencer à prendre des erreurs
et à mettre dans une spreadsheet.
Mais en temps, nous avons pu vraiment
se mettre en train de faire ça.
Et je pense que, à la fin de la vidéo,
nous avons terminé avec 38 000.
Et maintenant, nous sommes à 30 000,
qui est encore beaucoup, mais signifiquement réduit.
Et beaucoup de erreurs, vous ne pouvez pas
même juste, faciliter la modification de la mode ou quelque chose.
Donc, par exemple, il y a un gros bloc d'air
qui peut être possible de faire un bon tour.
Et peut-être que ce soit quelque chose de plus ou plus
que l'on a prévu et que le typecript est un peu plus strict.
Et le changement de code est en train de se faire
de savoir si c'est vraiment un bon tour
et de fixer les types ou de mettre un garde ou quelque chose comme ça.
Mais nous voulons préserver ces erreurs.
Mais l'une chose que nous avons aussi trouvé
que c'était utile pour se faire
de se faire de savoir si nous nous avons maintenu la sécurité type
était juste de se faire de la base de code
et de générer de la base de type pour la base de code
et de voir comment nous faisions.
Donc, Flow a un tool de type de coverage qui a été construit
et donc nous pouvons que ce soit le cas et voir
à quel point nous sommes à...
Je veux dire que c'était un type de coverage de 92%
avant, et c'est juste d'assertir
qu'il n'y ait pas d'autres types
comme de casquette, au base de code
et tout a quelque chose de plus strict que ça.
Avec TypeScript, il y a un package de NPM
je pense que c'est juste de la coverage type
qui vous donnera la même sorte de rapport
au niveau de la script type
et donc nous pouvons monitor ça en temps en temps
et dire que nous ne sommes pas en train de déterminer
notre coverage type à tout ou est-ce que c'est roughly équivalent?
Ce n'était pas une priorité de le faire
d'être exactement la même.
Nous avons trouvé que nous avons perdu un peu de coverage
juste pour être migrés.
Mais ce que nous avons trouvé après
faire un peu d'adaptations sur ça
c'était que la coverage type était un peu plus rapide
ce qui était assez surprise
parce qu'on avait plus de soupréhens,
plus d'arrêts et des coverages de la reds
mais nous avons eu beaucoup de nouvelles definitions
de type disponibles pour nous
pour toutes ces 3rd partie de la dépendance
que nous n'avons pas très strictement
typeé parce que nous devions avoir
les hands de la preuve avant.
Et donc, avoir tout cela disponible
a fait la coverage type
un peu d'augmentation en temps
ce qui est génial.
Donc si vous avez 30 000 erreurs
ça veut dire que vous n'avez pas
fait de type checker pendant le build
comme que vous êtes juste admettre les files?
Non.
Donc nous sommes type checker
pendant le build
et basically,
quand nous avons commencé à voir
le nombre d'erreurs qui étaient là
nous étions en train de dire
« oh, nous devons avoir un système
pour automatiquement
triager et supprimer ces files si nous pouvons »
et donc nous avons ajouté
un autre commande à notre code mod
qui est juste focussed
sur les types de fixation
après que vous avez converti
et comme je sais
c'est comme un nouveau truc
je n'ai pas vraiment vu
que l'on a fait
de la mode de fixation
mais l'un des features que nous pouvons faire
c'est juste aller à l'aise
et ajouter un comment de suppression
sur chaque erreur
et faire un error de TSXPECT
pour que, comme les gens fixent
les erreurs de type ou improvement
en temps, ça donnera un erreur
pour remettre le comment
et nous avons aussi un command
pour remettre les erreurs de TSXPECT
qui est en fait
quelque chose que je suis surpris
qu'ils ne sont pas en type script
juste comme un feature nativement
mais c'est certain que après la conversion
où nous avons tous ces suppressions
nous voulons pouvoir retourner
avoir des gens fixer un peu de 100 de eux
et puis juste les avoir automatiquement délisées
donc nous avons mis ensemble des outils
pour nous aider avec tout ça
donc nous avons évoqué des suppressions
et nous pouvons en faire un type script check
qui passe et se débrouille
un autre
quelque chose d'intéressant
type script aussi a des suggestions
ils ont été mieux en prenant
Hey, vous utilisez un valeur comme type
vous vous disais que vous en avez un type
avant ça
et donc pour certains de ces erreurs
c'est comme le correct 98% de temps
ou quelque chose comme ça
donc nous pouvons aussi
prendre ces erreurs et puis tenter
de juste appliquer le fixe
automatiquement après
avec type scripts
ajoutés contexte
sur tout le code
qui est vraiment bien
c'est génial
la suppression
de l'approche que vous parlez maintenant
est vraiment commun pour
de l'entraînement
non-strict type script
un type script trop strict
un type script
donc quand je suis à Artsy
on a fait une grande migration
qui a commencé
sur l'app mobile
Igon
et c'était
comme la même sorte
c'est comme
tourner sur le flag
et puis automatiquement
ajouter des erreurs TSEXPECT
à chaque fois que les erreurs s'occupe
avec un message
et puis avoir un script
pour faire sure que
pas plus de ces
les introduire
et essayer de
les établir en temps
c'est un bon approach
c'est bien et c'est bien
pourquoi ils ont les comments TSEXPECT
parce que si vous vous avez
fait un ignore
ce serait un grand
extra risque pour la sécurité type
quand les types sont réveillés
ceux ne sont pas réveillés
donc vous vous sentez un peu
plus sûr que le temps
que l'erreur est fixée
ces commentaires seront aussi
remis et vont plus vite
oui c'est mon opinion
que vous ne seriez jamais
utilisés pour l'ignore
comme ça
ça ne devrait jamais être utilisé
depuis que la base de code est tellement grande
vous vous faites
construire tout
tout les requises pour les contrôles
ça semble que
ça peut prendre un temps long
c'est une bonne question
donc
quand nous ont commencé
à faire les
réunions initiales
et nous avons eu tous ces erreurs
nous avons rapidement
réveillé des problèmes
de performance avec type script
c'est un grand nombre
de files
et
juste
le nombre de erreurs
aussi
augmente
je pense que le usage
de type script
je pense que ça a été
mieux
comme nous avons réduit
mais vous savez
avoir à aller
augmenter votre mémoire un peu
sur votre laptop
pour que ce n'est pas
renseigné
parce que je pense que c'est seulement 4 GB
par default
c'est assez curieux
à commencer
mais
nous avons fait un peu de choses
qui ont vraiment aidé
à mettre ça en place
dans le cadre de la raison
où les gens peuvent le faire
régulièrement
et cela fonctionne bien
dans leur éditor
le
main qui nous a fait
était
de regarder les références de projet
qui
pour les gens qui n'ont pas utilisé
c'est
comment le type script
tient à scale les bases de code large
vous pouvez basically
pointez
à des zones différentes
des bases de code
qui sont isolées
et vous pouvez dire
ce que c'est un projet
sur sa propre
typez-le sur sa propre
cache les types
pour le type
et ne récomputez
sans les files
dans le changement
c'est juste un bon
moyen de
cacher les types
sur le base de code
et de garder la mémoire
de la usage
plus basé
Unfortunately
vous pouvez seulement
utiliser les références de projet
quand vous ne vous
vous interviendrez pas
dans les directrices
et donc
dans une application large
de web
c'est vraiment common
pour les impôts
partout
vous avez écrit
un component réacteur
dans une direction
utilisez-le dans une autre
et donc on en a
et donc c'est vraiment
difficile de mettre
ces boundaries
et
on a assez rapidement
réalisé que
ce n'était pas possible
de
mettre les boundaries
pour
tout le
source main
source code
dans le dashboard
mais ce que nous pouvons
faire
cacher
les types les plus
les plus soudains
que nous pouvons
cacher
des files test
qui ont
une
dépendance de la

et donc
la première chose
qu'on a regardé
c'était de
utiliser le profilé

pour
savoir
quelle file
les plus longues
pour les types check
et
sur le point
qui a été
créé
c'est un grand file
de types
pour graph ql
et notre API
qui est probablement
assez commun
dans un peu de applications
et donc
si vous avez
tout le file
dans un
file
sur le point
qui sont
allés dans la mémoire
même si ils ne sont pas changés
et
cela peut vraiment
se faire
cacher
donc nous avons
créé un référence
c'est pas
très plein
mais comme
tous les types
générés
et tout le monde
peut rester
comme un référence
comme je dis
nous avons
expliqué les tests
dans un référence
séparé
ces types
sont récomputés
un peu plus souvent
depuis que les gens
édite leurs files test
mais
parce qu'à la fois
ils ont la relation
de la façon dont
les tests
importent
mais que
votre source
n'est pas importée
vous pouvez
bloquer ça
et cacher ça
aussi
et donc
avec le mode
incrementale
qui est créé
dans le type script
nous pouvons
prendre les zones
qui étaient soudes
générer un file
de la base
pour les types

faire un type script
plus performant
et plus rapidement
pour le startup
quand vous avez le généré
c'est assez cool
je l'ai regardé
les références du projet
et elles
sont un peu
compliquées
vous devez
vérifier
un peu
votre
file dts
comme
je ne sais pas
c'est juste des art-effects
qui doivent être
présents
pour les
faire
et pour nous
nous ne sommes pas
en train
de vérifier
les files dts
qui sont
qui sont
localement
des laptops
pour le temps
ça
fait
ça
c'est un peu plus
comme
un peu
plus


grande opportunité
pour nous
nous
nous devons
utiliser
ces files
plus profondément
dans notre système
car
localement
vous pouvez
faire un type script
ça peut prendre
quelques minutes
pour
générer
les files dts
des infos
la première fois
que c'est fait
mais quand vous avez fait ça
et que ces files existent
le type script est plus
plus rapidement
en taking seconds
pour
vérifier les files
que vous avez changé
et donc
on peut
jeter un peu
ceci
dans le système de CI
ce n'est pas
mal à la fois
mais en temps
on peut faire
une meilleure expérience
ce qui est sympa
donc
comment a-t-il
la rollout de tout ce go ?
n'est-ce pas
des rôdes
de la façon dont les gens
réagissent
avec des forcs et des feuilles
ou sont-ils
les changements
avec tout le type script ?
c'est
bâti
c'est beaucoup plus
d'autres gens
qui sont en train de
les changer
un mois
avant
nous avons fait
la migration
nous avons
sorti
et
réduisant
les types errors
et nous avons été
assez confiants
que nous étions
plus profondes
à avoir un build pass
donc nous avons commencé
de communiquer
aux équipes et de
dire que votre base de code
est en train de
mettre le type script
en bout de mois
on vous dirait
et je pense que
les gens
sont en train de

et de dire
qu'est-ce que ça va
arriver ?
et que
vous êtes en train
de le faire
et c'est comme
non
on est en train
de le faire
et c'est
vraiment cool
d'avoir
l'enthousiasme
de faire

comme nous sommes plus
plus profondes
les gens
sont en train
de tester
l'application
comme nous
avons été
préparés
à vérifier
nos types
de branch
voir comment les choses
vont
en fait
en faisant
une migration
nous avons
dû
faire
un bunch de travail
pour
faire
un peu plus
risqué
quand nous avons
changé les extensions
nous avons
trouvé
que
nous changeons
des lignes de code
dans ce code
de base
que la chose risquée
serait de modifier
tout ce code
mais
parce que nous changeons
les types
les types
si le code
de la mode
fonctionne
nous ne changeons pas
l'expérience
de la rotation
de l'exécution
de l'exécution
de chaque file
donc
votre point d'entrée
de webpack
et de tous les autres
tools
ont besoin
d'être
à l'aise
pour l'expérience
et de résolver
et c'était utile
d'avoir des enjeux
en jouant
et testant
leur partie de la production
et nous laisser
savoir si c'est quelque chose
qui a changé les extensions
et
après que nous
avons converti
les gens
sont revenus
et nous étions
un peu nerveux
initialement
nous savons que
les premiers jours
vont être un peu
bombes
où
vous devez
restarter
des codes de vsc
pour que les codes de vsc
soient en train d'élever
et donc
il y avait
une étude d'éducation
pour qu'il se dévile
si vous le déviez
vous devez réélever
c'est là où
les features
sont élevées
et
pour que tout le monde
soit en train de faire
des études
si les gens
avaient
des branches
ou des requises
qui étaient
en train de faire
des codes
et de rébaser
des choses comme ça
et donc
il y a un peu
de concern
comme
il y a un moment
du week-end
après la
sondage
où
l'accès était
assez
bien plus
positive
les gens
étaient vraiment
supportants
ils étaient
vraiment enthousiasmés
pour faire des typescript
et ils étaient
très patients
avec nous
comme nous
on a
des choses
qui nous

très stables
et
des choses
qui travaillent
il y a des gens
qui
ont été
en sondage
et ont dit
oh, c'est le meilleur jour
j'ai été très heureux
sur typescript
j'ai remarqué
mon folder
qui travaille
il y a un peu
de typesuppressions
donc je vais
faire des fixations
tous les jours
et je suis vraiment
très excité
et c'est génial
de voir
cette attitude
de faire des
typescript
et avoir
beaucoup de gens
qui ont aidé
à fixer tout à l'heure
parce qu'il y a
seulement 9 gens
sur notre équipe
et il y a
seulement 4 de nous
qui sont
complètement dédiés
à typescript
après
donc
ce n'est pas
assez de gens
pour fixer tout
dans une base
de code 3.5 millions
c'est vraiment
génial
c'est un truc
très gratif
de travailler sur les outils
c'est comme
tu construis des choses
pour les gens
que tu as
d'autre
c'est un customer

qui est
très satisfait
c'est génial
si quelque chose
se passe
on peut
floriser
dans un
épisode
ceshappy
et
au
latin

sur
on va
wording
c'est
un
mais vous ne vous appelez pas, c'est toujours une valeur de la vérité.
C'est vraiment facile de me faire perdre ça, juste en développant.
Je pense que il y a eu quelques gens qui ont trouvé ceux ici et là.
C'est génial que ça puisse identifier pour nous.
C'est un bon point.
Sur le sujet de tout ce travail, la prochaine question obvienne de Marian,
est-ce que vous vous pliez à faire des outils d'open sourcing?
Oui, donc la bonne nouvelle est que tout ce que nous avons travaillé sur,
et que les outils d'open sourcing soient en place,
probablement avant cette podcast,
ce qui serait génial, les gens peuvent le voir.
Nous sommes dans le processus de mettre ensemble un blog post
qui outline la histoire générale du projet.
Il y a beaucoup de détails sur comment nous avons réglé la migration
au cours de la semaine, en mars.
Tout ce qui sera disponible dans le code mod est là-bas.
Nous avons également travaillé sur des autres sites internaux,
nous avons aussi converti des éléments de strip payment
et des STK, des choses comme ça,
sur le type script.
Nous avons aussi été en train de faire des fixations
dans l'optimisation d'open sourcing,
donc il sera disponible en jour 1.
Nous avons également écrit un peu d'accommodation sur ça.
Il devrait être, si vous voulez,

essayer de faire un code flow,
il ne devrait que prendre 10 ou 10 minutes
pour s'y mettre et faire un peu de détail,
construire, et commencer à faire le projet.
Qu'est-ce qui est le prochain,
ce qui est le plus grand pour votre équipe pour conquerer,
maintenant que vous avez le meilleur de la base type script?
C'est une bonne question.
Je voudrais dire que nous avons complètement le meilleur,
nous ne sommes pas très là, mais nous sommes là.
Je pense que probablement
la prochaine grande opportunité,
que certains de mes teammates ont déjà fait un grand progress,
c'est de partager le code
dans notre grand monorepo.
Nous avons tout ce code JavaScript,
et comme vous vous en avez probablement plus d'envers,
si vous êtes dans une base de code,
c'est très facile
d'avoir des différents directrices
où vous ne pouvez pas facilement partager le code,
donc vous vous en avez des copies,
ou vous avez des parts de la base de code
où c'est trop facile de partager les choses,
et vous vous endvez avec la code interdependente
que vous ne pouvez pas vous couper.
Nous avons travaillé sur un peu de tooling
pour faire ce processus facile,
pour comment toquer les choses,
et pour ne pas avoir à faire un public en NPM
et un bump vers un vers
chaque fois que vous changez de la compétition.
Je pense que la mobilisation de type script
a aussi fait un moment
de nous rendre compte que c'est vraiment
c'est utile de mettre plus d'investissement
et de garder tous nos outils la même version,
et de prendre un régulier rythme
pour garder tout ça à la date.
Avec Flow, tous nos bases de code
étaient en relative de récentes versions de Flow,
mais elles n'étaient pas nécessairement les mêmes.
Et pour le type système,
c'est vraiment utile d'avoir
chaque projet de votre code base
sur la même version.
Si un type script fait une nouvelle check,
vous devez commencer à tourner le check de l'élo,
parce que certains autres packages
dans votre chaine de dépendance ne peuvent pas
passer la nouvelle version de strict,
des choses comme ça.
Nous essayons de garder tous les outils dans le sync,
et je pense qu'il y a beaucoup d'opportunités
pour faire ça pour d'autres outils.
Si vous êtes un ingénieur
en travaillant sur une application
dans ce grand repo,
vous essayez de mettre ensemble le meilleur code
de product que vous pouvez,
et vous n'aurez pas de temps
à garder votre version de Babbel
à la date avec tout le monde,
ou à la date avec tout le monde
de type script,
donc le plus que nous pouvons
mériter et faire plus de burden
pour les équipes, je pense que ça va être vraiment
utile.
Et puis la dernière question
que nous avons,
avez-vous des outils de nouveau développeur
que vous avez vu sur Twitter,
que vous êtes excitées à venir ou excitées
à utiliser ?
Il y a beaucoup de nouveaux outils de cool,
il y a beaucoup de très bonnes outils,
je pense que tout ce qui a été
en train de mettre en place
une émphysie sur la performance
et le support type,
les outils de base,
les outils de base,
les outils de base,
ce sont des outils qui sont
vraiment concentrés
sur la construction de la construction
de la production,
et la fonction de la production type,
c'est vraiment incroyable de voir ça,
parce que je pense que nous sommes
dans un bon endroit
avec les syntaxes d'un JavaScript,
mais l'amélioration de tous ces outils
et les faire très vite
est un bénéfice très immédiat.
Je pense que tout ce qui est
sur les ingrédients d'édit
ou d'autres
outils de l'in-code
ou des cheques,
je suis vraiment excitées.
C'est toujours vraiment beau
de les avoir
les hints en tant que type,
et d'avoir de la c.i.
typeScript, ça fait
beaucoup de erreurs et hints
dans votre éditor,
donc je pense que c'est un des
les raisons de la personne qui aime ça.
Oui, pour sûr. Je adore
tout le tooling natif qui vient de la production.
Je pense que le futur
de la tooling JavaScript est tout natif,
parce que
c'est où vous vous inquiétez
de votre performance. Il y a un temps
où nous nous optimise
pour dire que nous voulons tout
faire en langage.
Nous voulons tout juste faire notre code
en typeScript, comme nos outils,
nos outils de la CLI,
nos web apps, nos back-end.
Nous voulons tous être les mêmes choses,
mais il y a un bon tool pour le bon place.
Et si vous vous processez
des milliers de files,
c'est comme
que le tool natif
fait un grand différence.
C'est super stocke de Rome,
de Blend, de ES Build,
et tout ça.
Oui, et je ne pense pas
que j'ai eu assez de temps
en essayant de faire des trucs,
mais c'est incroyable
de voir
chaque nouveau tool,
comment je peux faire
ce type de performance
pour les gens.
C'est un grand improvement,
parce que je pense que la performance,
on a fait beaucoup plus de features en langage
et un peu moins de performances
de la tooling de la front-end.
Et de la simple,
aussi. Je pense que
pour un long temps, la front-end développement
a besoin d'une compétition d'un grand nombre
de différents tools.
Et ça a été un peu bruyant, mais c'est aussi
sympa de voir les gens
prendre des nouveaux attempts
pour essayer de simplifier un peu.
Avec ça, on va changer les tips de la tool.
Donc, la première chose
que je vais partager aujourd'hui
est une libraire de React called Virtuoso.
Si vous avez eu un liste
très très très large,
avec beaucoup de choses en React,
vous pouvez vous rappeler que
les performances de la page sont des tanks.
C'est parce que React rendra
chaque row, et même si c'est pas sur la table,
c'est en membre, toujours rendu.
Donc, une technique commune
pour se résoudre,
c'est la virtualisation,
où vous vous rendez
seulement les rows
qui sont visibles sur la table.
Et puis, un peu de la lait
en même manière, c'est l'overscan,
pour essayer de ne pas
sembler que les choses se popent en vous scrollant.
Les deux grandes libraries
pour faire ça dans le passé
des décennies, je pense, ont été
les premières version de React,
et les Windows de React.
Les deux libraries sont written par Brian K. Vaughan,
un membre de la team de React.
Ils viennent avec des limitations similaires.
La plus grande limitation
dans mon avis, c'est que
vous avez à dire,
ici est une box, ici est la main.
Les choses en ici sont virtualisées.
Vous devez donner une haute haute
à ce point, ce qui est un
un détail, et ça s'exprime
parce que, à la fois,
vous avez un browser responsable,
vous ne savez pas ce que l'on va faire,
donc vous devez mettre des mutations
ou des observateurs intersectionaux,
ceci a des choses cool
qui font ça très facile.
Le point que je veux appeler en particulier
est, je ne sais pas si je vais pouvoir
trouver un exemple ici,
mais ils ont un propos
qui s'appelle
Use Window Scrolling.
C'est pour ça que vous avez
des contenus virtualisés,
mais pas un extra box
où il y a une barre de scroll
où vous devez scroller.
Ce que j'ai utilisé est un browser
d'enregistrement de project.
Nous avons cet area où il y a
ce genre de contenus statiques
qui est visuellement plaisant.
Et là-bas, c'est le browser de project.
Si je suis en train de utiliser la window de React,
je dois scroller,
et là, il y a un box
où je peux scroller et les choses sont virtualisées.
Avec React Virtual Woso,
je peux utiliser le scroll d'un autre élément
et ça fonctionne.
Ça fait que je mets un padding
pour tous les cellules qui ne sont pas sur la window,
en avant à utiliser la position absolute
comme React Window.
Donc maintenant, quand vous scroller sur la page,
ça se sent comme une page long,
même si une partie de la page
est virtualisée.
Donc si vous avez voulu
mettre virtualisation sur votre app
et que vous avez été limité par le window de React,
c'est une bonne option.
Ça a un API assez facile
et j'ai eu un bon temps avec ça.
Est-ce un nouveau package ou est-ce que c'est passé pour un moment ?
Je pense que c'est un peu nouveau.
Probablement dans le passé
ou l'année passée.
C'est un des autres choses
que ça fait vraiment bien que
React Window ne fait pas vraiment tout.
C'est que vous pouvez
rendre des tables avec ça.
Avec les tables,
vous devez avoir une structure
très stricte de la table
et un T-head et un T-body.
Vous ne pouvez pas avoir des divs
ou quelque chose entre les deux.
Donc pour faire ça avec React Window,
c'est assez difficile car c'est
ajoutant des choses pour faire
les choses possible.
Vous pouvez les override, mais
beaucoup de temps, c'est un peu clonqué.
C'est un component de table
qui s'occupe de la marque
qui est en fin de la journée
une des choses les plus importantes.
Super important.
Je vois ça,
ça a été reposé
sur Twitter.
Je pense que...
Devin, le spectrum adobe,
n'est-ce pas ?
Je ne l'ai pas appris à dire.
Oui.
Devin a posé ça
et c'est un article
qui s'appelle Building Data-Cyntric Apps
avec un database réactif
relative.
C'est un article très dense,
mais l'un des choses
qui est très importante
est de vous donner
votre database plus près de votre application.
Il y a un projet qui embosse
ce que j'adone.
Il y a un projet
qui s'appelle Actual, c'est un app
d'abus.
Un des membres de la team Stripe Design System.
Exactement.
James Longster.
Longster.
C'est quelque chose de...
Me and Names, pas de Longster.
Mais, le principal est
que, un peu de fois, nous construisons
des applications, on a un API
et on a des laitres complexes
entre les
expériences productuelles que nous avons
et les données que nous connectons.
C'est une série complexe
de choses que nous faisons pour construire ces choses.
Ce article
parle d'une stratégie pour
prendre cela plus près, où peut-être vous vous
vous rendez votre database
à votre level UI.
Actual fait ça
par enregistrer un SQLite
sur l'index db,
et ça synchronise
les versions SQLite
en faisant tel-locking.
En tout cas, ce article parle
de cette séance et de l'architecture
et de la pensée
de
ce qu'il y a et de les bénéfices
et de les propres systèmes.
Je me trouve beaucoup
d'entre vous,
en pensant
à ce que la complexe
de simple des produits digitales
soit bien.
Et de la patience
de la production.
Je suis un grand profond
de GraphQL
et il a
beaucoup de propres
mais les appels de la construction
sont vraiment compliqués.
Comment vous n'avez pas de la génération type,
comment vous faites la génération automatique
et la séance de la processus
pour GraphQL.
Même un API restant, tout ça
est vraiment expensif.
Je commence à valoir
plus de simple.
Vous pouvez faire
un SQLite et prendre le data et le rendre sur la table.
Bon, c'est bon.
Un grand article, je vous recommande de le vérifier.
Il y a beaucoup de détails.
C'est un expérience de fond.
Le fait de la génération
de la construction
de la production
a été utilisé pour la production.
C'est un brise à utiliser.
Vous ne pensez pas à ces choses.
Oui, et dans cet épisode,
nous avons parlé de Blitz.js
et de la façon dont c'est un API invisible
où vous importez les modules de service
et que ça génère un interface de RPC.
C'est vraiment intéressant.
Ce n'est pas
pas de la faible de la production.
C'est des extractions et vous payez pour elles
de manière d'une certaine façon.
Je ne sais pas. Je suis tout à fait
de réduire la cognitive overhead.
Je veux voir plus de ça.
Si vous êtes intéressés, vous pouvez lire
ce très très dense article.
C'est assez extensible. C'est vraiment bon.
Je vous recommande.
C'est très relevant.
C'est un package
appelé ESLint bankruptcy
qui est un bon nom, une meilleure fonctionnalité.
Il fait
ce que nous avons
décrit avec les suppressions de type script
qui est
que vous voulez ajouter une nouvelle
rule de ESLint, ou que vous avez
migré de 3 millions de
lines de type script
et que vous avez décevé des règles
pour faire ça.
Vous êtes en train de
retourner sur les règles et
il y a des erreurs de ESLint.
Vous pouvez
faire un peu de fixation
mais
si vous êtes dans les 100, vous ne voulez pas
être envers les suppressions
ou les fixer.
Ce tool vous permet
de vous faire un CLI sur votre base de code
et de vous dire que vous avez trouvé
tout l'instance de ce failure de ESLint
et de vous supprimer.
Nous allons le faire
et tous les nouveaux en futur
devront devenir erreurs et nous allons le faire
mais pour maintenant, nous sommes bien avec les
règles que nous avons, nous voulons
juste des syntaxes plus strictes.
C'est un exemple
pour moi d'un tout simple
tool qui
fait ce que ça dit sur le TIN
et est très straight forward
mais très fonctionnel aussi.
Je pense que ça va apparaître très bien
avec quelque chose d'aussi mieux.
Le tool
que nous avons parlé, je pense que c'était
un tool de la fin de la fin de la fin
mais c'est un tool de plus en plus
par un ingénieur spotify
et il
vous permet
de vous couper en certain temps
des règles de TIS
ou
des règles de ESLint.
Il traite tous ces règles
sur votre base de code et vous avez un test
qui ne vous permet pas
de passer seulement en plus
et vous pouvez mettre des goals
et d'autres règles de migration.
Je pense que
plus de ces règles
dans l'écosystème sera génial
parce que c'est comme ça que les migrations
sont faites. C'est comme que vous avez besoin
d'un tool pour aider les gens
à faire ça sans bloquer leur journée.
Je suis un grand fan
de cet projet et ça va bien.
C'est pas le premier temps que nous avons parlé
de ça.
Ok
Donc
mon prochain
ce n'est pas utilisé tout
mais je vois comment c'est très utile
c'est
une plugin pour Radix
donc vous pouvez demander
pourquoi je veux ça
pourquoi vous avez besoin de ça c'est parce que
comment Radix fonctionne un peu de temps
c'est qu'il va mettre des States
sur les choses comme des règles de data
donc pour exemple
vous avez un groupe de toggle
où il y a trois boutons et seulement un de eux peut être sur
quand un de eux est sur
il va mettre
des States equals sur
et tous ces outils
vous aide à capturer
ces choses
si vous regardez le code snippet
ici
il y a des choses comme
Radix State Open Border 2
quand ce data attribue est présent
il va mettre un bord
donc ça peut vraiment
vous aider à ne pas écrire
ce CSS et juste plug direct
dans la tailwind
ce qui est probablement ce que vous voulez faire
si vous avez besoin de quelque chose comme ça
pour conclure le code
pour Radix et Radix
ce serait une bonne option
je suis pas très familier avec Radix
ce que c'est
Radix est
mon préféré library
que j'ai passé
dans l'année passée
vous savez où est le UI
mais pour l'audience qui ne pas
Radix et Radix ont tous les mêmes goals
et ce goal est
créer des components réactifs
qui sont complètement accessible
mais complètement style
vous pouvez utiliser ces components
pour créer votre système de design
comme j'ai fait à Descript
et vous pouvez utiliser leurs prématives
pour construire vos propres components
donc en fait, pour construire une menu drop-down
et pour lire le spec de Y-Aria
et pour obtenir les interactions de la keyboard
vous pouvez juste utiliser leurs propres components
ajouter des classes
et vous avez un système de design
donc Radix est une bonne option
ils vont beaucoup plus loin
que Reach
Reach a un combo box
et quelques autres choses
Radix implemente 75%
de les components Y-Aria
donc
ça les cover beaucoup
pour les plus de ce que vous avez besoin
c'est vraiment important
et les packages qu'ils utilisent
sont très utiles
pour construire votre système de design
mon préféré de DX
c'est qu'il y a
une fonction de composé des handlers
où vous pouvez aller
mon onclick est un onclick
le premier argument est votre prop
donc vous faites le prop.onclick
et puis vous faites le comportement default
quand vous voulez un onclick
et le cool de ce qui est
c'est que si le premier
prop.onclick s'appelle
E.preventDefault
il ne vous invite pas le second
donc si vous voulez avoir un onclick
quelque chose
que ça arrive
vous pouvez utiliser le onclick
Radix a beaucoup de choses où
il y a des manages de focus
mais parfois peut-être que vous ne voulez pas
le focus de la main de la pièce
en ce cas tout ce que vous faites
c'est que si vous faites un onclick
vous faites le prop.onclick
et ça vous permet de faire le comportement default
donc c'est un très cool libraire
pour utiliser et regarder
pour construire votre propre système
c'est génial
ils font beaucoup de choses clés
ils ont un autre propos
comme un enfant
comme un moyen de dégager
le type de component
c'est leur component de slot
et je l'ai utilisé aujourd'hui
avec React Virtuoso
React Virtuoso
ils rendent votre table-row
dans un endroit séparé
alors que vous êtes en fait
retournant de la fonction pour votre table-row
donc
j'ai originalement eu un patch-package
où j'ai modifié leur code
mais je réalisais que je pouvais
faire chaque table-row un slot
et le slot va spreadre
tous les props et les choses importantes
pour le truc sous-leibre
je l'ai contrôlé
et je n'ai pas de patch
j'ai juste délégué
j'ai aimé le truc
pour le jour, c'est un libraire
called Mute Narrows
c'est un
très simple libraire
qui fait un truc très bien
c'est pour
recruter des réponses
d'un API
donc si vous êtes
en train de faire beaucoup de choses
pour avoir des informations potentiellement
parfois vous avez
un request de multi-part
c'est vraiment très anoyant
pour réveiller ces choses
simplement
mais cet API donne
une subscription
comme un API qui fait
vraiment bien
et très simple
pour juste avoir
des données sur votre API
j'ai eu de la chance de faire ça
c'est très simple
mais qu'est-ce que l'expérience de multi-part API
quand j'ai un de ces?
peut-être
un exemple concrète
il y a
de nombreuses différentes manières
si vous avez des données structurées
et vous avez beaucoup de données structurées
vous pouvez le servir
et ça peut être utilisé
pour beaucoup de choses différentes
mais c'est toujours
une réponse d'un API
que vous vous interviendrez en deux parts
je pense que j'ai utilisé ça pour des uploads de file
mais je vais être d'accord
oui, donc c'est
tous mes conseils de tour
qui sont liés à la migration de typescript
c'est un package appelé TSMorph
on utilise TSMorph
dans notre
code mod pour le commande fixé
mais
si vous voulez
faire un code mod
pour des sortes de syntaxe javascript
vous avez probablement utilisé Babel
Babel a un
très bien défendant
un truc pour tout et beaucoup de tools
mais
si vous voulez
faire un code mod qui aussi
a besoin d'accès
TSMorph vous fait
ça va
faire un file type script
et vous pouvez faire des modifications
mais en même temps vous avez
accès à ce que type script
connaît le file
vous pouvez rapidement modifier
types ou vous pouvez faire des tools
qui vont essayer de fixer les typescript errors
ou des choses comme ça
c'est un extra
plus bon niveau
sur les codes normales
mais nous avons utilisé ça pour
faire des scripts pour les errors
pour les appareils de la sépression
mais il y avait aussi
des choses intéressantes
type script a un feature auto import
et TSMorph
expose tout le type script
API pour vous
donc nous pouvons
voir si ça a
n'a pas été défini
ou si ce type n'a pas été défini
et nous pouvons demander
si c'est un auto import
pour ce truc qui est en train
et juste le faire et le mettre
c'est un moyen très bon
pour un script en train
de type script et tout le type
d'information
c'est un des parts délites
de type script pour moi
c'est tous les codes transformés
qui sont en train de faire leur moyen
de les faire en train de faire le type script
mon favori
que je pense que j'utilise le plus maintenant
c'est que vous pouvez, en VS Code,
cliquer sur la source action
et puis remettre tout le code en use
oh mon Dieu
ça fait que
si vous voulez un component
pour un file pour un autre
juste cliquer sur la source action
et vous n'avez pas besoin de tout le code
et vous êtes dans un bon start
et avec ça
nous sommes faits avec l'épisode
merci Tyler pour le commenter
c'était un très intéressant et détaillé
pour le type script en train de faire un large scale
donc merci pour le commenter
merci beaucoup pour le commenter
merci Tyler, c'est génial
c'est tout pour cette semaine
d'épisode de DevTools FM
à vous de suivre sur Youtube et à tous les podcasts
merci pour l'entraînement