S9E8 | TypeScript: the types, the mistakes, and the growth| Jan-Niklas Wortmann & Chau Tran - The Angular Plus Show

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
M hm.

Speaker 2 (00:08):
Welcome to the Angular plus Show. We're app developers of
all kinds share their insights and experiences. Let's get started.

Speaker 1 (00:21):
Welcome everyone to another episode of the Angle plus Show.
This time I'm just here with my lovely co host,
and therefore this kind of makes us both guests. I
guess in a way, how are things.

Speaker 3 (00:32):
Going, show?

Speaker 4 (00:34):
Things are going pretty well. Enjoying the spring weather, right
you seff rain minus the rand. Yeah it was rainy,
ill look crazy in the past couple of days here.

Speaker 1 (00:49):
No, it was like last week was like terrible here,
and now it's finally starting to be nice, and I'm like,
this is this is good. I want to do yacht work. Now,
are you a yarch work person. You don't strike me
as a yartwork person. So I do what I need
to do, what you were told to do. Is that
what you said?

Speaker 5 (01:10):
No?

Speaker 6 (01:11):
No, No, I got, I get eyes, I get.

Speaker 4 (01:14):
I saw I saw too looking at the yard. Then yeah,
I do the minimum, the bare minimum, gotcha? Yeah?

Speaker 1 (01:23):
Well, I hated yardwork growing up. My parents forced me
to the yard work. But now with like having my
own house, I'm like going full blown German basically like
using like a scissor to cut my grass, and like
what that's exaggerating, But I do enjoy yard work. It's
it's a good balance from like doing computer stuff.

Speaker 3 (01:42):
So it's it's nice. I like it.

Speaker 6 (01:44):
Yeah, I mean I have.

Speaker 4 (01:47):
The same long mower ever since I moved into this house.
I never shopened anything. I never changed the oil springtime
coffsch that's it.

Speaker 3 (02:02):
It still runs now, never change running system.

Speaker 1 (02:06):
I guess, Okay, we're not here to talk about lawnars,
even though.

Speaker 3 (02:10):
That would be hilarious.

Speaker 1 (02:13):
Before this episode, we sat together, We're like, well, what
should we talk about?

Speaker 3 (02:16):
And we had a couple of good ideas.

Speaker 1 (02:18):
And the thing that I like the most that you
suggest so, was you watched a couple of talks recently
on YouTube that I think had very interesting statements in
it that I would like to discuss with you. So
talk me through them again so that I actually remember.

Speaker 4 (02:34):
All Right, So the first one, I guess we can
shovele the order around a little bit.

Speaker 6 (02:39):
I actually kind of.

Speaker 4 (02:40):
Want to to talk to discuss about just communicating in types.

Speaker 6 (02:45):
Actually, let me share a link, yes, so that we
can put in the show note communic cave. If I
can type in type.

Speaker 3 (03:00):
Go to.

Speaker 4 (03:03):
By Chris Jenkins. All right, where is zoom?

Speaker 3 (03:10):
Probably not the Chris Jenkins, the football player. I guess
I have no player.

Speaker 1 (03:18):
Well I looked up Chris Jenkins, and a football player
from the Cincinnati Bengals came up.

Speaker 4 (03:25):
Oh uh engineer, engineer, Yeah no.

Speaker 1 (03:32):
This looks slightly different. Okay, okay, So what was the
talk about other than that? It's talk called communicating on types,
he said, yep.

Speaker 6 (03:43):
So, uh, this high level.

Speaker 4 (03:49):
A couple of sentences summarize is this talk emphasize is
the importance of your of the types that you have
on your application, the data type uh data as in
your your your your business domain data like if you're

(04:11):
dealing with like any transaction, if you have any catalyg
transactional systems you would deal with like product order I
D like uh uh invoice I D things like that,
and how to how to communicate uh to out developers,

(04:31):
to to out.

Speaker 6 (04:32):
Engineers using types.

Speaker 4 (04:35):
So that's data types and then also uh, the talk
also mentions about the importance of your function types signatures,
because I mean, applications operate on functions, so if you
are crafting your functions, pay attention to your types signatures.

(05:01):
Of what the function accepts, what the function provides. Then
you can convey a pretty good summary of your of
your business, your application, business domain to other people without
them having to dive into the implementation details of the application.

Speaker 1 (05:22):
There's because I think the talk is more abstract. It's
not necessarily tightly related to typescript. But that's the only
thing that I can.

Speaker 4 (05:32):
Interestingly, interestingly enough, tapes script was not mentioned at all. Okay,
so but yes, we can absolutely applied the concept from
this talk to tip script without any problems.

Speaker 1 (05:48):
The thing where this where I can see the point
made that some of the language features that typescript has
allowed to be more expressive than just like to some extent,
act as a documentation over actually just like a functional representation.

Speaker 3 (06:05):
What do I mean with that?

Speaker 1 (06:08):
You could have thought that I prepared something right, like,
I seem very educated on this topic right now. So
the thing that I always like and that I actually
do is I use friended types a lot, right, So
say to one more time branded types. So instead of
just having an ID that is off type string, I
would say I create a user ID so that I

(06:30):
knew a user always has a user ID.

Speaker 3 (06:34):
The same way to some extent. I like type aliases.

Speaker 1 (06:38):
So if I as a super easy example, and I
would probably not do it this way, But if I
want the function to just take prime numbers, you can
have a type alias that is called prime number, which
is still off type type number, but with a type
guard you could declare that it's.

Speaker 3 (06:58):
A prime number, right, gotcha?

Speaker 1 (07:01):
Okay, And this way you can be very expressive in
the functionality and the context of your type.

Speaker 4 (07:11):
Ye.

Speaker 1 (07:11):
One thing I always keep going back and forth on
that I think is somewhat related to so how.

Speaker 3 (07:21):
Narrow do I design my functions? For instance, if I have.

Speaker 1 (07:26):
A function that cold lock in, right, and that function
takes use the name and password, so would you just
say use there? It takes two parameters, use the name
and password, and they are both strings. The other thing
you could do is that they For instance, you could
use pick on the user object or user type and

(07:50):
take out the username and password property out of those
and declare a new object out of that, for instance.
So how much do I reuse those types? That's something
that I always can going back and forth, because on
the one hand, it's unlikely that the type of your
username and past word changes.

Speaker 3 (08:05):
On the other hand.

Speaker 1 (08:06):
If you be that explicit with it, the context of
what you put in there is very very clear. You
wouldn't try to authenticate and technical account with that function.
You will always use that just for a user. So
you are you're a type script nerd. I know that,
uh so, so how do you approach that?

Speaker 4 (08:27):
I would probably just stick with username string, password string, honestly,
because one that there's this lockin function and like the
nature of the functions or the yeah, the nature of
the functions of functionality is in in is user facing.
So anything that anything user facing inherently would have a

(08:55):
more broader input types because like the can they can
they can literally put in anything, right, we can.

Speaker 6 (09:03):
We cannot.

Speaker 4 (09:05):
Prevent them even though we say we say the the
parameter name as username password, they can put in password
and use the name the orders right, or we say
the function is like redirect and they passing the URL.

