Transitioning a React Codebase from JSX to TypeScript ft. Priscila Oliveira and Mark Story - RRU 274
November 14, 2024 • 39 mins
Priscila Oliveira and Mark Story join the panel to discuss the recent transition at Sentry from vanilla JavaScript to React and TypeScript.
The show starts out with the panelists nerding out over Sentry and how they use it, then they dive into the code transition and the things that they learned from their conversion to TypeScript.
Links
Picks
Become a supporter of this podcast: https://www.spreaker.com/podcast/react-round-up--6102072/support.
The show starts out with the panelists nerding out over Sentry and how they use it, then they dive into the code transition and the things that they learned from their conversion to TypeScript.
Links
- Slow and Steady: Converting Sentry’s Entire Frontend to TypeScript
- Twitter: Sentry ( @getsentry )
- Twitter: Mark Story ( @mark_story )
- Twitter: Priscila Oliveira ( @priscilawebdev )
Picks
- Jack- Power of saying "No"
- Mark- GitHub | neovim/nvim-lspconfig
- Mark- GitHub | glepnir/lspsaga.nvim
- Priscila - GitHub | clauderic/dnd-kit
- TJ- Divvy
Become a supporter of this podcast: https://www.spreaker.com/podcast/react-round-up--6102072/support.
Listen
Watch
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:06):
Hello everybody, and welcome to another episode of React Roundup.
My name is TJ. Van Told and with me on
the panel today is Jack Herrington. Hello, and our special
guests today are Mark Story and Priscilla Alivera. Hopefully I
pronounced her name correctly. Yeah, welcome, excellent, welcome to React Roundup.
Why don't you introduce yourself and tell us who are
(00:27):
what you do while you're famous those sorts of things.
Speaker 2 (00:30):
I don't think I'm n okay okay 'all, thanks for
having me. My name is Priscilla. I'm a software engineer
based in Vienna, and I'm a grank To employee That's
Sanctuary work on the user interface of our application, so
I'm more like a front end engineer.
Speaker 3 (00:48):
I'm Mark Story. I also work at Center It's Prisona.
I work partially on the front time and then also
a lot on the back end on their building system.
And I'm in Toronto, Canada.
Speaker 4 (00:57):
All right, So looks at y'all have an article out
on converting from javascripts to typescript for your application and
what the advantages work, and you kind of give us
a bit of a high level synopsis on that.
Speaker 3 (01:06):
Yeah, so the high level synopsis is we converted the
application from JavaScript to typescript. To Typescript is a statically
analyzed language that compiles that a JavaScript if you've not
used to it before. And so over the coross of
eighteen months, we converted the whole applicate, the whole front
end application for Century from JavaScript from JavaScript into typescript,
and then we wrote a blog post around how we
(01:27):
did it and some of the challenges we had and
some of the benefits of that.
Speaker 4 (01:31):
So, what were some of the challenges you had.
Speaker 3 (01:33):
Big code bases take a long time to migrate. I
bet so for scale like Centuries, around ninety thousand lines
of code in JavaScript, and yeah, it just took a
really long time because we weren't allowed to stop delivering features.
So yeah, the process we kind of documented was doing
that without stopping. Because there's kind of like two approaches
you can take with converting a large CUD base. You
(01:54):
can like try and freeze the earth and do everything
at once and then not do any future work. And
the other one is like do a re right, which
is also very dangerous, and the other one is that
we approach we took, which is like you modify the
code in place and then incrementally kind of change things over.
Speaker 1 (02:08):
I guess maybe we could start with what precipitated this change,
like where you internally sold and typescript and decided it
was the right move, because obviously putting in that whole effort,
you must have saw some value in doing the work.
Speaker 3 (02:20):
Yeah, I can answer that. I guess the impetus was
we were having we had several kind of production incidents happened,
customer facing pression incidents that were caused by front end
problems and the after like in the retro for like
why did we have this incident? A lot of the
like paths forward where you know, if we had better
tooling or static analysis, then we would be able to
(02:41):
prevent these kinds of problems. And so that was kind
of that happened multiple times, and the solution came up
multiple times was to you know, if we had better
linting support or better static analyzation that could come from
a tool like touch script, then we would be able
to prevent these kinds of problems because they would be
compiled tim errors versus runtime aerrors that we catch in production.
So that kind of came through and then a century
(03:02):
overy year has like a hack week, like many companies
and a bunch of engineers took the time to kind
of start the genesis of touch script conversion and make
it possible to incre mentally move the application over as
part of their project, and then so we have kind
of a proof of concept, and then from there we
were able to get buy in on converting the rest
of the application over.
Speaker 1 (03:20):
I'm curious the setup because I sort of agree with
your how you laid it out, Like when you're tackling
something big like this, I think very often, at least
in my experience, freezing everything, like for a big rewrite
is almost never an option, just because like, if you
have an app that's that much code, chances are it's
doing something important, and chances are you have to keep
(03:44):
updating and working on it. And also, like business users
don't tend to like things of like, yeah, we're going
to spend two three months on this and you'll notice
no changes. Hopefully you'll notice no changes because we might
break something too, right like those those arguments don't go
over so well. But I am curious, like because I've
absolutely never attempt this with Typescript specifically, I'm very curious
(04:07):
of the architecture you came up with to make this possible,
because I'm assuming like you were pushing out typescript files
like or at least I'm assuming it's a mechanism where
you could like convert one file the typeescript, push it up,
push it to production or whatever, and then just like
keep on working. So I'm curious, like, how like technically
you set that up to work. Is it just like
(04:28):
some fancy webpack canfig or what was going on to
make that possible?
Speaker 2 (04:32):
Oh? Yes, So we decided on converting our files incrementally
to type script, and so every day we were pushing
files to production and we used our own.
Speaker 5 (04:45):
Application to monitor errors.
Speaker 2 (04:47):
Yes, and so we had to use some webpac confix
some configuration to be able to do that. But this
is something nice in type script. You don't need to
convert the whole code base at once. You can do
it incrementally. So this was also one of the reasons
we decided to introduce typescript.
Speaker 4 (05:07):
So how many developers are on your team and how
did they fare in terms of learning pypescript And you
mentioned in the articles some educational stuff. How did that work?
Speaker 5 (05:19):
So I think we are twelve developers. Some of some
of our colleagues.
Speaker 2 (05:25):
They only work on the front end, and some of
our colleagues they are FULLD stech. So the education was
the key in this process because some colleagues they didn't
know much about typescript and we would like to. First
we created a documentation. In terms of documentation, we also
(05:47):
tried to motivate the colleagues to adopt a typescript and
once they saw the benefits, they started to use typescript
by themselves. So we never used the tooling to block
some on of pushing JSX COLDE to our code base.
Speaker 5 (06:04):
This was naturally. This happened naturally.
Speaker 4 (06:08):
So what were the big like aha, benefits for these
front end developers on like, oh, now, yes, typescript, that's awesome.
You know, it's so much better than JSX. Now I'm
never going to do JSX again.
Speaker 5 (06:19):
So auto completion for example.
Speaker 3 (06:22):
Yeah, yeah, I would say like autocompletion and compile time
checks were the two big ones. Also, like improved code navigation,
so instead of having to get your editor to go
up and find the symbol ref like most editors, when
you have the language server setup, you can jump to
symbols or like preview symbols in line with like little
floating windows. And so because the editor ecosystem, the touch
(06:46):
script team spent a lot of time making like the
dev experience really well. It was that like improved developer
experience that really kind of like helped convert people over.
Speaker 4 (06:54):
Just a quick follow up, so for editor we're talking
vs code, we're talking web the Storm or what.
Speaker 3 (07:00):
Yeah, so we have of the twelve to twenty people
that work on the front end, there's a mix of
people in bs CO. There's some Vim users and then
there's some like web Storm or like pie Storm pie
chterm users as well. So getting it to helping people
get set up with vs cod is pretty straightforward. And
then the VIM users have their own like flag channel
where they all share a vimscript and you just hang
(07:22):
out over there.
Speaker 1 (07:23):
I don't know what you all are doing, hu, I
imagine you a specially invite to and it's I'm.
Speaker 3 (07:31):
One of those Vim people as well. So it was, yeah,
we all work together to get it all working nice.
So yeah, once once everyone had their editors set up,
then the benefits become a lot more visible and a
lot more tangible. And through that and like a code
review like Priscilla was mentioning we're able to kind of
like a guide and educate people forward. And then there
was also some pair programming along the way, like you
(07:52):
should do this in in the persons I don't know,
and then we're like, okay, well we can just sit
with you and help you or like video chat with
you sitting. But yeah, that's the kind of approach we took.
Speaker 4 (08:04):
It's impressive that you did it over a pandemic, that's
for sure.
Speaker 3 (08:06):
Yeah. That affected the timelines. Yeah. When we started the project,
the timelines were like RMVP was like, well when do
you think you'll be finished? And we gave a timeline
which was complete rubbish. The pandemic came and then the
timelines were very much rubbish, and then we were dealing
with like team burnout. So yeah, just like trying to
keep people motivated was one of the harder parts. I
(08:28):
would say.
Speaker 1 (08:28):
One kind of nice thing or fun thing I see
in your article is you have on here that it's
certain points, like certain messier points. You would just leave
in comments that were like to do use like tackle
this later, And personally I kind of like that because
it's like you're talking about like using the typescript like any,
which is like the get out of jail free typescript trick.
(08:52):
But I'm curious about that approach. I think I actually
kind of like it because I'm guessing your point was
you want to get this conversion done right, like addressing
some of the messier type script aspects would potentially break
your code unnecessarily, when really you just wanted to get
things changed and get things out there. Presumably.
Speaker 3 (09:11):
Yeah, I would say we tried to use any sparingly.
We tried really hard to do the proper typing, but
there are some places, especially where our type striped interfaces,
where with React, where you can't type it all properly.
I think it's like create ref as the one that
is really annoying, Like you can't put generics through create
create ref it drops them. So we had we had
a few things like that, And we have a lot
(09:33):
of like higher order components because Century is a long
lived REACT applications, so there's many different patterns. There's a
lot of higher artwork components, and we had a lot
of problems with like default props not being able to
tunnel their way through through a higher ardor component. So
those are some of like the Typeescript challenges we kind
of like had.
Speaker 2 (09:48):
To hack around, yes, and we used to do so
we can now after the conversion, we are doing that.
Now we are checking those places, those places where we
added to do, and we are trying to find a
better type and yeah and remove to.
Speaker 5 (10:06):
Do with the correct tack.
Speaker 3 (10:07):
And we were using libraries that had some like not
ideal typing support. So we're using create react class and
some of the types get kind of squidgy when they
go through create react class. So we went back and
like removed all of create react class and like tried
to simplify some of the higher components. And we still
have a budget to Doo's love to do. So while
we're while we're done, we're not like one hundred percent
(10:29):
no any anywhere. There's still some.
Speaker 4 (10:31):
So when just typescript it was it was kind of
more generalized. Repass it with the whole system and refactor
some of the old cruft it was stuck around in
there kind of thing.
Speaker 3 (10:41):
Yeah, we tried to try to focus, like when you're
converting a file to type script or converting a module
to typescript, like just do the typescript conversions, don't make
too many run time changes unless the typing becomes really
really challenging, because conflating the run time changes with the
with the type changes kind of sets you up for
more problem BOMs than what you you'd want to take
(11:02):
on at this point in time.
Speaker 4 (11:04):
Oh loo could go wrong.
Speaker 3 (11:08):
Yeah yeah. Another thing that helped us make progress was
to kind of put like a moratorium on any like
other large scale refactoring. So another thing that we've been
battling with is is enzyme is no longer being maintained
as well as we would like to have, and we
want to like be upgraded to REACT seventeen, and enzyme
required some workarounds to make that work. So we also
(11:29):
wanted to shift off of enzyme for testing, but we
didn't want to start that until the typescript was finished
because we'd have too many like inflight projects, and you
get everything half done and then everything is just awful
for a long long period of time.
Speaker 5 (11:42):
Yes, we also we agreed that we wouldn't.
Speaker 2 (11:45):
Use reacted hooks before the conversion, before the conversion was complete.
So this was one of the things that's motivated MEATS
to convert to even more fires.
Speaker 5 (11:55):
I think not only be but to many many other colleagues.
Speaker 2 (11:58):
So finally, now after the conversion, we can use react
to hooks.
Speaker 5 (12:04):
Yay much better.
Speaker 4 (12:06):
Yeah, all right. I mean it's only been a couple
of three years since React Hooks came out. I think
something like that two years. It's been a while. Yeah, yeah,
it's nice. That's a long time. So interesting A question
for you about the educational side of the house. I've
actually done a lot of Typescript education and written, done
a bunch of videos on it and all that, and
(12:27):
a lot of questions that I get are around the
misconception that Typescript has a run time to it, that
it's going to bloat your code because it's going to
do all this type checking and things like that. And
I find it challenging to kind of get through to
folks that Typescript is just at compile time only. There
is no run time version of Typescript. How how much
of a challenge was that for you to get that
(12:49):
across to your team members and what do you say
or do to make you get them to kind of
grock that.
Speaker 3 (12:54):
I don't remember that coming up as a big problem.
We're fairly conscious of or bundle signs, so like just
comparing bundle size from the code that webpacker's generating from,
like the down compilation from like Yes six down to
or whatever version we were on, but Yes current down
to Yes five, and then comparing the typescripts compiled down.
We'd be able like it was pretty easy to demonstrate,
(13:16):
like there's no significant runtime cost on bundle size. So
I think that was the way to end that argument,
was like the bundle size is actually the same or smaller,
so it doesn't matter why typrip is doing it right.
Speaker 4 (13:28):
Well, I think there's also things like like, for example,
if you put it an interface around where you're saying, okay,
this is what we expect from the server, right, and
then you get a response from the server and it
doesn't match the payload although the type that you have
in the interface, and people kind of expect that. Oh wait,
I thought typeseop was going to validate what was coming
back from the server. And you're like, no, that's not
(13:49):
the way that No, that's not type peop's not going
to do that for you. So is that something That
kind of thing is something that I find challenging.
Speaker 2 (13:57):
Yes, yeah, so we are fortunately actually don't we don't
have our payload to type it. So many times we
have to cast it or we already know what data
we are going to get, so we we we add
in the front end the correct type.
Speaker 5 (14:17):
But that's that's what we do.
Speaker 3 (14:20):
That's what everyone has to do, though, Like there has
to be at the network boundary, you have to be like,
this is what's coming in. I promise.
Speaker 4 (14:25):
I think you swear, I promise. That's the thing, right.
I think I think people have this understanding misunderstanding like oh,
type that actually going to be like a joy or
a yup which actually goes through and literally checks to
make sure that like oh there should be an idea
here and there's not that kind of thing. But it's
not gonna do that. Yeah, no, it doesn't do that.
Speaker 3 (14:46):
That's her.
Speaker 1 (14:47):
Are there any other learning guides you would recommend, like
any like you know, courses or books or anything that
you use for for learning or teaching others that you
might recommend teach typeescript. Yeah, and if not, that's okay too.
It's just so I.
Speaker 2 (15:05):
Think in my face. For example, I learned it on
a daily basis. I needed to do something, so I
googled it and then I found a solution. I tested
and tried some things out, and yeah, I think it's
pretty much it. That are a lot of materials on internet. Yeah,
but I don't know one specific.
Speaker 3 (15:25):
Yeah, I think we gave people like some links to
like learning typescript guides, Like there's a couple of well
published webbooks that are good. The official docs are really good,
and there's a lot of like if you want to
learn it, just like like message one of us on Slack,
we'll sit with you and talk you through it, or
like work with you on it. And that was a
lot of how we did it. And like I learned
to strip through this commersion. I never used typescript before,
(15:47):
so for me, it was just like learn on the job,
how do I do this? Like, Yeah, a lot of
a lot of that and my reading other people's code
stealing ideas.
Speaker 2 (15:57):
When I joined at the Center, the typescript convey ession
was already happening, So I was happy because I had
typescripts and knowledge, and I was glad they could help
the team consequently speeding up the process so then we
could use hooks for example.
Speaker 1 (16:17):
Yeah, so I'm curious now that you have typescript out
in production. Well, I guess, first of all, has it
helped stop some of the random bugs that you got
in with the first question? And I'm also curious, like,
now that you have a complete typescript code base, are
there any things that came up with typescript specifically that
(16:37):
you maybe didn't think about early on.
Speaker 3 (16:41):
I would say the promise of, you know, solving some
of the runtime errors that could be caught by compilers
has come true. We haven't had a front end code
production incident that could have been caught by a compiler
that wasn't anymore, so we still have like people still
make mistakes. Type script is not a panalcya to solve
all bugs and prevent all problems. Doesn't do that, But
(17:04):
what it does do is stop you from like accessing
nulls and accessing undefines. So I would say those kinds
of like very visible customer problems have not been happening,
and it's forced people to think about types a little
bit better. So I feel like it helps design a
little bit ask for like things we didn't expect to happen.
Bill times have gotten longer just because the compiler. We
(17:26):
have a lot of Typescript, not a lot of touchcrip code,
but we have a sizeable chunk of Typescript codes, so
there is some added compile time. So we've tried to
mitigate that by like keeping as current as we can
with Typescript so that we always get the fastest compiler.
I guess how.
Speaker 1 (17:39):
Much longer are we talking? How long does it take
the typescript compiler and your year app a couple of minutes? Okay,
and that's something you only experience. Like dev time is fine,
right because it's like compiling as you go, But just
when you build for like a release or whatever, I.
Speaker 3 (17:55):
Think there's well, building for releases happens, like you merge
to master and then holding stuff happens, and then Docker
images have to be built, and like that whole Docker
image build process is the is a long part. I
would say the CI and local dev is the slower part,
where like spinning up webpacks, it has a like an
initial lead time of about a minute for it to
(18:16):
get started, and then in CI, like the linting and
type scripting checking takes a couple of minutes.
Speaker 4 (18:22):
Interesting, Okay. I'm playing a lot with es build and
SWC lately, which are like Rust and go jsts compilers,
and in the right context, they can make a significant
difference in those compiled.
Speaker 3 (18:36):
Times good time. That's the thing I would like to do.
We have a lot of we have a couple of
custom webpac module like custom web pack plugins, which makes
it hard because we're deeply entwined into Webpack. I've used
VTA on our fight on a little side project and
it was awesome. The compile times completely go away. But yeah,
we were kind of deep in the webpack pool.
Speaker 4 (18:59):
Yeah, VAT is amazing. So I've heard a lot of
issues around a typescript and just kind of naysayers like
I just don't want to do typescript when it comes
to more comfortable jobascript. One of another complainert here is
that it makes code ugly. So is that something that
you had any resistance on folks saying I just don't
like the look of it.
Speaker 3 (19:20):
Yes, Yes, the CTO was very much like typescript just
makes code ugly and hard to read, But we did it. Anyways.
I would say that like we also, like Century is
a is a mixed shop. So we have something we
have a lot of JavaScript, we have Python, and then
we also have Rust, and so typescript is not nearly
as ugly as rust, so it's quite.
Speaker 4 (19:42):
Palatable fighting words right there.
Speaker 1 (19:48):
It's funny. It's all in the idea to beholder, because
I worked for a company that was a long time
dot net shop, and they considered typescript like the height
of elegance, right because it's it's made by the same
person behind like c Sharp, who's like the dot net guru.
So they considered like tight script to be like an
enlightened form of JavaScript. And so I think it's it's
(20:11):
all relative to what your background is or what your
personal preferences are.
Speaker 3 (20:15):
Yeah, so like the touch script is ugly. Camp came
from like Python, where everything is like very syntactically very
like it's low low noise or like low volume, I guess,
and touch script has a lot more like punctuation to it,
and Rust has more punctuation. I don't think Rust or
typescript are ugly, Like they're both very readable. They're just
you just have to have a lot more like the
(20:36):
dense they're just dense languages.
Speaker 4 (20:38):
Oh no, I think we should stick with that because
it makes a great subtitle for the podcast. Is you
know once it again typescript, It's nowhere near as ugly
as rust.
Speaker 1 (20:45):
And that's it right there, not as ugly as rust.
We should just call it is typescript code ugly. Just
I think it's like bait title right there. What you're
used to right like, you're not used to list list
could be very ugly.
Speaker 4 (21:01):
All yeah, I think you can. There can definitely be
some readability issues when it comes to generics, and I
don't think any language that supports generics has actually solved
that challenge. But generics are incredibly important in retaining the
type safety of your components or whatever you're you're using.
So have you seen folks maybe almost go too far
(21:24):
with generics. I mean I've definitely seen that. As another complaint,
which is people saying, oh, you know, it gets really complex.
Speaker 3 (21:31):
I would say we have we don't have a ton
of generics. We have a lot of intersection types, and
we've had typescript yell at us that the type is
too complicated. This came up when with our like main
event payload if you include all of the properties types
trips like no, I don't want to really, I've never
seen them. Yeah, Or that's another one we had was
(21:52):
the top level form like form input, where you can
push a type as a string, and then you can
get to all of the various input types in that
we have in century. We were just trying to like
intersection all of those types of like union, all of
those different formats together with a discriminated field and a
certain point too is like Noah, I don't want to
do this, Like there's too many conflicts. Wow, type it's
(22:14):
too big, please stop.
Speaker 4 (22:15):
WHOA, I've never seen that.
Speaker 3 (22:19):
It was not a good thing to say.
Speaker 5 (22:23):
I don't think we have a lot of generics in
our cult.
Speaker 3 (22:26):
Yeah, we have some, but not as not many, not
like there's not a lot of like three tier generics,
like the like generic of a generic of a generic,
Like we don't try just trying to do that.
Speaker 1 (22:36):
One thing I've noticed from doing this podcast is that
the people that struggle with typescript the most seem to
be people like library authors that have these like general
purpose APIs, because those are the ones that are really
hard to configure, like if you're the person that's in
charge of making the types for like reactor or like
some of the libraries you were speaking of that had
(22:58):
for support, I imagine part of the reason why they
have pre support is that they have to get into
like crazy levels of like generics and intersection types because
they're kind of designed for general purpose use. So that's
where I think some of the struggles with typescript comes in.
But the thing is like in your average app, even
like big apps, like the ones you're working on, like that,
those are like fringe situations I feel like, because I mean,
(23:22):
most of the time the types you're dealing with while
you have objects to raise strings numbers, right, you're you're
not doing anything like crazy, And it sounds like that's
sort of the case with what you've been working on
as well.
Speaker 3 (23:35):
Yeah, I would say, like for a lot of like
web applications, you're dealing with like API responses and then
converting those around like munging that data and then turning
it into into use state, right Like, so I would
completely agree that you're not dealing with the crazy generics,
I would say, yeah, And I think you're respont on
with like the library the library author part, Like, especially
(23:55):
if the library started off as as a JavaScript library
and then was converted to typescript. I think that's where
you really run into it because they've leveraged the dynamic
properties of JavaScript and like the ability to be very
polymorphic on anything and not kind of bite someone they
try and turn into the typeescript. Yeah.
Speaker 1 (24:11):
I think it was last week. Week before, we were
talking to an author of a form library and they
were relaying horror stories of like it sounds like you
have a similar experience as well, Like they had form things,
but forms can contain all sorts of types, so they
got into some insanity in terms of defining that.
Speaker 3 (24:31):
Yeah, I could see a form library being really hard.
Speaker 5 (24:34):
Yeah.
Speaker 4 (24:35):
One of the nice things about that though, is sometimes
you can kind of contain that in insanity. If you've got,
for example, a set of shared components, like the button
that you're using everywhere, right, the type definition of a
button might be a little bit complex because you might
be bringing in like detailed HTML props, which has a
really weird complex signature, but you want to get all
of the extra types for a button and you don't
(24:57):
want to define those yourself. So that's actually really nice.
But the complexity is sort of contained within that that
that library of your your share components, and then as
as a user, right, you just pull you just import
button and the next thing, you know, you get hinting
for on click and everything just works, and so that's
kind of nice. And sometimes, you know, you can hide
the complexity a little bit of the of the typescript stuff.
(25:18):
It's not in your face like all the time. I
feel like you get tuk with like well designed libraries. Yeah,
but it is tougher, I guess for older libraries that
were written in a style that was less kind of normalized.
Maybe you know, you have to start using some of
the weirder features of typescript to deal with that, like
function overloading, which I don't even think people know exists
(25:40):
inside typescript, but actually it does and you can use it.
Speaker 3 (25:43):
We had to use it.
Speaker 4 (25:45):
Oh there you go, Okay, you know when you need it.
It's actually really handy, but it's a it's a weird implementation.
It's not like C sharp or C plus plus or Java.
It's a sort of it's it's just kind of like
multiple signatures for actually what's really just one function.
Speaker 3 (26:00):
But to use a lot of type guards to break
down our unions too into those. Yeah, those are some
of the like the weirder types of stuff we have
to use. Was function overloading, a lot of like type guards,
custom type guards and big unions and intersections.
Speaker 1 (26:14):
Cool nice, So one thing it'd be fun to talk
about because I'm I know we have a lot of
listeners that are working on similar types of apps, right,
large projects that have been around for a while, and
that they also have a laundry list of things that
they want done, whether you know, they want to be
using hooks or they want to be using typescript or
whatever the case may be. So I'm curious, and we
(26:37):
did discuss some of this, but I'm curious if you
have any other advice for convincing like management that like, hey,
like this is a worthwhile effort, because I know that
can be a struggle for a lot of people to
get time sort of approved to do this, and then
also like seeing these projects through, because not every large
scale effort like this ends with one hundred percent conversion
(26:59):
and success, right, So it's kind of impressive that you
you push this to the finish line. So I'd be
curious if you have any other advice in terms of
how to make that sort of thing happen and how
to see something of this scale through.
Speaker 2 (27:12):
So how to convince management to adopt type script. I
would say that only the possibility to catch errors on
the compiled times.
Speaker 5 (27:22):
It's amazing, you know, So this is amazing.
Speaker 2 (27:26):
Also we could reduce the need for API documentation because
type script it self self explain everything the type and
also autocompletion. So I believe this type script the team,
it's faster, the product productivity is faster than usual.
Speaker 3 (27:50):
Guess on the like how do you get it to finish?
We're really fortunate that we have we have like a
front end steering community, and the main contributors to the
Techica project were also part of that kind of steering committee,
and so we just had to kind of stick to
our guns, like no new big projects until this one
is finished. And towards the end of the project, we
(28:13):
were kind of like every week kind of asking people
like how many files are you going to convert? People
would volunteer like convert a couple, or I'll convert two
or I'll convert three, and then every week check in
with those people like did you get your stuff done?
What are you going to do next week? And that
helps kind of like gamify lightly people's desire to be involved.
I would say another thing that helped us finish was
(28:34):
that we did it in the long term, and so
we weren't rushing to meet a deadline. Instead, we were
just giving updates on like when we would finish. So
instead of it being like you must be finished by
December of twenty twenty, or your project is out of gas,
it was more like we're just going to do this slow.
We're going to do it the right way, like the
right way for us, which is like not slap any
on everything and do a machine organization. We're going to
(28:57):
take our time, going to do it, you know, so
that we have something that we're proud of when we're finished,
and then just give updates on when we will be done.
And then as long as people were meeting their project
delivery like deliverables, the front time folks were able to
focus as much as they wanted on tuch script. That
was the kind of like their B project was converting
to touch script, and all the managers, like all the
team managers knew about it, all the engineering managers knew
(29:19):
about it, knew who was contributing to it, and so
they were kind of like on board, like this is
this person's be project.
Speaker 1 (29:25):
Yeah, I think all that is great, Like I like
Priscilla's points of proving to management. It's like a lot
of those points you made were really about proving that
this is going to be long term a net positive right,
like well, like the fewer bugs and more productivity will
make this time like pay off and the long run.
And then I also like the points just in terms
of keep seeing this through to the finish, like the
(29:48):
accountability bit, like having someone that's in charge of the
project that reaches out and forces people to say, I'm
going to do this and almost gamifying it a little bit,
or at least like holding people accountable so that there's
that constant update, like it doesn't get lost because I
know what, I've been involved in projects like this before.
(30:08):
Sometimes it's going well, but then some big feature comes
down from business or some big bug happens, and then
all of a sudden, like this thing that's very low
priority gets sidetracked sometimes to never reappear. So I think
having like someone on it and someone constantly checking in
through all of that can make a big difference.
Speaker 6 (30:30):
Yeah, I'd also say another thing that helped us was like, yeah,
constantly checking in, constantly double checking, and then also making
sure all the new code was written in touch shriped
was a big monumental thing to get done, was like
convince everyone that touch script is worth learning and then
also get them to stop writing JavaScript, because if we
(30:51):
never stopped writing.
Speaker 3 (30:52):
JavaScript, we would never finish. And so for us to
be able to complete, like and to prove that the
tuchrip project was going to actually finish both through ourselves
and up management, was to get everyone to stop writing cabscript.
And we're way past that point now, but that was
a that was a key turning point, was getting everyone
on board.
Speaker 4 (31:08):
Yeah, so that actually leads a question, So would you
personally ever want to work on a streat JavaScript application?
Speaker 3 (31:15):
Again, Yeah, it would. It's not as good as like typeshrip,
Like you get a lot more benefits out of having
it in type strip. And if I was to start
a new project, I would definitely start it in typescript.
Sure how about you, Priscilla?
Speaker 5 (31:26):
Yeah, me too, Me too.
Speaker 2 (31:27):
Last week we had again heck quick and I work
it on two projects and I used typescript. So I
started from scratch and I decided to use tapscript because yeah,
I really like it.
Speaker 4 (31:40):
And I think that's something again with talking to management, right,
hiring is always an issue. It's a very hot hiring
market right now. People can move between jobs very quickly,
and people are evaluating what they're going to be going into.
And if you're saying, hey, you know, we're doing React
circa twenty fifteen in JavaScript, come on down, we were
(32:00):
going to be like, I really enjoy you know, typescript
and hooks. I mean Rizilla's like, yes, hooks, you know,
so you want to work in a modern code base.
And I think that's the thing, you know, when you
talk managements as a selling.
Speaker 3 (32:15):
Point, Yeah, for sure, And I think that was something
our like our vps knew as well, Like the VP
that we were working with then is like very much
understanding of that. People want to be on the vanguard
and want to be working with new stuff when Century
as a company does that a lot as well. So
I think that's an important point to make if you're
in an organization where that isn't part of the company's culture.
Speaker 2 (32:38):
I'd like to addit that we are always trying to
introduce new technologies and for example, now we just introduced
reactive Testing Library, so we are planning of converting our
tests to from ENSIGN to reacted Testing Library, and that's
pretty cool.
Speaker 1 (32:55):
Yeah, I was just going to say that the it's
a really good point that like sometimes like you, you
are not in control of your management and your your
team or like entire organization. And not to put this
to blunt, but I mean, if if your organization is
really obstinate, if your managers aren't great, you know, it
is a hiring markets. You know, there are other decent
(33:17):
teams out there. So if you really are like super
super struggling and working on stuff you're not interested in,
maybe you consider other things as well, because they're everybody's
got like old code you know, bad code bases and such.
But having a culture that encourages that sort of thing
and allows you to you know, ramp up over time,
I think is a really big deal.
Speaker 3 (33:39):
Like century is an old code base, it's coming up
on eight nine years. But at the same time, we
also like to fix it and see the value in
investing it and making it current and like keeping it
up to day. Like on the on the not front time,
we've just finished like a humongous amount of Python upgrades,
like from Python two to Python three, from Jengle one
to six, all the way to gay Go two point two.
(34:00):
Like that's been eight months of work, and all of
that is to get us up to a new version
of Pythons so we can get performance. Actually the main
driver of that.
Speaker 1 (34:08):
And I have to imagine too, like like pushing those
things to production is immensely satisfying as well. Like it's
it's like the same sort of things that like when
you finish. Like for me, it's like if I'm I
like if I mow my lawn, Like there's that moment
like when you're done, Like I hate mowing my lawn,
But at the same time, when I'm done, like looking
out over it, it's like, yeah, I crushed that, Like
look how good that grasped.
Speaker 4 (34:29):
Yeah, I was gonna say, like that last puzzle piece,
you know, when you got a thousand piece puzzle. I
can only imagine like that last JSTS file, right, the
last commit was like, yes, we did it, you know
as a team. You know, if you're in slack, you're like, yeah,
that last little.
Speaker 5 (34:45):
Bit, Yes, we celebrate it.
Speaker 4 (34:47):
I want Yeah, nice, Priscilla, was that your your file?
Who was the last person to actually like do the
last file?
Speaker 3 (34:53):
I think it was vin a right of us. I
think it was one of the other one of the
other folks.
Speaker 2 (35:00):
We let the lashest files, the most complex files.
Speaker 5 (35:04):
To the end, and yeah, I can't remember the last
to us.
Speaker 3 (35:11):
Yeah, there's some like changing of tactics through it. It
was like start with the biggest, start with the files
that are important the most. Then start with the files
that are imported with the least because these most important
files are becoming annoying. And then it was like important
you do like one whole view tree. There was a
bunch of different tactics, but yeah, there was a bunch
of big rocks at the end.
Speaker 4 (35:29):
Yeah, you did mention that in the article where you mentioned,
you know, there's sometimes you work from the core and
other times you work from the leaves. And that's actually
a very interesting question out there is, hey, we get
the typescript is awesome, you know, how do we go
and take our twenty thousand and thirty thousand file project
and bring that over? Like, what what are some good strategies?
And I don't unfortunately I think the answer probably there
(35:51):
is It depends terrible answer. Yes, yes totally.
Speaker 3 (35:58):
I would say, like, try a bunch of different approaches
and see which ones help you get progress, Like the
if your goal is to convert that twenty thousand file project.
Over do the things that are going to help you
get progress, like if you're going to measure progress on
number of files, aim for like choose whatever tactic is
going to yield you the most amount of progress at
the beginning, so you can get a good foothold so
you can get people invested and get people ready to
(36:22):
help out.
Speaker 4 (36:22):
Yeah, you want to finish up on that. I feel
like you left out. Okay, that's cool, all right, awesome,
very cool. Well this has been really really fun. I
think now is the time to get into this week's picks,
So mark one, lead us off on your pick for
this week.
Speaker 3 (36:38):
Sure, yeah, I would say the new version of them,
NEOHIM zero five has native language server support, so you
can configure neovim with LUO, which is nice. You don't
have to use vimscripts, which is my least favorite programming language,
and you can use LUI descripted and then the native
LSP look looks really good and works really well. So
check out new of them and some of the new
(36:59):
native LSP. Very cool about you, Bricella.
Speaker 5 (37:02):
Oh I think so?
Speaker 4 (37:04):
Yeah?
Speaker 2 (37:05):
So that is this library D and D kit. I
really like that one. It's They have an amazing documentation.
It's very easy to customize and yeah, it's amazing the library.
It's very light as well.
Speaker 4 (37:19):
What did you do? D and D kit? Yeah, it's
not disturbed.
Speaker 2 (37:22):
So recently we had to introduce dragon drop in century
and we founded this library and it's amazing.
Speaker 5 (37:31):
We are really enjoying using it.
Speaker 3 (37:33):
Cool.
Speaker 4 (37:34):
Yeah, there's so many D and ds. There's dragon draw
theres do not disturb Dungeons and Dragons. It's very very popular,
you know, three letter combination.
Speaker 3 (37:43):
I guess.
Speaker 5 (37:44):
Yeah.
Speaker 4 (37:45):
And for my pick, I am going to go with
a bit more metaphorical. Just the power of saying no.
I know that we just we talked a little bit
about burnout in the beginning of this episode, and the
I find the major key for me to avoid burnout
is to just say no, you know, reduce the amount
of stuff on your plate. You get less stressed out,
(38:06):
and you just feel better about the attraction you make
in a day by saying no to a lot of
these small projects, even the ones that you want to
do for yourself. So I think that's really important.
Speaker 2 (38:16):
I think here, I read a book about it, but
I can't remember the title. How to give a sheet.
I don't I cannot remember the time, but it was
exactly about it the.
Speaker 5 (38:29):
Power of no.
Speaker 4 (38:30):
Yeah. I know we all want to be nice people,
we all want to help out our friends and all that,
but you know, you can just get snowed under on
all these things, and work is just work alone is
very stressful. So you know you don't want to take
on too much. You want to live a happy and
healthy life and you know, go out and do kayaking
or whatever you enjoy. So take that time and be
(38:51):
confident and say no, yes, definitely, TJ, you want to
take us out.
Speaker 1 (38:55):
Yeah. I will not be picking comcasts this week, as
I hope this doesn't come through the editing, but my
Internet has been catastrophic here lately. But I will pick
a window manager for the Mac called Divvy dvv y,
one thing that I am shocked the Mac still doesn't
have it built in, just a way of snapping a
window to a certain part of a screen. It's crazy
(39:17):
to me that you have to like look out for
a third party app for that. But Divvy is a
pretty decent one if you don't already have one, and
I'd recommend it, especially if you have like a widescreen
monitor just because being able to dock windows is super
nice and super time saving.
Speaker 4 (39:32):
Absolutely thanks for that. I'll check that out all right. Well,
thank you so much for showing up. That was an
awesome episode and we'll see you next week.
Speaker 5 (39:39):
See
Hello everybody, and welcome to another episode of React Roundup.
My name is TJ. Van Told and with me on
the panel today is Jack Herrington. Hello, and our special
guests today are Mark Story and Priscilla Alivera. Hopefully I
pronounced her name correctly. Yeah, welcome, excellent, welcome to React Roundup.
Why don't you introduce yourself and tell us who are
(00:27):
what you do while you're famous those sorts of things.
Speaker 2 (00:30):
I don't think I'm n okay okay 'all, thanks for
having me. My name is Priscilla. I'm a software engineer
based in Vienna, and I'm a grank To employee That's
Sanctuary work on the user interface of our application, so
I'm more like a front end engineer.
Speaker 3 (00:48):
I'm Mark Story. I also work at Center It's Prisona.
I work partially on the front time and then also
a lot on the back end on their building system.
And I'm in Toronto, Canada.
Speaker 4 (00:57):
All right, So looks at y'all have an article out
on converting from javascripts to typescript for your application and
what the advantages work, and you kind of give us
a bit of a high level synopsis on that.
Speaker 3 (01:06):
Yeah, so the high level synopsis is we converted the
application from JavaScript to typescript. To Typescript is a statically
analyzed language that compiles that a JavaScript if you've not
used to it before. And so over the coross of
eighteen months, we converted the whole applicate, the whole front
end application for Century from JavaScript from JavaScript into typescript,
and then we wrote a blog post around how we
(01:27):
did it and some of the challenges we had and
some of the benefits of that.
Speaker 4 (01:31):
So, what were some of the challenges you had.
Speaker 3 (01:33):
Big code bases take a long time to migrate. I
bet so for scale like Centuries, around ninety thousand lines
of code in JavaScript, and yeah, it just took a
really long time because we weren't allowed to stop delivering features.
So yeah, the process we kind of documented was doing
that without stopping. Because there's kind of like two approaches
you can take with converting a large CUD base. You
(01:54):
can like try and freeze the earth and do everything
at once and then not do any future work. And
the other one is like do a re right, which
is also very dangerous, and the other one is that
we approach we took, which is like you modify the
code in place and then incrementally kind of change things over.
Speaker 1 (02:08):
I guess maybe we could start with what precipitated this change,
like where you internally sold and typescript and decided it
was the right move, because obviously putting in that whole effort,
you must have saw some value in doing the work.
Speaker 3 (02:20):
Yeah, I can answer that. I guess the impetus was
we were having we had several kind of production incidents happened,
customer facing pression incidents that were caused by front end
problems and the after like in the retro for like
why did we have this incident? A lot of the
like paths forward where you know, if we had better
tooling or static analysis, then we would be able to
(02:41):
prevent these kinds of problems. And so that was kind
of that happened multiple times, and the solution came up
multiple times was to you know, if we had better
linting support or better static analyzation that could come from
a tool like touch script, then we would be able
to prevent these kinds of problems because they would be
compiled tim errors versus runtime aerrors that we catch in production.
So that kind of came through and then a century
(03:02):
overy year has like a hack week, like many companies
and a bunch of engineers took the time to kind
of start the genesis of touch script conversion and make
it possible to incre mentally move the application over as
part of their project, and then so we have kind
of a proof of concept, and then from there we
were able to get buy in on converting the rest
of the application over.
Speaker 1 (03:20):
I'm curious the setup because I sort of agree with
your how you laid it out, Like when you're tackling
something big like this, I think very often, at least
in my experience, freezing everything, like for a big rewrite
is almost never an option, just because like, if you
have an app that's that much code, chances are it's
doing something important, and chances are you have to keep
(03:44):
updating and working on it. And also, like business users
don't tend to like things of like, yeah, we're going
to spend two three months on this and you'll notice
no changes. Hopefully you'll notice no changes because we might
break something too, right like those those arguments don't go
over so well. But I am curious, like because I've
absolutely never attempt this with Typescript specifically, I'm very curious
(04:07):
of the architecture you came up with to make this possible,
because I'm assuming like you were pushing out typescript files
like or at least I'm assuming it's a mechanism where
you could like convert one file the typeescript, push it up,
push it to production or whatever, and then just like
keep on working. So I'm curious, like, how like technically
you set that up to work. Is it just like
(04:28):
some fancy webpack canfig or what was going on to
make that possible?
Speaker 2 (04:32):
Oh? Yes, So we decided on converting our files incrementally
to type script, and so every day we were pushing
files to production and we used our own.
Speaker 5 (04:45):
Application to monitor errors.
Speaker 2 (04:47):
Yes, and so we had to use some webpac confix
some configuration to be able to do that. But this
is something nice in type script. You don't need to
convert the whole code base at once. You can do
it incrementally. So this was also one of the reasons
we decided to introduce typescript.
Speaker 4 (05:07):
So how many developers are on your team and how
did they fare in terms of learning pypescript And you
mentioned in the articles some educational stuff. How did that work?
Speaker 5 (05:19):
So I think we are twelve developers. Some of some
of our colleagues.
Speaker 2 (05:25):
They only work on the front end, and some of
our colleagues they are FULLD stech. So the education was
the key in this process because some colleagues they didn't
know much about typescript and we would like to. First
we created a documentation. In terms of documentation, we also
(05:47):
tried to motivate the colleagues to adopt a typescript and
once they saw the benefits, they started to use typescript
by themselves. So we never used the tooling to block
some on of pushing JSX COLDE to our code base.
Speaker 5 (06:04):
This was naturally. This happened naturally.
Speaker 4 (06:08):
So what were the big like aha, benefits for these
front end developers on like, oh, now, yes, typescript, that's awesome.
You know, it's so much better than JSX. Now I'm
never going to do JSX again.
Speaker 5 (06:19):
So auto completion for example.
Speaker 3 (06:22):
Yeah, yeah, I would say like autocompletion and compile time
checks were the two big ones. Also, like improved code navigation,
so instead of having to get your editor to go
up and find the symbol ref like most editors, when
you have the language server setup, you can jump to
symbols or like preview symbols in line with like little
floating windows. And so because the editor ecosystem, the touch
(06:46):
script team spent a lot of time making like the
dev experience really well. It was that like improved developer
experience that really kind of like helped convert people over.
Speaker 4 (06:54):
Just a quick follow up, so for editor we're talking
vs code, we're talking web the Storm or what.
Speaker 3 (07:00):
Yeah, so we have of the twelve to twenty people
that work on the front end, there's a mix of
people in bs CO. There's some Vim users and then
there's some like web Storm or like pie Storm pie
chterm users as well. So getting it to helping people
get set up with vs cod is pretty straightforward. And
then the VIM users have their own like flag channel
where they all share a vimscript and you just hang
(07:22):
out over there.
Speaker 1 (07:23):
I don't know what you all are doing, hu, I
imagine you a specially invite to and it's I'm.
Speaker 3 (07:31):
One of those Vim people as well. So it was, yeah,
we all work together to get it all working nice.
So yeah, once once everyone had their editors set up,
then the benefits become a lot more visible and a
lot more tangible. And through that and like a code
review like Priscilla was mentioning we're able to kind of
like a guide and educate people forward. And then there
was also some pair programming along the way, like you
(07:52):
should do this in in the persons I don't know,
and then we're like, okay, well we can just sit
with you and help you or like video chat with
you sitting. But yeah, that's the kind of approach we took.
Speaker 4 (08:04):
It's impressive that you did it over a pandemic, that's
for sure.
Speaker 3 (08:06):
Yeah. That affected the timelines. Yeah. When we started the project,
the timelines were like RMVP was like, well when do
you think you'll be finished? And we gave a timeline
which was complete rubbish. The pandemic came and then the
timelines were very much rubbish, and then we were dealing
with like team burnout. So yeah, just like trying to
keep people motivated was one of the harder parts. I
(08:28):
would say.
Speaker 1 (08:28):
One kind of nice thing or fun thing I see
in your article is you have on here that it's
certain points, like certain messier points. You would just leave
in comments that were like to do use like tackle
this later, And personally I kind of like that because
it's like you're talking about like using the typescript like any,
which is like the get out of jail free typescript trick.
(08:52):
But I'm curious about that approach. I think I actually
kind of like it because I'm guessing your point was
you want to get this conversion done right, like addressing
some of the messier type script aspects would potentially break
your code unnecessarily, when really you just wanted to get
things changed and get things out there. Presumably.
Speaker 3 (09:11):
Yeah, I would say we tried to use any sparingly.
We tried really hard to do the proper typing, but
there are some places, especially where our type striped interfaces,
where with React, where you can't type it all properly.
I think it's like create ref as the one that
is really annoying, Like you can't put generics through create
create ref it drops them. So we had we had
a few things like that, And we have a lot
(09:33):
of like higher order components because Century is a long
lived REACT applications, so there's many different patterns. There's a
lot of higher artwork components, and we had a lot
of problems with like default props not being able to
tunnel their way through through a higher ardor component. So
those are some of like the Typeescript challenges we kind
of like had.
Speaker 2 (09:48):
To hack around, yes, and we used to do so
we can now after the conversion, we are doing that.
Now we are checking those places, those places where we
added to do, and we are trying to find a
better type and yeah and remove to.
Speaker 5 (10:06):
Do with the correct tack.
Speaker 3 (10:07):
And we were using libraries that had some like not
ideal typing support. So we're using create react class and
some of the types get kind of squidgy when they
go through create react class. So we went back and
like removed all of create react class and like tried
to simplify some of the higher components. And we still
have a budget to Doo's love to do. So while
we're while we're done, we're not like one hundred percent
(10:29):
no any anywhere. There's still some.
Speaker 4 (10:31):
So when just typescript it was it was kind of
more generalized. Repass it with the whole system and refactor
some of the old cruft it was stuck around in
there kind of thing.
Speaker 3 (10:41):
Yeah, we tried to try to focus, like when you're
converting a file to type script or converting a module
to typescript, like just do the typescript conversions, don't make
too many run time changes unless the typing becomes really
really challenging, because conflating the run time changes with the
with the type changes kind of sets you up for
more problem BOMs than what you you'd want to take
(11:02):
on at this point in time.
Speaker 4 (11:04):
Oh loo could go wrong.
Speaker 3 (11:08):
Yeah yeah. Another thing that helped us make progress was
to kind of put like a moratorium on any like
other large scale refactoring. So another thing that we've been
battling with is is enzyme is no longer being maintained
as well as we would like to have, and we
want to like be upgraded to REACT seventeen, and enzyme
required some workarounds to make that work. So we also
(11:29):
wanted to shift off of enzyme for testing, but we
didn't want to start that until the typescript was finished
because we'd have too many like inflight projects, and you
get everything half done and then everything is just awful
for a long long period of time.
Speaker 5 (11:42):
Yes, we also we agreed that we wouldn't.
Speaker 2 (11:45):
Use reacted hooks before the conversion, before the conversion was complete.
So this was one of the things that's motivated MEATS
to convert to even more fires.
Speaker 5 (11:55):
I think not only be but to many many other colleagues.
Speaker 2 (11:58):
So finally, now after the conversion, we can use react
to hooks.
Speaker 5 (12:04):
Yay much better.
Speaker 4 (12:06):
Yeah, all right. I mean it's only been a couple
of three years since React Hooks came out. I think
something like that two years. It's been a while. Yeah, yeah,
it's nice. That's a long time. So interesting A question
for you about the educational side of the house. I've
actually done a lot of Typescript education and written, done
a bunch of videos on it and all that, and
(12:27):
a lot of questions that I get are around the
misconception that Typescript has a run time to it, that
it's going to bloat your code because it's going to
do all this type checking and things like that. And
I find it challenging to kind of get through to
folks that Typescript is just at compile time only. There
is no run time version of Typescript. How how much
of a challenge was that for you to get that
(12:49):
across to your team members and what do you say
or do to make you get them to kind of
grock that.
Speaker 3 (12:54):
I don't remember that coming up as a big problem.
We're fairly conscious of or bundle signs, so like just
comparing bundle size from the code that webpacker's generating from,
like the down compilation from like Yes six down to
or whatever version we were on, but Yes current down
to Yes five, and then comparing the typescripts compiled down.
We'd be able like it was pretty easy to demonstrate,
(13:16):
like there's no significant runtime cost on bundle size. So
I think that was the way to end that argument,
was like the bundle size is actually the same or smaller,
so it doesn't matter why typrip is doing it right.
Speaker 4 (13:28):
Well, I think there's also things like like, for example,
if you put it an interface around where you're saying, okay,
this is what we expect from the server, right, and
then you get a response from the server and it
doesn't match the payload although the type that you have
in the interface, and people kind of expect that. Oh wait,
I thought typeseop was going to validate what was coming
back from the server. And you're like, no, that's not
(13:49):
the way that No, that's not type peop's not going
to do that for you. So is that something That
kind of thing is something that I find challenging.
Speaker 2 (13:57):
Yes, yeah, so we are fortunately actually don't we don't
have our payload to type it. So many times we
have to cast it or we already know what data
we are going to get, so we we we add
in the front end the correct type.
Speaker 5 (14:17):
But that's that's what we do.
Speaker 3 (14:20):
That's what everyone has to do, though, Like there has
to be at the network boundary, you have to be like,
this is what's coming in. I promise.
Speaker 4 (14:25):
I think you swear, I promise. That's the thing, right.
I think I think people have this understanding misunderstanding like oh,
type that actually going to be like a joy or
a yup which actually goes through and literally checks to
make sure that like oh there should be an idea
here and there's not that kind of thing. But it's
not gonna do that. Yeah, no, it doesn't do that.
Speaker 3 (14:46):
That's her.
Speaker 1 (14:47):
Are there any other learning guides you would recommend, like
any like you know, courses or books or anything that
you use for for learning or teaching others that you
might recommend teach typeescript. Yeah, and if not, that's okay too.
It's just so I.
Speaker 2 (15:05):
Think in my face. For example, I learned it on
a daily basis. I needed to do something, so I
googled it and then I found a solution. I tested
and tried some things out, and yeah, I think it's
pretty much it. That are a lot of materials on internet. Yeah,
but I don't know one specific.
Speaker 3 (15:25):
Yeah, I think we gave people like some links to
like learning typescript guides, Like there's a couple of well
published webbooks that are good. The official docs are really good,
and there's a lot of like if you want to
learn it, just like like message one of us on Slack,
we'll sit with you and talk you through it, or
like work with you on it. And that was a
lot of how we did it. And like I learned
to strip through this commersion. I never used typescript before,
(15:47):
so for me, it was just like learn on the job,
how do I do this? Like, Yeah, a lot of
a lot of that and my reading other people's code
stealing ideas.
Speaker 2 (15:57):
When I joined at the Center, the typescript convey ession
was already happening, So I was happy because I had
typescripts and knowledge, and I was glad they could help
the team consequently speeding up the process so then we
could use hooks for example.
Speaker 1 (16:17):
Yeah, so I'm curious now that you have typescript out
in production. Well, I guess, first of all, has it
helped stop some of the random bugs that you got
in with the first question? And I'm also curious, like,
now that you have a complete typescript code base, are
there any things that came up with typescript specifically that
(16:37):
you maybe didn't think about early on.
Speaker 3 (16:41):
I would say the promise of, you know, solving some
of the runtime errors that could be caught by compilers
has come true. We haven't had a front end code
production incident that could have been caught by a compiler
that wasn't anymore, so we still have like people still
make mistakes. Type script is not a panalcya to solve
all bugs and prevent all problems. Doesn't do that, But
(17:04):
what it does do is stop you from like accessing
nulls and accessing undefines. So I would say those kinds
of like very visible customer problems have not been happening,
and it's forced people to think about types a little
bit better. So I feel like it helps design a
little bit ask for like things we didn't expect to happen.
Bill times have gotten longer just because the compiler. We
(17:26):
have a lot of Typescript, not a lot of touchcrip code,
but we have a sizeable chunk of Typescript codes, so
there is some added compile time. So we've tried to
mitigate that by like keeping as current as we can
with Typescript so that we always get the fastest compiler.
I guess how.
Speaker 1 (17:39):
Much longer are we talking? How long does it take
the typescript compiler and your year app a couple of minutes? Okay,
and that's something you only experience. Like dev time is fine,
right because it's like compiling as you go, But just
when you build for like a release or whatever, I.
Speaker 3 (17:55):
Think there's well, building for releases happens, like you merge
to master and then holding stuff happens, and then Docker
images have to be built, and like that whole Docker
image build process is the is a long part. I
would say the CI and local dev is the slower part,
where like spinning up webpacks, it has a like an
initial lead time of about a minute for it to
(18:16):
get started, and then in CI, like the linting and
type scripting checking takes a couple of minutes.
Speaker 4 (18:22):
Interesting, Okay. I'm playing a lot with es build and
SWC lately, which are like Rust and go jsts compilers,
and in the right context, they can make a significant
difference in those compiled.
Speaker 3 (18:36):
Times good time. That's the thing I would like to do.
We have a lot of we have a couple of
custom webpac module like custom web pack plugins, which makes
it hard because we're deeply entwined into Webpack. I've used
VTA on our fight on a little side project and
it was awesome. The compile times completely go away. But yeah,
we were kind of deep in the webpack pool.
Speaker 4 (18:59):
Yeah, VAT is amazing. So I've heard a lot of
issues around a typescript and just kind of naysayers like
I just don't want to do typescript when it comes
to more comfortable jobascript. One of another complainert here is
that it makes code ugly. So is that something that
you had any resistance on folks saying I just don't
like the look of it.
Speaker 3 (19:20):
Yes, Yes, the CTO was very much like typescript just
makes code ugly and hard to read, But we did it. Anyways.
I would say that like we also, like Century is
a is a mixed shop. So we have something we
have a lot of JavaScript, we have Python, and then
we also have Rust, and so typescript is not nearly
as ugly as rust, so it's quite.
Speaker 4 (19:42):
Palatable fighting words right there.
Speaker 1 (19:48):
It's funny. It's all in the idea to beholder, because
I worked for a company that was a long time
dot net shop, and they considered typescript like the height
of elegance, right because it's it's made by the same
person behind like c Sharp, who's like the dot net guru.
So they considered like tight script to be like an
enlightened form of JavaScript. And so I think it's it's
(20:11):
all relative to what your background is or what your
personal preferences are.
Speaker 3 (20:15):
Yeah, so like the touch script is ugly. Camp came
from like Python, where everything is like very syntactically very
like it's low low noise or like low volume, I guess,
and touch script has a lot more like punctuation to it,
and Rust has more punctuation. I don't think Rust or
typescript are ugly, Like they're both very readable. They're just
you just have to have a lot more like the
(20:36):
dense they're just dense languages.
Speaker 4 (20:38):
Oh no, I think we should stick with that because
it makes a great subtitle for the podcast. Is you
know once it again typescript, It's nowhere near as ugly
as rust.
Speaker 1 (20:45):
And that's it right there, not as ugly as rust.
We should just call it is typescript code ugly. Just
I think it's like bait title right there. What you're
used to right like, you're not used to list list
could be very ugly.
Speaker 4 (21:01):
All yeah, I think you can. There can definitely be
some readability issues when it comes to generics, and I
don't think any language that supports generics has actually solved
that challenge. But generics are incredibly important in retaining the
type safety of your components or whatever you're you're using.
So have you seen folks maybe almost go too far
(21:24):
with generics. I mean I've definitely seen that. As another complaint,
which is people saying, oh, you know, it gets really complex.
Speaker 3 (21:31):
I would say we have we don't have a ton
of generics. We have a lot of intersection types, and
we've had typescript yell at us that the type is
too complicated. This came up when with our like main
event payload if you include all of the properties types
trips like no, I don't want to really, I've never
seen them. Yeah, Or that's another one we had was
(21:52):
the top level form like form input, where you can
push a type as a string, and then you can
get to all of the various input types in that
we have in century. We were just trying to like
intersection all of those types of like union, all of
those different formats together with a discriminated field and a
certain point too is like Noah, I don't want to
do this, Like there's too many conflicts. Wow, type it's
(22:14):
too big, please stop.
Speaker 4 (22:15):
WHOA, I've never seen that.
Speaker 3 (22:19):
It was not a good thing to say.
Speaker 5 (22:23):
I don't think we have a lot of generics in
our cult.
Speaker 3 (22:26):
Yeah, we have some, but not as not many, not
like there's not a lot of like three tier generics,
like the like generic of a generic of a generic,
Like we don't try just trying to do that.
Speaker 1 (22:36):
One thing I've noticed from doing this podcast is that
the people that struggle with typescript the most seem to
be people like library authors that have these like general
purpose APIs, because those are the ones that are really
hard to configure, like if you're the person that's in
charge of making the types for like reactor or like
some of the libraries you were speaking of that had
(22:58):
for support, I imagine part of the reason why they
have pre support is that they have to get into
like crazy levels of like generics and intersection types because
they're kind of designed for general purpose use. So that's
where I think some of the struggles with typescript comes in.
But the thing is like in your average app, even
like big apps, like the ones you're working on, like that,
those are like fringe situations I feel like, because I mean,
(23:22):
most of the time the types you're dealing with while
you have objects to raise strings numbers, right, you're you're
not doing anything like crazy, And it sounds like that's
sort of the case with what you've been working on
as well.
Speaker 3 (23:35):
Yeah, I would say, like for a lot of like
web applications, you're dealing with like API responses and then
converting those around like munging that data and then turning
it into into use state, right Like, so I would
completely agree that you're not dealing with the crazy generics,
I would say, yeah, And I think you're respont on
with like the library the library author part, Like, especially
(23:55):
if the library started off as as a JavaScript library
and then was converted to typescript. I think that's where
you really run into it because they've leveraged the dynamic
properties of JavaScript and like the ability to be very
polymorphic on anything and not kind of bite someone they
try and turn into the typeescript. Yeah.
Speaker 1 (24:11):
I think it was last week. Week before, we were
talking to an author of a form library and they
were relaying horror stories of like it sounds like you
have a similar experience as well, Like they had form things,
but forms can contain all sorts of types, so they
got into some insanity in terms of defining that.
Speaker 3 (24:31):
Yeah, I could see a form library being really hard.
Speaker 5 (24:34):
Yeah.
Speaker 4 (24:35):
One of the nice things about that though, is sometimes
you can kind of contain that in insanity. If you've got,
for example, a set of shared components, like the button
that you're using everywhere, right, the type definition of a
button might be a little bit complex because you might
be bringing in like detailed HTML props, which has a
really weird complex signature, but you want to get all
of the extra types for a button and you don't
(24:57):
want to define those yourself. So that's actually really nice.
But the complexity is sort of contained within that that
that library of your your share components, and then as
as a user, right, you just pull you just import
button and the next thing, you know, you get hinting
for on click and everything just works, and so that's
kind of nice. And sometimes, you know, you can hide
the complexity a little bit of the of the typescript stuff.
(25:18):
It's not in your face like all the time. I
feel like you get tuk with like well designed libraries. Yeah,
but it is tougher, I guess for older libraries that
were written in a style that was less kind of normalized.
Maybe you know, you have to start using some of
the weirder features of typescript to deal with that, like
function overloading, which I don't even think people know exists
(25:40):
inside typescript, but actually it does and you can use it.
Speaker 3 (25:43):
We had to use it.
Speaker 4 (25:45):
Oh there you go, Okay, you know when you need it.
It's actually really handy, but it's a it's a weird implementation.
It's not like C sharp or C plus plus or Java.
It's a sort of it's it's just kind of like
multiple signatures for actually what's really just one function.
Speaker 3 (26:00):
But to use a lot of type guards to break
down our unions too into those. Yeah, those are some
of the like the weirder types of stuff we have
to use. Was function overloading, a lot of like type guards,
custom type guards and big unions and intersections.
Speaker 1 (26:14):
Cool nice, So one thing it'd be fun to talk
about because I'm I know we have a lot of
listeners that are working on similar types of apps, right,
large projects that have been around for a while, and
that they also have a laundry list of things that
they want done, whether you know, they want to be
using hooks or they want to be using typescript or
whatever the case may be. So I'm curious, and we
(26:37):
did discuss some of this, but I'm curious if you
have any other advice for convincing like management that like, hey,
like this is a worthwhile effort, because I know that
can be a struggle for a lot of people to
get time sort of approved to do this, and then
also like seeing these projects through, because not every large
scale effort like this ends with one hundred percent conversion
(26:59):
and success, right, So it's kind of impressive that you
you push this to the finish line. So I'd be
curious if you have any other advice in terms of
how to make that sort of thing happen and how
to see something of this scale through.
Speaker 2 (27:12):
So how to convince management to adopt type script. I
would say that only the possibility to catch errors on
the compiled times.
Speaker 5 (27:22):
It's amazing, you know, So this is amazing.
Speaker 2 (27:26):
Also we could reduce the need for API documentation because
type script it self self explain everything the type and
also autocompletion. So I believe this type script the team,
it's faster, the product productivity is faster than usual.
Speaker 3 (27:50):
Guess on the like how do you get it to finish?
We're really fortunate that we have we have like a
front end steering community, and the main contributors to the
Techica project were also part of that kind of steering committee,
and so we just had to kind of stick to
our guns, like no new big projects until this one
is finished. And towards the end of the project, we
(28:13):
were kind of like every week kind of asking people
like how many files are you going to convert? People
would volunteer like convert a couple, or I'll convert two
or I'll convert three, and then every week check in
with those people like did you get your stuff done?
What are you going to do next week? And that
helps kind of like gamify lightly people's desire to be involved.
I would say another thing that helped us finish was
(28:34):
that we did it in the long term, and so
we weren't rushing to meet a deadline. Instead, we were
just giving updates on like when we would finish. So
instead of it being like you must be finished by
December of twenty twenty, or your project is out of gas,
it was more like we're just going to do this slow.
We're going to do it the right way, like the
right way for us, which is like not slap any
on everything and do a machine organization. We're going to
(28:57):
take our time, going to do it, you know, so
that we have something that we're proud of when we're finished,
and then just give updates on when we will be done.
And then as long as people were meeting their project
delivery like deliverables, the front time folks were able to
focus as much as they wanted on tuch script. That
was the kind of like their B project was converting
to touch script, and all the managers, like all the
team managers knew about it, all the engineering managers knew
(29:19):
about it, knew who was contributing to it, and so
they were kind of like on board, like this is
this person's be project.
Speaker 1 (29:25):
Yeah, I think all that is great, Like I like
Priscilla's points of proving to management. It's like a lot
of those points you made were really about proving that
this is going to be long term a net positive right,
like well, like the fewer bugs and more productivity will
make this time like pay off and the long run.
And then I also like the points just in terms
of keep seeing this through to the finish, like the
(29:48):
accountability bit, like having someone that's in charge of the
project that reaches out and forces people to say, I'm
going to do this and almost gamifying it a little bit,
or at least like holding people accountable so that there's
that constant update, like it doesn't get lost because I
know what, I've been involved in projects like this before.
(30:08):
Sometimes it's going well, but then some big feature comes
down from business or some big bug happens, and then
all of a sudden, like this thing that's very low
priority gets sidetracked sometimes to never reappear. So I think
having like someone on it and someone constantly checking in
through all of that can make a big difference.
Speaker 6 (30:30):
Yeah, I'd also say another thing that helped us was like, yeah,
constantly checking in, constantly double checking, and then also making
sure all the new code was written in touch shriped
was a big monumental thing to get done, was like
convince everyone that touch script is worth learning and then
also get them to stop writing JavaScript, because if we
(30:51):
never stopped writing.
Speaker 3 (30:52):
JavaScript, we would never finish. And so for us to
be able to complete, like and to prove that the
tuchrip project was going to actually finish both through ourselves
and up management, was to get everyone to stop writing cabscript.
And we're way past that point now, but that was
a that was a key turning point, was getting everyone
on board.
Speaker 4 (31:08):
Yeah, so that actually leads a question, So would you
personally ever want to work on a streat JavaScript application?
Speaker 3 (31:15):
Again, Yeah, it would. It's not as good as like typeshrip,
Like you get a lot more benefits out of having
it in type strip. And if I was to start
a new project, I would definitely start it in typescript.
Sure how about you, Priscilla?
Speaker 5 (31:26):
Yeah, me too, Me too.
Speaker 2 (31:27):
Last week we had again heck quick and I work
it on two projects and I used typescript. So I
started from scratch and I decided to use tapscript because yeah,
I really like it.
Speaker 4 (31:40):
And I think that's something again with talking to management, right,
hiring is always an issue. It's a very hot hiring
market right now. People can move between jobs very quickly,
and people are evaluating what they're going to be going into.
And if you're saying, hey, you know, we're doing React
circa twenty fifteen in JavaScript, come on down, we were
(32:00):
going to be like, I really enjoy you know, typescript
and hooks. I mean Rizilla's like, yes, hooks, you know,
so you want to work in a modern code base.
And I think that's the thing, you know, when you
talk managements as a selling.
Speaker 3 (32:15):
Point, Yeah, for sure, And I think that was something
our like our vps knew as well, Like the VP
that we were working with then is like very much
understanding of that. People want to be on the vanguard
and want to be working with new stuff when Century
as a company does that a lot as well. So
I think that's an important point to make if you're
in an organization where that isn't part of the company's culture.
Speaker 2 (32:38):
I'd like to addit that we are always trying to
introduce new technologies and for example, now we just introduced
reactive Testing Library, so we are planning of converting our
tests to from ENSIGN to reacted Testing Library, and that's
pretty cool.
Speaker 1 (32:55):
Yeah, I was just going to say that the it's
a really good point that like sometimes like you, you
are not in control of your management and your your
team or like entire organization. And not to put this
to blunt, but I mean, if if your organization is
really obstinate, if your managers aren't great, you know, it
is a hiring markets. You know, there are other decent
(33:17):
teams out there. So if you really are like super
super struggling and working on stuff you're not interested in,
maybe you consider other things as well, because they're everybody's
got like old code you know, bad code bases and such.
But having a culture that encourages that sort of thing
and allows you to you know, ramp up over time,
I think is a really big deal.
Speaker 3 (33:39):
Like century is an old code base, it's coming up
on eight nine years. But at the same time, we
also like to fix it and see the value in
investing it and making it current and like keeping it
up to day. Like on the on the not front time,
we've just finished like a humongous amount of Python upgrades,
like from Python two to Python three, from Jengle one
to six, all the way to gay Go two point two.
(34:00):
Like that's been eight months of work, and all of
that is to get us up to a new version
of Pythons so we can get performance. Actually the main
driver of that.
Speaker 1 (34:08):
And I have to imagine too, like like pushing those
things to production is immensely satisfying as well. Like it's
it's like the same sort of things that like when
you finish. Like for me, it's like if I'm I
like if I mow my lawn, Like there's that moment
like when you're done, Like I hate mowing my lawn,
But at the same time, when I'm done, like looking
out over it, it's like, yeah, I crushed that, Like
look how good that grasped.
Speaker 4 (34:29):
Yeah, I was gonna say, like that last puzzle piece,
you know, when you got a thousand piece puzzle. I
can only imagine like that last JSTS file, right, the
last commit was like, yes, we did it, you know
as a team. You know, if you're in slack, you're like, yeah,
that last little.
Speaker 5 (34:45):
Bit, Yes, we celebrate it.
Speaker 4 (34:47):
I want Yeah, nice, Priscilla, was that your your file?
Who was the last person to actually like do the
last file?
Speaker 3 (34:53):
I think it was vin a right of us. I
think it was one of the other one of the
other folks.
Speaker 2 (35:00):
We let the lashest files, the most complex files.
Speaker 5 (35:04):
To the end, and yeah, I can't remember the last
to us.
Speaker 3 (35:11):
Yeah, there's some like changing of tactics through it. It
was like start with the biggest, start with the files
that are important the most. Then start with the files
that are imported with the least because these most important
files are becoming annoying. And then it was like important
you do like one whole view tree. There was a
bunch of different tactics, but yeah, there was a bunch
of big rocks at the end.
Speaker 4 (35:29):
Yeah, you did mention that in the article where you mentioned,
you know, there's sometimes you work from the core and
other times you work from the leaves. And that's actually
a very interesting question out there is, hey, we get
the typescript is awesome, you know, how do we go
and take our twenty thousand and thirty thousand file project
and bring that over? Like, what what are some good strategies?
And I don't unfortunately I think the answer probably there
(35:51):
is It depends terrible answer. Yes, yes totally.
Speaker 3 (35:58):
I would say, like, try a bunch of different approaches
and see which ones help you get progress, Like the
if your goal is to convert that twenty thousand file project.
Over do the things that are going to help you
get progress, like if you're going to measure progress on
number of files, aim for like choose whatever tactic is
going to yield you the most amount of progress at
the beginning, so you can get a good foothold so
you can get people invested and get people ready to
(36:22):
help out.
Speaker 4 (36:22):
Yeah, you want to finish up on that. I feel
like you left out. Okay, that's cool, all right, awesome,
very cool. Well this has been really really fun. I
think now is the time to get into this week's picks,
So mark one, lead us off on your pick for
this week.
Speaker 3 (36:38):
Sure, yeah, I would say the new version of them,
NEOHIM zero five has native language server support, so you
can configure neovim with LUO, which is nice. You don't
have to use vimscripts, which is my least favorite programming language,
and you can use LUI descripted and then the native
LSP look looks really good and works really well. So
check out new of them and some of the new
(36:59):
native LSP. Very cool about you, Bricella.
Speaker 5 (37:02):
Oh I think so?
Speaker 4 (37:04):
Yeah?
Speaker 2 (37:05):
So that is this library D and D kit. I
really like that one. It's They have an amazing documentation.
It's very easy to customize and yeah, it's amazing the library.
It's very light as well.
Speaker 4 (37:19):
What did you do? D and D kit? Yeah, it's
not disturbed.
Speaker 2 (37:22):
So recently we had to introduce dragon drop in century
and we founded this library and it's amazing.
Speaker 5 (37:31):
We are really enjoying using it.
Speaker 3 (37:33):
Cool.
Speaker 4 (37:34):
Yeah, there's so many D and ds. There's dragon draw
theres do not disturb Dungeons and Dragons. It's very very popular,
you know, three letter combination.
Speaker 3 (37:43):
I guess.
Speaker 5 (37:44):
Yeah.
Speaker 4 (37:45):
And for my pick, I am going to go with
a bit more metaphorical. Just the power of saying no.
I know that we just we talked a little bit
about burnout in the beginning of this episode, and the
I find the major key for me to avoid burnout
is to just say no, you know, reduce the amount
of stuff on your plate. You get less stressed out,
(38:06):
and you just feel better about the attraction you make
in a day by saying no to a lot of
these small projects, even the ones that you want to
do for yourself. So I think that's really important.
Speaker 2 (38:16):
I think here, I read a book about it, but
I can't remember the title. How to give a sheet.
I don't I cannot remember the time, but it was
exactly about it the.
Speaker 5 (38:29):
Power of no.
Speaker 4 (38:30):
Yeah. I know we all want to be nice people,
we all want to help out our friends and all that,
but you know, you can just get snowed under on
all these things, and work is just work alone is
very stressful. So you know you don't want to take
on too much. You want to live a happy and
healthy life and you know, go out and do kayaking
or whatever you enjoy. So take that time and be
(38:51):
confident and say no, yes, definitely, TJ, you want to
take us out.
Speaker 1 (38:55):
Yeah. I will not be picking comcasts this week, as
I hope this doesn't come through the editing, but my
Internet has been catastrophic here lately. But I will pick
a window manager for the Mac called Divvy dvv y,
one thing that I am shocked the Mac still doesn't
have it built in, just a way of snapping a
window to a certain part of a screen. It's crazy
(39:17):
to me that you have to like look out for
a third party app for that. But Divvy is a
pretty decent one if you don't already have one, and
I'd recommend it, especially if you have like a widescreen
monitor just because being able to dock windows is super
nice and super time saving.
Speaker 4 (39:32):
Absolutely thanks for that. I'll check that out all right. Well,
thank you so much for showing up. That was an
awesome episode and we'll see you next week.
Speaker 5 (39:39):
See
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
The Breakfast Club
The World's Most Dangerous Morning Show, The Breakfast Club, With DJ Envy, Jess Hilarious, And Charlamagne Tha God!