Speaker 6 (09:23):
No, we cannot. We cannot stop.

Speaker 4 (09:28):
Them from inputting something that is not an ural or
an incomplete ural, or they try to be uh complete
with it's just as wlah the four yur right, So
things of that nature. Thinks of that, like the use
of facing natures, I would keep as broad as possible

(09:48):
or as broad as ease without trying to narrow them.

Speaker 6 (09:52):
I think that's also conveyed.

Speaker 4 (09:54):
To to the people that read the code too, is
that if we are on the same page, if we
have like the same mindset of looking at types and
this is how we communicate in types, and the the
next person is gonna look at this like these functions
that accept string but then returned a narrow type of

(10:14):
Like so so let's say lock in hm, you lock
in uh, you passing us an aim string passwords string,
but then you return like an okay result or an
error m hm. Right. That tells me that, oh, so
this function actually being grafted carefully, but with the input

(10:35):
type still being broad. It means that there must be
a user uh facet in here, like the user facing
facet in here, something that the user can input. So
I think that's that's that's also conveyed the intent functions.

Speaker 1 (10:55):
So if that is your statement, that would basically though
mean also that you're a massive fan of type aliases.

Speaker 3 (11:05):
What do you mean?

Speaker 1 (11:06):
So if you're you're trying to convey intent with your
function or with your types and any it's not a
necessarily very conveying type. And that's just an example. String
is the same. String is also very like super broad.
It can be anything. Mm hmm.

Speaker 3 (11:29):
That is in quotes.

Speaker 1 (11:30):
But if you're intended to convey intention, wouldn't it make
more sense to say type, my super fancy type is
equal to string.

Speaker 6 (11:42):
I see what you're saying.

Speaker 1 (11:46):
Why I don't have a good example on top of
my hand my head, because I'm not that prepared.

Speaker 4 (11:53):
Now the thing is uh so so so again, I
think I don't think I'm that extreme in terms of
like using type alias to convey.

Speaker 6 (12:05):
Intent in that sense.

Speaker 4 (12:06):
So for simple, when you say, let's say that for
the lockin function, use a name password, certain step like
use the name string, passwork string, something more expressive would
be type use a name, type, use a name, eCos
string type passwork equos string.

Speaker 3 (12:26):
Uh huh.

Speaker 4 (12:27):
That's also already conveyed by the parivate name though, right
if we look at the functions.

Speaker 1 (12:34):
So true on the other hand, like without saying certain
without saying names, but certain tools just show the type
and not the parameter name.

Speaker 6 (12:44):
I got ya. Yeah, that can happen as well, yep.

Speaker 1 (12:49):
So I mean that's one of the reasons why this
configuration object pattern exists because the tooling is lacked or
can be lacking.

Speaker 4 (12:59):
Mm hmmm, sure. Personally, I don't type alias primitive types
like that.

Speaker 1 (13:08):
I think for a password, I would probably use an
alias because that also more better allows for validation rules.
I think for password, I would probably do it. For
user name, probably not unless they follow like a certain
format where you could use like a stringles type for instance.

(13:31):
But then also I would need to have a benefit.
Most of the time you just display use a name.

Speaker 4 (13:37):
So yeah, now no, I think I still I still
stay on the hill of keeping it broad a string
because when you say so, let's let's let's use the
argument of.

Speaker 6 (13:54):
Making the type.

Speaker 4 (13:55):
The passwords, the password type expressive, as in including the
validation rules for that password in the type. I'm not
saying possible or not possible. I'm just saying, like the intention, right,
and let's assume that it's possible to do so.

Speaker 3 (14:11):
I think it's you can just do a type card
right like.

Speaker 4 (14:14):
Yeah, But then also it is it is also tricky
because when we say when we have like a user
facing functions functionality like that, we have to rely on
the user interface and that user interphase to me is
an external system to our application, which means that that

(14:36):
user interphase regardless like either on the phone platform or
the web browser, they might not have the same capability
to express that in terms of accepting inputs.

Speaker 1 (14:49):
Okay, but if we stick with a typescrit example, you
can very easily say, Okay, my user has a password,
and that password is a type password, and to make
sure that my use or is an actual user, I
take a string from the password field validated that it's
an actual, valid password. And this can also include the
asynchronous process of logging in and authenticating, and at that

(15:12):
point I know it's a password. So I think we
need to if we're talking about this, then we have like,
like what you consider external system, I consider more like
a boundary in that sense of course, of course, yes,
And in this context we're talking very broadly because at
the end of the day, everything in the browser is
a string most.

Speaker 3 (15:32):
Of the time, but in our application not everything needs
to be a string.

Speaker 4 (15:38):
Okay, yeah, absolute look like so I think we kind of, like, uh,
discuss a little bit about that function types, like trying
to give it a little bit more thought on the input,
what the function accepts and what the function returns.

Speaker 6 (15:55):
So now let's let's take let's take a step.

Speaker 4 (15:58):
Forward and move into the return type or the data
type that these functionalities provides.

Speaker 6 (16:07):
Back to the invokers. So what do you think about h.

Speaker 4 (16:13):
Expressing every possible cases on the type level? What it
means that, uh, what it means is that success cases
and error cases as well. And that's so interesting this
and this is also like kind of like a seguay

(16:35):
to dive into throwing or returning error.

Speaker 6 (16:37):
So that's exactly the rabbit hole that we were about the.

Speaker 1 (16:42):
Inter Yeah, so if we're making that argument, I think
errorss type if you go that way, is a.

Speaker 3 (16:52):
Very strong architecture pattern.

Speaker 1 (16:56):
It enforces a very high level of runtime safety at
the end of the day. The thing is, the implications
are so massive because the way you write code is
so different. The thing that I like about it is

(17:16):
that I also are strictly typed, which is the thing
that the browser has never heard of. The fact that
we as developers got excited once errors weren't any anymore.
But unknown in typescript is already telling enough that there's
an issue. Funny enough, I know there's a language server

(17:41):
that does static analysis to see if your methods that
you call throw errors and therefore give you like a warning,
which I think is an interesting approach. But on the
other hand, there are so ridiculous way how you can
throw an error, and an error doesn't need to be
an error typescript or JavaScript.

Speaker 3 (18:01):
It can also just be you can throw a string
mm hmm.

Speaker 1 (18:06):
So static analysis I think just gets you this far
with errors. So therefore, in general, if you have a
mature team that knows what they're dealing with and the
implication that has on their code and the level of
details they need to write with that, I think this
is a good approach because it implicitly forces you to,

(18:26):
for every scenario think each error case through, which is
one of the things that I always liked about RHS,
where it's like, okay, what if this part throws? What
if that part slow was, if this throws? What if
this outer with those before this inner observers?

Speaker 3 (18:39):
Amit something?

Speaker 1 (18:39):
That's one thing that I always appreciated. Having that said, though,
and now I contradict my own statement, I'm not a
fan of explicitly typing return types.

Speaker 4 (18:54):
I see no, no, no, no, no, I'm not saying explicitly well, yeah, yeah, exactly,
So to have sent you would Yeah, I have personal
experience with this as well. Some of you might have known,
some of you might have not, some of you might
might have heard but didn't really care. Is that so
when when I first joined the nx cloud team. So

(19:16):
I joined Novel and I worked on the nx Cli
for close to two years and it got burned out
by the by the whole es M common jazz thing.
Oh my god, so it has to be put onto
the nx cloud team.

Speaker 6 (19:28):
So I joined the nx cloud team. And at the
time when I.

Speaker 4 (19:31):
Joined, we were in the process of migrating from Angler
to to Remix. But then the uh, the intermediate step
is to react rout first. From Angler react rout a
Remix And at the time, Remix was still pretty pretty
damn new, so I think it was at the point

(19:53):
at that point, Remix was just announcing their open source
and uh, they're free things like that. So Pantons are
pretty much non google able, right. So at the time,
we use a result pattern, a result type pattern, so

(20:14):
you have you return like an API success, API error.
You never throw things like that. But then as we
work with Remix a little bit more, we understand it's
pattern a little bit more and how it uses type
inference to get like loaded data and all that stuff.
Returning errors seems contradicting with what Remix kind of wants

(20:41):
or operates, because when you return something from your load
from your loader and you say use loaded data type
of loader, the return type actually inferred, right, So if
you return something some some like error cases, that's going
to propagate to your loaded data type as well, even

(21:02):
though you might not mean for.

Speaker 6 (21:05):
That error case is to be returned as the loaded data.

Speaker 4 (21:09):
Because you actually want to throw in that case because
AERRB boundary in Remix only gets rendered if you throw
error and not the current error.

Speaker 6 (21:22):
So there's that as well.

Speaker 4 (21:23):
And then what if you you redirect, because when you redirect,
you're not expecting that component, the page component of that
route to be rendered.

Speaker 6 (21:33):
But because return redirect affects.

Speaker 4 (21:36):
The type signature of the load of function, so now
you're like use loaded data type of FLADO is kind
of messed up and missing the information.

Speaker 6 (21:46):
So now is all throw redirect.

Speaker 4 (21:48):
If you have a redirect, you throw redirect.

Speaker 6 (21:51):
If you have an error that you.

Speaker 4 (21:52):
Want to show in an error boundary, you throw that
error if you want to render errors in light, you
return that error.

Speaker 6 (22:02):
So it's kind of like mix.

Speaker 4 (22:04):
And match different kind of patterns, not very consistent. So
six months later, after we first migrated to remix, I
proposed to my team that let's throw everything, all right, error,
throw everything, but we standardize. We normalize every errors back

(22:29):
into a top level NX cloud error. And there are
different types of errors as well that extends the next
cloud error like organization error, walk space era, work flow era,
run era, authentication errors, blah blah blah, all types, and
all of these errors will have medadata associated to them,
Like if you throw an organization error, I want to

(22:50):
know the organization I D for example.

Speaker 3 (22:53):
Yeah, makes sense, Well, it's working.

Speaker 4 (22:57):
Kind of okay until we get to we want to
be more aggressive with the aero boundaries in a sense
that so you know how.

Speaker 6 (23:11):
Route you have an air boundary at this boundary.

Speaker 4 (23:14):
If you don't have it, it would just propagate back
up to the parent and all the way up to.

Speaker 6 (23:18):
The root to the root route. So we want to
be able to kind of like.

Speaker 4 (23:23):
Pick and choose where we want to have an Arab
boundary to show it's like the information that is that
makes sense for the customers. But because we throw everything,
we don't have the type information of the throne errors.
So we kind of like have to guess what errors
we want to catch at this aerob boundary. So for example,

(23:43):
we have an organization details right, so we have like
an organization details Arab boundary. It makes sense to only
catch some sort of validation errors and organization errors outside
of that aero boundaries.

Speaker 6 (23:56):
But we have to guess.

Speaker 4 (23:57):
We don't have any help from the from the HIGHCO compiler.

Speaker 3 (24:04):
Can you not just do an instance off check?

Speaker 4 (24:06):
Basically no, no, Because arabioutrees are rendered both on silver
side and on the client side as well.

Speaker 6 (24:13):
It can be randomed.

Speaker 4 (24:16):
Okay, when it renders on the client side, it is
no longer that instance.

Speaker 6 (24:20):
It's just like a generic error.

Speaker 3 (24:23):
I see. Okay, it's also different.

Speaker 4 (24:27):
It's also different when you run in depth versus in
products as well, because in production they they remove all
kinds of information in your errors.

Speaker 3 (24:36):
I guess that makes sense.

Speaker 6 (24:37):
Yeah, so yeah, so.

Speaker 3 (24:41):
Now that topic. Sorry, then let me finish.

Speaker 4 (24:45):
Let me so, so so fast forward to now we
want we want to.

Speaker 6 (24:54):
Go back to returning errors.

Speaker 3 (24:56):
Okay, yeah, interesting, So.

Speaker 1 (25:01):
One thing that I spend a good on my amount
of time in my career early on. Particular is defining
rest APIs and there is you have to.

Speaker 3 (25:12):
Some extent that same argument there.

Speaker 1 (25:15):
Do you use HGGP as it's designed, meaning if you
have a good response you return a two hundred, if
you have a bad response you return in a four
hundred or five hundred, depending on what it is. And
I think there are valid arguments for both of those sides.
At the end of the day, I don't think those

(25:36):
arguments really matter as much as people like to discuss them,
because it's most of the time really like, okay, how
well can the team deal with those things? If I
look at it. For instance, with the argument that is
made for rest, right, you have the argument, well, if

(25:56):
you use nature rest, then you can use browser features.
So if you're, for instance, returning four or three not
four three is forbidden. If you're returning three hundred something
to redirect, the browser will automatically redirect you. If you
would just say two hundred and say hey, I want
you to redirect somewhere, you have to implement this yourself,
So there are arguments for that. On the other hand,

(26:19):
those defaults of the browser can also be somewhat annoying,
like you run into with every time a remix handles
an error, it's follows the information from that error. So
I don't think in most cases your case might be
a little bit special.

Speaker 3 (26:36):
But I don't think.

Speaker 1 (26:37):
I think consistency is really more important than like going look,
do I go left or right? As long as you
know I always go right now, I always.

Speaker 6 (26:45):
Go left exactly.

Speaker 4 (26:48):
Yeah, I think so too. I mean, just to how
did I right on top of your argument about the platform?

Speaker 3 (26:58):
Right?

Speaker 4 (27:00):
Yeah, I've been I've been beaten by the HDP status
uh as well because everyone has. Yeah, because like when
so so so when you read the wreck, is is
all good, it's all fun and game if your app
only has get requests.

Speaker 6 (27:17):
But then when you put.

Speaker 4 (27:18):
When you have like post requests in there and then
you read the wreck something, and then your post re
reruns or not or then or if you if you
read the rec and then you get requests for that
runs like what the hell?

Speaker 6 (27:31):
What so? Things like that.

Speaker 4 (27:34):
But but then but then on the price site, you
get to learn the platform, You get to learn your
HDP status codes.

Speaker 3 (27:42):
Good morning.

Speaker 1 (27:43):
Do you know that moment when your coffee hasn't kicked
in yet, but your slack is already blowing up with
Hey did you hear about that new framework that just dropped?

Speaker 3 (27:51):
Yeah, me too.

Speaker 1 (27:54):
That's why I created the Weekly Death Spur, the newsletter
that catches you up on all the web depth chaos
while you're still on your first cup. Oh look, another
anger feature was just released, and what's this typescripts doing
something again? Look also through the poor request and change
slot gramma. So you don't have to five minutes with

(28:16):
my newsletter on Wednesday morning, and you'll be the most
informed person in your stand up. Ah. That's better the
Weekly Desperate because your brain deserves a gentle onboarding to
the week's tech madness. Sign up at Weekly Brew dot
Death and get your dose of deaf news with your
morning caffeine. No hype, no clickbait, just the updates that

(28:37):
actually matter.

Speaker 3 (28:38):
Your Wednesday morning self will thank you.

Speaker 1 (28:41):
One thing I want to hook into in this whole conversation,
how do you feel about schema validation?

Speaker 6 (28:46):
I like it?

Speaker 4 (28:48):
You like it? I do like it, but I'm not
like like hardcore everything schema kind of thing. For example,
just for example again back to remix loader actions. So
loaders and actions. They get called by remix and they
get passed like a load of function arguments which has

(29:10):
the request itself, the context which is arbitrary data.

Speaker 6 (29:15):
And the proams. Now the praams.

Speaker 4 (29:20):
Isn't it is a record string string is a record
of string strength.

Speaker 3 (29:24):
That's horrible.

Speaker 4 (29:26):
I know, I know. But then I'm not going to
go out of my way to make scheme of validation
for the programs because with a like a foul based
convention of Remix, I know for sure that you're not
going to hit this rude if you're not going to
match that. So even if you say so, Let's say
I have a rouse of organizations slash organization I D,

(29:47):
slash workspaces slast workspace I D, right, my params objects
are going to have organization I D in workspace I D.

Speaker 6 (29:55):
I know that, I don't. I know that much.

Speaker 4 (29:57):
I'm not going to go out of my way to
make scheme of an aidations to make sure the params
has those feels. However, though, if you do organizations slash undefined,
last workspaces last undefined, and now I have to do
EVALI validation.

Speaker 3 (30:11):
On those, Yeah, yeah, what do you use for schema validation?

Speaker 4 (30:16):
I use forms mostly and form forms and such queries
because I want to convert those search qureers back into
the type like offset and things like that.

Speaker 3 (30:30):
Yeah, I like the idea of.

Speaker 1 (30:33):
If you have like a distributed system with different teams
to also validate, like hup API S wait. I always
had that that like you working like you're the front
end team and then you're intact with the back end
team and someone one way without saying names, provides data.
So having something like that that errors as soon as

(30:55):
possible can be beneficial for that. So I search the
situation if it in your if you're in control of
both of those, I would probably not deal and have
like the runtime cost of schema validation.

Speaker 4 (31:08):
Yeah for sure, Yeah for sure. Now I only use
scheme of validations if there's is uh, there is a
big risk.

Speaker 7 (31:18):
Of crashing everything data line, right, So I only do
that and uh, we try to keep the scheme of
validations as close to the request invocations as possible.

Speaker 6 (31:33):
So like so like things like in our.

Speaker 4 (31:35):
Data access like API layer, things that functions that talk
to the database, we don't scheme of validate as much.

Speaker 6 (31:45):
Don't you need to?

Speaker 3 (31:48):
No? No, that makes sense?

Speaker 4 (31:50):
Yeah, now, so again so so so I have another like,
if you want to talk about uh, the NX clown cobs,
which I mean, I think I can talk about it
without talking about the business logic inside of it.

Speaker 6 (32:04):
I can talk about it all day long, man, because.

Speaker 4 (32:06):
I made stupid decisions that I now regret it. So
basically every six months I look back my fuck.

Speaker 1 (32:17):
But honestly, I think, A, this is a sign that
you grow as a developer, So that's a good thing. Yeah,
And B it's also a sign that the code base
grows with those things, because if you're if you wouldn't
have those moments, it basically means that your code bases
ship the thing.

Speaker 6 (32:37):
The thing though the thing, I have a bad habit.

Speaker 4 (32:40):
So even though I recognize those things and I know
that it's kind of bad for the code base and
I want to change it, my bad habit is one
I it's hard for me to convince other people. So
I told you, I told you earlier before the show
that I'm not good at making decisions. What if so

(33:03):
for things that I'm not one hundred percent sure that
it's bad, what if it turns out it's not to be,
it's not so bad after all? Right, and then but
but then the second thing is that we like if
I don't or if I cannot do it in one
world soup there, it's hard for me to to do
it gradually.

Speaker 6 (33:22):
I when I can, when they when they are.

Speaker 4 (33:25):
Things that are more on the uh architect level type
of thing like if you change if you change this approach,
you change the entire code base basically.

Speaker 3 (33:36):
Yeah.

Speaker 1 (33:37):
Yeah, I think it's a little bit difficult in your
particular case working at an x RA, like I assume
at least I would have that to some extent, I
would suffer from like imposter syndrome because everyone is like
super smart and like a great engineer, so you always assume, oh,
everyone else is smarter than I have.

Speaker 3 (33:55):
Yes, I'm not saying you do that.

Speaker 4 (33:58):
That's no, no, no, I I I I feel the
same way. I think that's why it's hard for me
to kind of like, should I like raise this flag,
you know, should I raise this flag and tell everybody
what we've been doing?

Speaker 6 (34:11):
Sucks?

Speaker 1 (34:13):
Yeah, I think that the way I approach those things,
I would if I personally right, if I would notice like, okay,
I don't like those things that we have, I would
try to because I personally often have the different situation
where I think my opinion is so much more right
than everyone else. So therefore I often try to take

(34:35):
a step back and be like, Okay, what are the
problems that I have with the current approach?

Speaker 3 (34:39):
Right?

Speaker 1 (34:39):
Because this way you built like common ground if and
you also have like an early conversation point. If people
don't agree with those problem statements already, or they see
different problems, then maybe your approach might be wrong. Right,
But if you say, okay, you see problem X, why
and this is why all this sucks? What you're doing
right there? It doesn't scale, it's cumbersome, it does the

(35:00):
test well like ideally as objective as possible, right, not
like I don't like it.

Speaker 3 (35:04):
It looks bad.

Speaker 1 (35:06):
And if then people agrees on that, then you can
be like, okay, I think about we could what do
you guys think about approach x Y. Approach x Y
doesn't cover problem one but takes the box for problem two, three, four, five, six, seven.
So this way you already have like some kind of
like checklist. Does your solution cover the problems statements that

(35:29):
you identify, And.

Speaker 3 (35:31):
This way you you.

Speaker 1 (35:33):
Go away from this feeling territory, the situation isn't good
and more of like, okay, how can I make things
more objective? And also it makes it more tangible to discuss.
That's how I would approach us.

Speaker 4 (35:46):
Yeah, now so I think, well, I think this is
very situation noise is very on a team basis as well.
Oh well I'm not I'm not saying my team at
uh like at an exclaim.

Speaker 6 (36:00):
Now is this that they amazing?

Speaker 2 (36:04):
Right?

Speaker 6 (36:04):
Or we all care.

Speaker 4 (36:05):
About the product, But in order to have a discussion,
you have to have people that care enough.

Speaker 3 (36:14):
Oh that that is true? That is true?

Speaker 6 (36:18):
Right, that is true. Yeah.

Speaker 4 (36:20):
And so let's say that my team, my team, we
are like the front end team, but more like remixed
team kind of thing. So if I raise something right,
it's very less likely that I receive a meaningful discussion
out of it most of the time because how small

(36:43):
my team is and how people have different priorities.

Speaker 6 (36:47):
And that's not saying that they don't.

Speaker 4 (36:48):
Care or not, but it's it's most of the time
is hey, if you see it's wrong, then go go
go go do it, go fix it. Yeah okay, and
I ended up not doing anything.

Speaker 1 (37:03):
Yeah yeah, interesting, Yeah, yeah, I don't think I. I
don't think I had that particular context. I had certainly
the situation where it was like, Okay, I care about
things and other people don't care about it, but it's
like small enough that I can just do it and
people will be okay with it. Now at Jet Brains,

(37:25):
I have more the problem. I'm not super familiar with
the code base, so if I see an issue from
like a user perspective, I need to figure out who
is responsible and be.

Speaker 3 (37:33):
Like why why.

Speaker 1 (37:35):
So one thing that I still buffles is still mind
blowing to me is like we have different keyboard shortcuts
for super small things between intelligent WebStorm, So the same
keyboard shortcut does a slightly different thing in intellig than
it does a WebStorm, and it's like most of the
time that's for like nine percent, that's not the case,

(37:57):
like the same keyboard shortcut, but some things just grew
his so they have like different keyboard shortcuts. It was
something abound multi select like multi cursor selects.

Speaker 4 (38:06):
I'm like why, I see yeah.

Speaker 1 (38:11):
And so I'm just like the super person don't know
the details.

Speaker 3 (38:15):
So I need to figure out, Okay, who's responsible for it?

Speaker 1 (38:18):
Why is it this case and is it worth changing
because is it just bothering me as advocate who jumps
between seventy project products and different versions of those, or
is this really.

Speaker 3 (38:28):
Like a pain for users?

Speaker 1 (38:32):
So I had that situation, but I don't think I
had the situation where it's like, yeah, people are not
involved enough to have opinions, if that's an accurate way
to describe it, because I see what you're saying with
it is that they care.

Speaker 3 (38:50):
It is just it doesn't tangent. I don't know.

Speaker 4 (38:56):
Now the thing is my problem. Let's just say that
my problem affect them, you know because if if if circle, Yeah,
if we changed so, if we changed that kind of
like approach that we write code, then that affects them

(39:20):
right on the day, on the daily basis too. So
that's that's also what's like, That's that's also what's scary
to me, is that how can I make this person's
live better not worse? Right now, back to that topic,
back to the topic of surfacing errors. What do you

(39:42):
think about effect affect?

Speaker 6 (39:44):
Yes, have you heard about it?

Speaker 1 (39:45):
I have heard about it. I have I reached out
to the Greater.

Speaker 3 (39:51):
And want to talk with him.

Speaker 1 (39:53):
I haven't used it, so I don't have strong opinions,
all right, I've not even detailed looked about. It popped
up in my timeline every so often because people compare
to our excess, But if you look at it for
more than.

Speaker 3 (40:02):
Like a minute, you see that it's not really related.

Speaker 4 (40:06):
Yes, it is not really related. But but I don't know.
If you've seen my tweets the other day, like a
couple of weeks back, that that's I was like kind
of like just looking into Effect because I like the
way that they surface the errors types.

Speaker 3 (40:24):
Mm hmmm, oh that's true. They have strong error types.

Speaker 6 (40:27):
Right, yeah, So.

Speaker 4 (40:31):
I'm like, would this makes sense for hour back in,
for our remix back in? So I looked into it
and I tried to study it. You know what helps me?

Speaker 6 (40:43):
My RX chess.

Speaker 4 (40:44):
Knowledge helps me.

Speaker 3 (40:47):
Well, that's good.

Speaker 4 (40:48):
The first the first time I looked at Effect, like
way way way back then, like when it first kind
of like trendy, you know, I looked at it and
it threw me off immediately. When I when the example
is like console dot log capital k C Like, what
the what the hell is this?

Speaker 6 (41:08):
I just want to console log?

Speaker 4 (41:09):
Why do I have to do console dot log returned
that and then use that to run right, And now
I'm like, oh, it's lazy. So like if if we
look at if I look at it from the lens
of r ex just obsobos, then it makes a lot
more sense and it is.

Speaker 6 (41:29):
A kind of light. It's easier for me to accept it.

Speaker 3 (41:33):
Yeah.

Speaker 1 (41:34):
I the one thing that I didn't consider before with
our when we discuss how errors as types, how contagious
of this in a way, because if you have if
you use one function that returns two errors and then
you're working with that function, your new function basically could

(41:55):
potentially also return those two errors correct unless they're catched right.
So basically, like you at every given time, you need
to make this decision, Okay, do I rethrow this, do
I handle this? If I handle this, I have new errors.
So that's what That's one thing that I didn't even
consider properly before. Yes, you need to make this conscious
effort how to handle those errors, what to do with them.

(42:18):
But also if you don't do that, you basically just
end up with like, Okay, you're like, if you go
up the calls, like your method on the very top
could potentially return three hundred and fifty errors.

Speaker 4 (42:30):
Yeah, and I think I think now, I think, yes,
that contagious, and that might look bad from the surface.

Speaker 6 (42:39):
But that's the point though, right, that's the point of engineers.

Speaker 4 (42:43):
Look at engineers, look at this with three hundred errors types,
and if they're not, like, if they don't have the
tingling feeling like what the hell is going on here?

Speaker 6 (42:53):
Or what the hell is wrong here?

Speaker 4 (42:54):
And then there's something wrong with them, not the tools.

Speaker 6 (42:58):
Sure, yeah, it's not a personal feeling.

Speaker 1 (43:03):
I think that's a great analogy. And I want to
make a jump and stick with me because it makes sense.

Speaker 3 (43:09):
Trust me.

Speaker 1 (43:12):
I think this is somewhat considered. You can compare this
to single fi components. You're nodding because you're already agreeing
with me, probably, But the thing is, if I see
some and it's the same if I have a function
that takes like three hundred arguments, right, I would immediately
raise like red.

Speaker 3 (43:30):
Flegs for me.

Speaker 1 (43:30):
Can this not be split up the same way we
talked about this in forma episodes. We're both fans of
single fi components, so we don't need to discuss this
in detail. But the same way, I think, even if
we stick with the methods that anger has right now,
if we are not in la la land where we
would like to be with anger components. But you just
have an inline component and it's not readable because you

(43:54):
have too much code. You have too much HML code, next,
too much types code, next, too much CSS. There's probably
a sign that you should split it up. And with
splitting it up, I don't mean create separation files.

Speaker 4 (44:08):
Yeah, exactly, exactly and and and and yes, we we are.

Speaker 6 (44:12):
We agree, we're on an agreement.

Speaker 4 (44:14):
Is in line kind of helps you see these problems
a little bit better?

Speaker 6 (44:21):
Yes, yes, So back to the topic of effect. I
did look into effect.

Speaker 4 (44:29):
I did build like a very small prototype of like
like an entire flow from the request loaders all the
way back to the long database.

Speaker 3 (44:41):
Right.

Speaker 4 (44:43):
I like it because of two of two aspects. One
is that errors kind of like ERA handling things. The
second is the dependency ingestion. It kind of like it's
kind of built in. But then I looked at the
function that I wrote, I'm like, I don't think I
can convince my team to write generator functions.

Speaker 3 (45:07):
I'm not a big feel generator functions either.

Speaker 6 (45:09):
The syntax sucks.

Speaker 4 (45:11):
Yeah, honestly, the syntax sucks. And I understand how it
works and understand why effect uses it. But then I
can bring myself to okay, team, you have to write
effect dot jen functions star blah blah blah. Now that's
your start to function.

Speaker 3 (45:28):
My god, damn it.

Speaker 4 (45:30):
I cannot do it, but it's really nice. So I
kind of like took a step back, scratched the effect experiment.
But then I really did look into trying to incorporate
dependency injection into our application. Because something simple like just

(45:54):
like a locker so remix. The flow up remix is
that something make a request to the loader action which
has the context, which has the request itself. On that request,
we have the signal, the aboard signal, so basically the
context of the entire requests.

Speaker 6 (46:11):
We have those information.

Speaker 4 (46:14):
Now we want to make the locker to be aware
of those information, for example, the correlation idea of the
of the original requests, so that even the function that
talked to the database when we call locker dot log,
we want to know that this belonging to this context.
Without dependency injection is hell passing the context around. So

(46:38):
we ended up with just like all right, so these files,
these these API functions file just new up the old
locker with zero correlation, Like, oh my gosh, yeah, I
really really want to have dependency injection.

Speaker 1 (46:56):
I did have to open the docs for effect. Yes,
I'm not a big fan of generators. Yeah, but I
think I would like this, particularly in the particularly like
in this full sex scenario.

Speaker 3 (47:12):
I think I would really like this.

Speaker 1 (47:15):
Talking about fancy libraries that I have not properly used.

Speaker 3 (47:18):
Have you used archetype?

Speaker 1 (47:22):
I think for me it's probably been now three or
four weeks that I've.

Speaker 3 (47:26):
Heard about it the first time.

Speaker 1 (47:28):
And for those who are like me and haven't heard
about it before, it's basically like this odd scheme of
validation library more or less. The thing that where they
are different, or the they will probably different, have a
different opinion. But the thing where I think they are
different is that they don't express types with types. They

(47:49):
express types as a string. And at first I was like,
why did they do that? Strings are not typesafe? Well, A,
they implemented it in a type safe way, which is
from a typescript scenari already like ridiculous, so you do
get compile errors if you. They basically use like I don't,

(48:09):
probably like a giant string literal type that expressed that
that type construct because they also have validation aspects in
that type DSL that they define. But the thing where
I think this is interesting is that it allows also
for serializing that. So basically you could ship if you

(48:30):
if we talk about like data ownership or something, you
could have your back end define the data shape and
with the data deliver how it's validated and how, and
then do the run time validation and you know what
the type. I haven't used that, but if I think
through this in my head, this sounds pretty cool.

Speaker 6 (48:51):
Yep.

Speaker 4 (48:52):
Now about archetype, I haven't used it to that extent.
I just tried was just like try it out alongside
out the scheme of validation's library like ballabat and ZART
and things like that, just to say what what what?

Speaker 6 (49:08):
What vies with me the most? In my opinion that
would still be I.

Speaker 4 (49:13):
Would still vibe with ZART And the thing with archetype.
The thing that kind of throws me off and any
other libraries that does that do this is I hate
libraries that have a VESCO extension accommodate to accommodate it
effect does have a Visco extension to accommodate it. And

(49:38):
Archetype too, I'm like, why do I have to so?
So now you're forcing me to use vs code to
enjoy enjoy your library to the fullest.

Speaker 3 (49:48):
To be fair, Archetype has a WebStorm extension.

Speaker 4 (49:52):
See I don't like tools that that that need kind
of extra help.

Speaker 1 (49:59):
I I get that sentiment in a way. On the
other hand, I think it's a and obviously I have
slightly different opinions on that because I think in a way,
you need to prioritize what's important for you, right, And
if we look at arch Type as an example, like

(50:21):
the I think the serialization is something that they consider
it as like a primitive for the design of the library.
This is something where the language lacks capabilities, but a
tool can accommodate that. So therefore, I think at the
end of the day, it's a trade of Okay, what
is important to me and how can I provide a
nice developer experience. And I think there are different tools

(50:43):
for different.

Speaker 3 (50:45):
Aspects of that.

Speaker 1 (50:47):
I mean, at the end of the day, if you
would look at it like that, also Anger has the
same thing. You need the Anger language server or web
Storm to have a decent experience because HML, like Anger
has never been native HML. You can discuss that with
me all day long. But the minute you have curly braces,
it's not HML correct. Plus in that curly braces you

(51:12):
have typescrep context that is absolutely not HTML anymore. And
if we just look at the types score file, you
have HML in there or CSS. So it's so to
some extent tools I like to look at it like that.
A tool needs to take care of the developer experience
and if the framework, the library that you provide has

(51:37):
issues in the developer experience for certain due to certain circumstances.
For instance, another great example for Angula, we have the
new great component factory instance thingy thing an Anger at nineteen,
Anger or twenty and Anger twenty.

Speaker 3 (51:52):
I think that comes out where you.

Speaker 1 (51:55):
Can at runtime create a component instance and pass input PAAM.
Because of input aliases and those kind of things, Anger
team cannot properly type those so if you use that,
you don't have type information. Well, fancy libraries and IDs
without saying a certain name can provide those informations because

(52:19):
that code and or like web symbols are pretty cool.
So that's just what I'm saying I think there's space
for a library needs to make design decisions, and a
tool can accommodate those design decisions.

Speaker 3 (52:36):
I see.

Speaker 6 (52:37):
I mean it's fair.

Speaker 3 (52:38):
Is fair?

Speaker 6 (52:39):
Is probably too extreme.

Speaker 3 (52:40):
On my part, but it's very black and white.

Speaker 1 (52:45):
Yes, it is fair.

Speaker 6 (52:47):
Is fair, It's.

Speaker 3 (52:48):
Fair Fundamentally you have a point to be fair. Fundamentally
you have a point.

Speaker 4 (52:53):
Yeah, like it is immediately throws me off when I
see oh in STOVIA's extension.

Speaker 1 (53:01):
But according to that argument, everything should just be TSX.
Then that's literally the only thing that chips with the
types blank or server other than type.

Speaker 4 (53:12):
Honestly, with you, I don't mind TSX at uh.

Speaker 3 (53:16):
I've said this publicly before.

Speaker 1 (53:18):
I think TSX is the best thing that happens to
developer tools works.

Speaker 3 (53:24):
Everything else does need special attention.

Speaker 4 (53:28):
Now, the thing is well with with with with TSX.
It doesn't mean that you have to slick to like
dot map to iterate like solid They have like a
four thing right, Yeah, but I mean is fine, give
me touch set.

Speaker 1 (53:51):
That's one thing that Anger struggled with for quite a while.

Speaker 3 (53:55):
Type safety THATSX.

Speaker 4 (53:59):
Yeah, it's amazing to me, Like if you think about it,
like Anglist is the first framework that embraced. Typescript is
the weakest type framework.

Speaker 3 (54:10):
That we have. Yep, I'm like what.

Speaker 1 (54:15):
From like a technical aspect, I think the approach that
the Anger team took with like converting the HML to
typescript to figure out type information is super interesting.

Speaker 3 (54:25):
But it's also the reason why.

Speaker 1 (54:27):
We don't have all types of language feature We talked
about this earlier because it basically needs a mapping from
one to one of Like, Okay, how does this syntax
in HML be represented in typescript?

Speaker 3 (54:39):
Yeah, which the new.

Speaker 1 (54:44):
In that type of I think are enabled by types
by Anger twenty now right as operators in HML, I
think it's a matter of tradeos.

Speaker 3 (54:56):
Right.

Speaker 1 (54:57):
Is this a common enough use case that it's worth
implementing in a compar and a language server.

Speaker 4 (55:03):
Yeah, but you still cannot have global symbols in your ashetmail.

Speaker 6 (55:08):
We still have to do read only math egos math.

Speaker 4 (55:12):
Yes, Yes, that's that's sad man.

Speaker 1 (55:16):
Yes, yes, I kind of surprised because a view your
technically can use TARSX that people don't really use it.

Speaker 3 (55:27):
I thought this would be.

Speaker 4 (55:27):
More popular, do you Why do you think is this
like a resentment towards React. People like I refuse to
use tex because of React.

Speaker 1 (55:39):
I No, I think that it's more that the sacnified
component developed experience is a little bit nicer.

Speaker 3 (55:47):
I think.

Speaker 6 (55:48):
So this is really I mean, like, uh, what what?

Speaker 4 (55:53):
So what's in the I'm not I don't know view,
but what's in the single of our component format that
you cannot have in the TSX version.

Speaker 1 (56:05):
Oh no, you can't have everything. It's just a very
clear separation.

Speaker 3 (56:08):
Of like where the code is and what to look for.
That's all. You can have everything in TSX. I think
with the viewpart.

Speaker 1 (56:18):
It's also a different problem is the documentation because the
documentation just talks about signified component format, so you're more
trimmed towards Okay, let's use this over other approaches the
same way. In No, I don't have an example for Anguler.

(56:38):
The Anger documentation usually has everything in there, for good
or bad.

Speaker 6 (56:45):
Yeah.

Speaker 4 (56:45):
So yeah, anyway, my current my current state is how
should I do this? How should I approached it? Because
there's one thing is so we migrate. So when we
first migrate from Angler to like react and then to remix,
when it was when the application was still Angler or

(57:08):
React router, which is a single page application. We still
had the graph KL back and for front end got
a deal going on, and in that graph KL server
we put the permissions layer on the resolvers, which so.

Speaker 6 (57:31):
It's kind of weird. It's kind of weird in the
sense because you know, you don't have a craft.

Speaker 4 (57:35):
They have just resolvers qureis queries right and inside of
those curries function did you you talk to your database?
And then they also have like graph KL, mongol dB
or graph col permission whatever they layer that they put
right in front of those stovers. So when we migrate

(57:58):
those functions to remix, we keep the permission layer next
to the Mongol database layer.

Speaker 3 (58:08):
Mm hmm.

Speaker 4 (58:09):
I called this out, but it seems like at the
at the time I did not convince people enough or
I did not push hard enough, which I should have,
and for some reason I was I was like convinced
by the people that has been on the team for
longer than me.

Speaker 6 (58:29):
That I kept it.

Speaker 4 (58:30):
I kept it closer to the mong of the database layer.

Speaker 6 (58:34):
It sucks. I'm sorry, I'm sorry. If it's gonna air
or not, I sucks so bad.

Speaker 4 (58:42):
Why because now we have a higher level than these
resolve of functions, right, which is the loaders, which is
where the request initiates, So that is where the permission
should be checked out the freaking Mongol database layer.

Speaker 6 (59:00):
So now in some of the among.

Speaker 4 (59:02):
The database functions we have, we have like the permissions
tied to them, and those are the correct permissions. We
have enough information to check for the permissions. But then
there are something that we don't have enough information to check,
so we like we we slap like allow all on
those functions and then do the check inside of the function.

Speaker 6 (59:22):
Body.

Speaker 4 (59:23):
Yeah, it's like the consistency it just went.

Speaker 6 (59:27):
Through went out of the window, which eccuse me.

Speaker 1 (59:31):
Yeah, it also seems sweet because like things like permission
you want to catch as early as possible, and like
having to the database is very late in the process exactly.

Speaker 4 (59:41):
And also because because of that approach. So let's say
that you are in order to get to this route, right,
in order to see this route, you need you need
to be an admin.

Speaker 6 (59:52):
Of this organization.

Speaker 4 (59:54):
So we have the organization idea from the route. All right,
we have to we have to check the permission. Now,
check the permission. We have to grab the organization, check
the memberships array things like that. But then these permission
functions just returned two or false.

Speaker 6 (01:00:13):
So now in the in the bodies.

Speaker 4 (01:00:15):
So like later on that route, we still we we
still need the information of this organization. We fetch it again.
And when we fetch it again, we call it the
Mango database functions, which means that market data bay function
might have permissions again which fetch again. So in order
to get to this route, we could have fetched the

(01:00:36):
organization data once, but we did it like five or
six times. Yeah, yeah, so bad. And then and then
because because these functions just returns two of falls, right,
so you have so let's say that you have like
get organization, get organization details that returned the organization. But

(01:01:00):
then the the the derived information from the permission check itself.
For example, when you do permission check, you do know
that if this organization station is accessible or not, public
or private, if the user is a membership or not,

(01:01:20):
and if they are a member, what role do they have.
So we all have all of this derived information during
the checking process, but we lost them because we don't
return anything. We don't pretend that information anyway in the
context of the request. So when we return to say
const organization echos or wait, get organization details. All right,

(01:01:42):
you pass this, You got the organization, Yes, you have access.
Next on the next line, cons ease admin echos eCos
away this organization admin.

Speaker 3 (01:01:54):
Check again.

Speaker 4 (01:01:57):
So we have this like all the fat each you
black the entire back end of the remix application.

Speaker 1 (01:02:06):
I think it's funny because I think everyone can relate
to that so much.

Speaker 4 (01:02:12):
But but then again, so as you mentioned on the
price side, as you realize this problem, you grow as
a developer.

Speaker 1 (01:02:19):
Yes, yeah, I think I saw that on Twitter a
couple probably months ago at this point, where someone said,
if you don't see code smells, you are the problem
of the code.

Speaker 3 (01:02:34):
I think this is very true.

Speaker 4 (01:02:36):
Yeah.

Speaker 1 (01:02:37):
I think if you look back at your code from
like half a year ago and you don't see an issue,
it basically means you're stuck in what you're doing and
your way of thinking.

Speaker 6 (01:02:45):
Mm hmmm. So yeah, now I'm at the point.

Speaker 4 (01:02:50):
I'm at the point where I don't want to abstract anything.
I want my I want my loader to be as
long as possible.

Speaker 1 (01:02:58):
That is, every one of us has to go through
this face where they think, no, no, we should abstract us. Yeah,
abstracture is great, but it's also sucks. That's also really bad.

Speaker 4 (01:03:09):
Yes, especially yeah, especially like a monor rebo. How did
I set up like a like an ex most an
ex monor is where code code discovery, code navigation is painful.
I mean, god damn it. I just want to look
at the loader and see what the hell is happening. No,

(01:03:31):
I mean like like things like reusable mongo queries, like
those things. Yes, abstracted to like a function, so I
can call it, but don't don't make me, uh have like,
don't don't make me pass like a permission check to
call these functions.

Speaker 6 (01:03:49):
When I get to this point.

Speaker 4 (01:03:50):
When I get to this point, when I get to
the point where I call these functions, my permission should
be good.

Speaker 3 (01:03:58):
I mean intelligent runs in the mono rapportory tour. I
feel that.

Speaker 4 (01:04:01):
Yeah, so yeah, I feel that.

Speaker 6 (01:04:04):
So there are a lot of things that we need
to change.

Speaker 4 (01:04:06):
But it didn't again, straight off between priorities business value.

Speaker 6 (01:04:10):
So everybody, as.

Speaker 1 (01:04:13):
Much as I like talking about an ex claude, I
would still like you to be employed next week when.

Speaker 3 (01:04:19):
The heirs and on somewhat he's had confidences.

Speaker 1 (01:04:26):
Okay, So I was talking to Ryan Kanyado the other
week and he put that statement on me about solid jairs,
which I think kind of goes back to our earlier
conversations in a way.

Speaker 3 (01:04:38):
So we were talking about signals on solid jairs and
he was like.

Speaker 1 (01:04:44):
Saying that for solid jass sickness is the interesting aspect.
They basically don't need components because every front end framework
basically looks at on a component level the way they
structure code, and he is like, components are just developing experience.

Speaker 3 (01:05:04):
I don't care about that. I don't care about components.

Speaker 1 (01:05:06):
What I care about is a data flow so that
I know at the end what we renotds, and that's
what we use signals for. This can be in a component.
We can also just write one singulation file.

Speaker 3 (01:05:16):
If you please yourself, if it makes.

Speaker 1 (01:05:18):
You happy and I So that's one thing that I
thought was really interesting. It's like, okay, because we were
also talking about the signified component pattern and stuff. I thought, Okay,
why is it the case that everyone looks at it
a component and why is that the case now for
the last generously ten years, probably even more to some extent,

(01:05:44):
Why is every front and framework component driven.

Speaker 3 (01:05:47):
Why hasn't there been something better? Do you see what
I'm saying?

Speaker 1 (01:05:52):
Yeah, and I think signals in a way signals obviously
are better. I mean, if we're talking about if the
way change detection was working, and here was like, well
I don't care, just just run everything and react, It's like, well,
I don't care, run everything, but imply a fancy diff
over it. So where signals, it's like, well, this is

(01:06:14):
the piece I changed, let's just render this part. What
do you think about the statement of frameworks don't need components.
Frameworks need to understand how data flows.

Speaker 4 (01:06:28):
I think I agree, but hm hmm, but it's it
is as tricky. Yes, framework needs to understand data flow
to what end.

Speaker 1 (01:06:45):
And so here's the thing, because we were talking about that.

Speaker 3 (01:06:51):
As well. Do you meteor jazz mirror meteor jazz. That's
a ring of hope for you.

Speaker 1 (01:07:00):
I always think you started coding with me at the
same time, but then I remember you started way later
than I did. So meteor JS was at the Anger
JS times right, and meteor JS was like, so ahead
of time. They didn't have one way binding, they didn't
have two way binding. They're three way binding. So so

(01:07:21):
the way that three way binding and meteor JS works
is basically it's a full sex framework. So you have
the client two way binding to the back end and
three way binding.

Speaker 3 (01:07:32):
To the database.

Speaker 1 (01:07:34):
Oh and if you have something like that and you
understand the data flow, you can architect very smart applications.

Speaker 6 (01:07:42):
I see. Oh yeah, I mean I could see that.

Speaker 4 (01:07:47):
But still, though, would you would you still rely on
some sort of like templating by World Templating Library.

Speaker 3 (01:07:57):
I would be fine with JSX yeah.

Speaker 4 (01:08:01):
I mean yeah, I don't mind it, honestly, No.

Speaker 1 (01:08:04):
I think this was a fun episode. I enjoyed very
much talking about this, even though there's like no clear.

Speaker 3 (01:08:11):
Train of pod.

Speaker 6 (01:08:14):
It's types touch is touch g Yes.

Speaker 3 (01:08:17):
It's okay.

Speaker 1 (01:08:17):
We put this in the title for the people that
are still listening. I'm a little sorry, but also I
enjoyed this very much. Thank you for joining me, and
thanks for having me in a way, you.

Speaker 3 (01:08:28):
Know, likewise. Yeah, see you next time.

Speaker 5 (01:08:35):
Hey, this is Preston my I'm one of the NGI
Champions riders. In our daily battle to crush out code,
we run into problems and sometimes those problems aren't easily solved.
Ng comp broadcasts articles and tutorials from NGI champions like
myself that help make other developers' lives just a little
bit easier. To access these articles, visit medium dot com,
Forward Slash, ngcomp.

Speaker 2 (01:08:57):
Thank you for listening to the Angular Plus show in JIKOMF.
We would like to thank our sponsors, the NGCOMF organizers
Joe Eames and Aaron Frost, our producer Gene Bourne, and
our podcast editor and engineer Patrick Hayes. You can find
him at spoonful ofmedia dot com.

All Episodes

S9E8 | TypeScript: the types, the mistakes, and the growth| Jan-Niklas Wortmann & Chau Tran

Episode Transcript

Popular Podcasts

New Heights with Jason & Travis Kelce

The Breakfast Club

Fudd Around And Find Out

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}S9E8 | TypeScript: the types, the mistakes, and the growth| Jan-Niklas Wortmann & Chau Tran