August 8, 2024 • 55 mins
Raul Jimenez, the CEO of Byte Default, answers the panels many questions on functional programming with NgRx. In this playful interview, Raul defines functional programming and what it is trying to solve. The panel discusses side effects using a Spiderman analogy. Raul shares the benefits of switching to and when to use NgRx. The importance of knowing RxJS in using NgRx is considered by the panel. The episode ends with an in-depth discussion on some the specifics of using NgRx for functional programming.
Links
Picks
Become a supporter of this podcast: https://www.spreaker.com/podcast/adventures-in-angular--6102018/support.
Links
- https://twitter.com/elecash
- https://www.facebook.com/adventuresinangular
- https://twitter.com/angularpodcast
Picks
- Shai - https://www.youtube.com/watch?v=B48Exq57Zg
- Joe - https://thinkster.io/tutorials/five-essential-lessons-for-typescript-competence
- Aaron - https://www.rxjs.live/
- Aaron - The Go-Giver, Expanded Edition: A Little Story About a Powerful Business Idea by Bob Burg
- Raul - https://app.quicktype.io/
- Raul - https://www.ag-grid.com/
Become a supporter of this podcast: https://www.spreaker.com/podcast/adventures-in-angular--6102018/support.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:06):
Hey, everybody, welcome to another episode of Adventures and Angulare.
Speaker 2 (00:10):
I'm Aaron Frost, the host.
Speaker 1 (00:11):
I work with Hero Devs and Ngi komf And today
on the panel we have Shai Resnik, shay I Insroy yourself.
Speaker 3 (00:20):
Hello, I'm Shy Resnik, I run Testanngelar dot com and
Hires dot A, thank you very much.
Speaker 1 (00:28):
We got Joe Emes go ahead, Eyboddy, Joe Eames from
Thinkster dot I O.
Speaker 3 (00:37):
And uh.
Speaker 1 (00:38):
Notably missing is one of the world's newest moms, Alyssa Nichael.
Speaker 2 (00:45):
Oh my god.
Speaker 1 (00:47):
Well, I mean by the time this comes out, be
on my It's anytime this week though, So I's gonna.
Speaker 4 (00:52):
Be gone that we don't know.
Speaker 2 (00:54):
No, I don't know anything. But that's why she's not here.
Speaker 1 (00:57):
She's resting up for mom anyway.
Speaker 2 (01:01):
So she's gonna be out for a few epistols.
Speaker 1 (01:02):
But everyone follow her on Twitter and wish your good
luck as a new mom.
Speaker 2 (01:07):
I'm excited for.
Speaker 1 (01:08):
And then as our guest, we have Rauz. We're gonna
have Ral go ahead and introduce yourself.
Speaker 2 (01:14):
To the to the crowd.
Speaker 5 (01:18):
Vold and I'm the CEO for a small company called
Bite Default and we worked for all the world and.
Speaker 6 (01:27):
We do a lot of time.
Speaker 7 (01:29):
What's the name of your company?
Speaker 6 (01:31):
By default?
Speaker 4 (01:32):
It's yeah, bite bite default, yeah bite.
Speaker 2 (01:38):
What was the name of your old your old company.
Speaker 6 (01:42):
I didn't have an old company.
Speaker 2 (01:43):
No, you did.
Speaker 1 (01:44):
You had a company with you and another guy.
Speaker 2 (01:46):
It was you had to developers. What was the name
of your company?
Speaker 6 (01:49):
Ah, that wasn't a company. Actually that was just a
blog and it was too fucking developers.
Speaker 8 (01:55):
Yeah to.
Speaker 4 (01:57):
Hey, hey, code of condo.
Speaker 1 (01:59):
Yeah, the phone, it's the name of a company. Calm down,
telling me you're don't judge his company. You're judging his
company now.
Speaker 4 (02:09):
All right, you're a dumb American.
Speaker 1 (02:12):
Okay, everybody, welcome to the show.
Speaker 8 (02:22):
All right.
Speaker 2 (02:23):
We invited Raoul the.
Speaker 1 (02:25):
Soothing tones of Raoul to the show today because Raoul
has some stuff we wants to talk about.
Speaker 8 (02:30):
What are we talking about today, Raoul?
Speaker 2 (02:33):
I see that.
Speaker 5 (02:35):
I found that this is a very interesting topic, which
is the angler.
Speaker 8 (02:43):
And j X.
Speaker 1 (02:45):
Okay, so a lot of people are like, dude, so
many keywords.
Speaker 2 (02:49):
I don't even know what is the keyword? Functional programming?
Speaker 6 (02:52):
Need okay, function programming.
Speaker 5 (02:55):
This is like programming or functional programming.
Speaker 4 (03:03):
It's like when you use the function.
Speaker 5 (03:06):
Now, yeah, it's actually it's it's like objects are into programming,
but you're not using objects mostly all the time.
Speaker 6 (03:14):
You are composing functions instead of objects.
Speaker 3 (03:17):
So I think it's it's when you are dealing with
functions that like produce no side effects, right or am
I wrong?
Speaker 6 (03:27):
Yeah, well that's that's part of it. Yeah, but that's
that's very true.
Speaker 1 (03:33):
What's the difference between functional programming and pure functional programming pure.
Speaker 6 (03:37):
Fictional program Probably I don't know.
Speaker 5 (03:40):
I'm going to just guess that pure functional programming doesn't
have a child say it said the effects or you're
not going to adach anything to global objects or whatever.
Speaker 7 (03:55):
So is there like dirty functional program.
Speaker 4 (04:00):
Don't go there, it's a trap.
Speaker 6 (04:02):
Yeah, I know, I know it is that then.
Speaker 7 (04:05):
Just impure functional programming. Functional programming.
Speaker 2 (04:09):
Oh man, I'm out out the eject button.
Speaker 7 (04:17):
The eject button.
Speaker 9 (04:19):
We just saw right out. James Bond, Stop you two.
You have a conference run, you have a conference run. Okay,
let's stick with functional programming. So functional program can you
tell us what's the problem that it's trying to solve?
Speaker 5 (04:34):
Well, I think that what it's trying to solve, it's.
Speaker 6 (04:40):
Usual problems with extending classes.
Speaker 5 (04:43):
And sometimes to avoid to half states in your objects
that can be you know, maybe contaminated.
Speaker 6 (04:52):
By other states or that kind of stuff.
Speaker 5 (04:56):
So what's it's important is that your function and receive
some parents and return some values and that's it.
Speaker 3 (05:04):
So so they're not producing any side effects. But let's
let's take a real example from Angler, like I have
a component okay, okay, and I have a service Let's say,
like I don't know, like a product component and a
product service and to display products on the play and okay,
(05:28):
what is the where's the functional program goes?
Speaker 4 (05:33):
Like playing in that scenario.
Speaker 6 (05:36):
In that scenario, pro is going to pay.
Speaker 5 (05:38):
If you want to display a list of products, probably
you should use something.
Speaker 6 (05:43):
Like AnGR X or this other library. I don't remember
the name.
Speaker 4 (05:50):
What no our no our X, Yes, and I.
Speaker 6 (05:56):
Don't remember the name. Actually I will find it. I
will find a no no no no.
Speaker 5 (06:01):
It's very similar to nji X, but it just as
the creators and so on.
Speaker 6 (06:08):
So you probably will use one of those.
Speaker 5 (06:10):
And what you're going to do is to use is
anngr X this revex pattern where you are not going
to call the service directly, but you are going to
call an action that it's going to call the service,
and you are going to receive an action with.
Speaker 6 (06:29):
A response from the service.
Speaker 5 (06:31):
In the middle of that process that it's going to
be a store in a thing called a store, very
appropriate name. The thing is that you cannot modify that
the store directly.
Speaker 6 (06:42):
You have to use always, all the time actions.
Speaker 5 (06:45):
So that's to prevent those side effects that you need
that you said before, that's pretty much it is.
Speaker 10 (06:52):
Here's my favorite question about side effects, side effects or
how you actually make a program do something. So why
do I worry about side effects?
Speaker 8 (07:01):
Effects?
Speaker 7 (07:02):
Nothing happens, literally nothing happens without a side effect.
Speaker 2 (07:07):
So like, let's say you have a function. Okay, uh
huh Wesse.
Speaker 1 (07:15):
We'll say you have a function and you pass, uh
you pass like a person object into the function. Yeah,
you don't want the function to mutate the person maybe
I do. Well, that's not functional. That's that would be
a mutation.
Speaker 4 (07:31):
That's not function to function. Why Joe?
Speaker 3 (07:34):
What what Jose is asking is why wouldn't I want
to be.
Speaker 10 (07:40):
So here here's my scenario. I got a function, it's
the radioactive spider function. I pass in the Peter Parker person, right.
Obviously I want the function to mutate the person, right,
that just makes sense.
Speaker 7 (07:52):
But you're saying that with functional program. I don't want
that to app So it's functional program.
Speaker 10 (07:56):
There's no superheroes, right, we don't Marvel does making money.
Speaker 6 (08:02):
That's not true.
Speaker 5 (08:03):
You can you can use you can use effects, and
that can start to mutiate the results that you're getting
from the server if you if that's what you want,
If that's what you want.
Speaker 3 (08:13):
But let's talk about why not, Like what is the
problem that that's the first question.
Speaker 6 (08:18):
What is the.
Speaker 4 (08:19):
Problem that doing this way solve?
Speaker 2 (08:23):
You know, like, well, he's the expert.
Speaker 6 (08:26):
I mean, in my opinion, I'm not the expert. I'm
just using it a lot in my work. That's it.
I'm not going to say that I'm an expert. I'm
not going to say that I'm an expert anything in
my life, I think.
Speaker 5 (08:39):
Okay, So what it's trying to solve is the you know,
when when your applications are growing a lot, it usually
happens that a lot of interactions between your data is
happening there. So if you're using uh, this one direction pattern,
you can know every time that someone or some function
(09:04):
or some component or certain view has modified it.
Speaker 6 (09:08):
That that's that's store. So that's the point of this
thing that you.
Speaker 4 (09:12):
Can How would you change? How would you know that?
Speaker 5 (09:16):
Well, we we use reducs tools, the debt tools for reducts,
and every time that you you can see the.
Speaker 6 (09:26):
Log with all the with all the actions that you
have executed.
Speaker 4 (09:31):
M hm.
Speaker 5 (09:31):
So every time that you do a call to the server,
and every time that you modify your store or you
add an eating to that store, or.
Speaker 6 (09:41):
You remove some things from the store.
Speaker 5 (09:43):
You can know that because you have on the debt tools,
you have all the log So.
Speaker 3 (09:49):
And by the way, I believe that mobiics, which is
a different implementation of state management, has the same thing,
but they use a think setters and getters now they
use proxies I think to achieve the same thing. So
you get a log of all the changes to a
certain thing, and without writing like a special action or
(10:12):
making it functional per se, you can decorate something as
an action and then prevent people from using it in
other like levels of the program.
Speaker 4 (10:23):
But okay, so so.
Speaker 3 (10:25):
You get like the logability, let's say, the logging ability
to know when you do this in that shape.
Speaker 7 (10:34):
Can you also get lovability in there?
Speaker 3 (10:37):
Is that not No, lovability is not related to state management.
It's far far away management pattern you will meet. But
it's hate ability in there.
Speaker 4 (10:53):
Yeah, but that's that's true with.
Speaker 3 (10:55):
Today's But okay, so let's say you have something that
mutate the you know that this is how people worked
for years where they had like I don't know, services
or some cash or some something that holds like the person,
and then something would change it and it will render
(11:19):
you know, and wherever we got to a place where
it doesn't make sense or you know, something happens and
I don't know, like what happens and you know the
problems that you are describing, is it happening like from
your expand you moved to NNGRX for for a reason,
So what led you to move to that?
Speaker 6 (11:41):
Okay, that's a good question.
Speaker 5 (11:44):
Well, first of all, we started in this project like
in Angler alpha, so angie x didn't exist at all. Interesting,
that's the first thing. So after working in the project
for like one year or so, intex looked stable, pre stable,
(12:06):
and we decided to give it a try. Why because well,
you know, functional programming was getting a lot of trauction.
Speaker 6 (12:17):
One of my co workers. He is very into ELM
two and he.
Speaker 5 (12:25):
Kind of combines me, Hey, we should give it a
try to this because we have these benefits, these benefits,
these things.
Speaker 6 (12:31):
And they said, okay, let's let's give you a try.
Speaker 7 (12:34):
Yeah.
Speaker 3 (12:35):
Wait, zooming, what is this benefit and this benefit and
this benefit.
Speaker 5 (12:40):
Well, he explained to me all these the problems about
using all gender interprogramming instead of functional programming, and the
benefits with for example, using braduct step tools and all
that stuff.
Speaker 3 (12:57):
But I did you suffer from anything before you moved
to anngio rex, Like have you experienced any pain or
hate ability with the old way or let's say the
older way of how we did it.
Speaker 5 (13:12):
Not necessarily, but afterwards we think that it was the
right choice because for example, we did some UI refactors,
like we basically redown the whole UI, so we we throw.
Speaker 11 (13:30):
All the ACL and sas files, keep some components, but
we do it are completely right from the of the UI.
Speaker 5 (13:42):
But because we used anchi X, we we were able
to reuse a lot of code, like all the services,
all the redoucers, the effects, the models.
Speaker 6 (13:55):
Basically we were able to reduce a lot of.
Speaker 5 (13:57):
That which you can do that Also, if you're inducing
a YOURX, that's that's true.
Speaker 6 (14:04):
But maybe it's going to be more difficult if you
are not, you.
Speaker 3 (14:09):
Know, make concerns if you put a lot of logic
in the components here.
Speaker 5 (14:14):
Yeah yeah, yeah, And sometimes you can mess up things
easily if you're not using patterns.
Speaker 2 (14:21):
That's shy mm hmm, I objecked. I feel like you're
leading the witness.
Speaker 4 (14:27):
No, I'm asking him to say something.
Speaker 2 (14:29):
Just tell him what to stay.
Speaker 6 (14:31):
He's taking for his work. He's taking.
Speaker 3 (14:34):
Guy, say I love I love you, Shy, say I
love you Shy.
Speaker 7 (14:40):
But I know you and you know.
Speaker 2 (14:44):
See noise bro.
Speaker 5 (14:51):
But no, it's it's okay. I mean I I I.
I can't like the questions. I like to be interrogated.
Speaker 2 (14:58):
No, I think Shy's questions. I think a lot of
us don't know what a redux is.
Speaker 1 (15:02):
We don't know where it came from, we don't know
why we need it, but we know that we keep
hearing about it, so we just adopt it.
Speaker 2 (15:11):
I don't know what it is. I don't know what
it is, but I got to adopt it.
Speaker 1 (15:14):
And so I think that's why I was asking, like, Hey,
what was the pain that pushed you there?
Speaker 7 (15:19):
Why did the new iPhone?
Speaker 10 (15:22):
Yeah, that's what it is.
Speaker 3 (15:26):
The iPhone that red Beat has it, I must have
it as well.
Speaker 10 (15:32):
But what is But I still in line for four
days to get one exactly.
Speaker 1 (15:38):
No, you know, it's funny you say that, but that's
how I feel like. I had no idea what it was.
But people were like, oh, do you have state in
your app? I'm like, oh, yeah, they're like.
Speaker 2 (15:58):
Them, you have some reducs in your apps state And.
Speaker 1 (16:05):
I'm like, I might have a state, you know, but
uh no, And I feel like I got duped a
little bit. And by the time I realized what it is,
I realized, oh, this is overkill for what I need.
I needed a better solution for this. But what I
got was I got the doomsday solution that I only
(16:25):
need if I have like a highly real time, concurrent
data driven app, which most of our apps aren't, and
even in the apps that are, ninety percent of the
data in that app is.
Speaker 2 (16:36):
And so I don't know, I understand that that's a question.
Speaker 3 (16:39):
No, that's a good point for us to because for
that example, let's say like a high uh, you know,
a lot of events push mutifications, and stuff like that.
Maybe in that complexity level, when you have mutable data
that keeps changing a lot, you might have a hard
time to keep track where like you know that come
(17:02):
from mutation happen and then it makes sense to keep it,
uh you know mutable.
Speaker 7 (17:09):
Well, I just want to point out something.
Speaker 10 (17:10):
I'm actually building the next Facebook, so I obviously need it.
Speaker 7 (17:14):
Right, I'm actually doing that.
Speaker 10 (17:15):
I'm building the whatever is going to be replaced Facebook.
Speaker 7 (17:20):
Right, I'm pretty sure.
Speaker 10 (17:21):
I mean everybody in my company says we're building the
next Face. My boss says, we're building the next Facebook.
So we're going to be as performance as Facebook.
Speaker 2 (17:30):
Right, you have a boss, Joe.
Speaker 10 (17:35):
I'm channeling my inner employee, your spirit animals.
Speaker 7 (17:41):
Yeah, yeah, is Dilbert. My spirit animal is Dilbert.
Speaker 3 (17:45):
Okay, So let's get back to njr X and functional
n gr REX. So you're doing NJI REX, which is
divided into instead of mutating something, you raise an action,
your mit an action or something like that, and which
is like an event, and like you have the reducer, which, yeah, the.
Speaker 2 (18:07):
State, right I have I have the same question.
Speaker 1 (18:11):
So I understand reducts, actions, side effects, reducer selectors. Right,
how is functional programming with anji x different than programming
with anji X.
Speaker 2 (18:22):
Like, what's the difference between functional.
Speaker 1 (18:25):
Inj X and non functional injections? I know anj X
the way we learned it. Like, what makes your inter
x functional? I guess programming.
Speaker 6 (18:35):
In Yeah, I will say that anji x is functional
by default. So if you are doing interi X, you're
doing functional programming.
Speaker 3 (18:45):
So the reducers themselves are return and immutable data like
luted the actual data they receive, but a new copy
of the data. And that makes them functional because they
don't produce any side effect. They don't change maybe the
state that they got, right.
Speaker 6 (19:01):
This is if you are doing properly.
Speaker 1 (19:04):
Yeah, So the reducer is what's known as a pure function.
If you give it the same input, it will put
out the same output every single time.
Speaker 2 (19:14):
That's supposed to be what your reducer does.
Speaker 1 (19:16):
If you have a reducer that, given the same input,
would ever output a different output, then you're not necessarily
dealing with a functional of a pure function as a reducer,
which is what they're supposed to be.
Speaker 8 (19:27):
Right.
Speaker 1 (19:29):
So when we talk about functional programming with injurax, are
we talking about the reducer or were talking about like
the selectors, because really that's where these two paradigms are
going to come in. Are going to be in the
reducer or the selector. It's not necessarily going to be
in the side effect of the actions.
Speaker 2 (19:44):
So what does functional programming and inji act mean?
Speaker 6 (19:48):
Who's a g X here?
Speaker 2 (19:51):
When I get forced to, I do okay.
Speaker 6 (19:53):
And I'm engine okay, okay, who like it?
Speaker 1 (19:57):
It was bro that was this since your comment, I
use it when enforced you, I'm being honest.
Speaker 6 (20:01):
Okay, do you like it? Oh? No, you hate it? Yeah?
Speaker 1 (20:07):
I mean it's I love my friends that build it,
So I won't say what I really think.
Speaker 2 (20:12):
I just think.
Speaker 1 (20:13):
Also it's it's a bit over architectured for most of
what I do.
Speaker 4 (20:18):
But I think we talked about it like two episodes ago.
Speaker 3 (20:21):
They also say that you might not need Angie rex
in everything that you do. You have use cases for that,
and that's cool.
Speaker 4 (20:29):
That's okay.
Speaker 3 (20:30):
That's why I asked, and I asked from a sincere
place the use case. The troll went through why he
needed or they needed to use it. Because this is
what I want to know myself when I will encounter
a use case like that I really want to know,
because if I will encounter this use case, I want
(20:50):
to know if I should implement it or not. What
is your experience if it was helpful. I'm not asking
it to troll. I'm asking from a sincere place.
Speaker 6 (20:59):
Okay, thank you, Shay. I know that you are not
controlled all the time, all the time, all the time.
Speaker 12 (21:06):
I don't know if when we choose at the moment,
when we chosen that angur X or you know state
management thing.
Speaker 5 (21:20):
I don't know if it was a good decision or
if it was a very good, you know, solution for
our problem. Because in most cases of URAP, we are
just displaying list and that kind of things, which is
like the ninety nine percent of the apps are doing.
(21:42):
But we have a particular case where we have to
generate forms dynamically and store the data and all that stuff.
Speaker 6 (21:51):
We're using anj X for all that.
Speaker 5 (21:53):
Yep, it's pretty complex to explain all what we do.
Speaker 13 (21:58):
But I do you really know, as I said before,
that it was very good because when we did this
you know, this refractor, it was so easy to do
that refractor.
Speaker 3 (22:11):
Okay, let me ask you, like I don't know, backward
questions like if I want do n g X in
a functional way, what will be the danger in that?
Speaker 6 (22:22):
Like?
Speaker 3 (22:22):
What am I missing? What's the pain there?
Speaker 14 (22:25):
It is true, and I agree with Aaron that it
is not maybe what you should use for everything, for
every single app that you're going to do, you should not.
Speaker 6 (22:38):
Probably use and your X for everything.
Speaker 5 (22:41):
I really think that if your app is pretty big
and you expect that your RAPP is going to grow
a lot, you are going to get more benefits a
long time. Why I do think that because when your
app is growing and you have a lot of screens,
(23:02):
and those screens are growing, and you have you know,
for example, now you have this upload component where you
can do multiple uploads and then you can move along
your app and you can still see your uploads there.
Speaker 6 (23:17):
And all that and that can stuff.
Speaker 5 (23:20):
Okay, you are going to be able to reuse a
lot of code across old the screens, and it's going
to be very easy to use the same services and
all that stuff across all those views when your app
this is growing and growing. And this is something that
I've noticed, As I said, we've been working in this
(23:41):
play for since Anglaropha and we started using a ger
X I think that when vers in two.
Speaker 6 (23:50):
What's released.
Speaker 5 (23:51):
So we've been using jr X for a long long
time I will say almost two years maybe, and this
is something that we we really noticed that it helped
us to right now to create new screens for us.
It's very very fast. A big part of that is
because we are using a ger X I think.
Speaker 3 (24:12):
Okay, sorry to cut you there, just focusing again, reiterating
my question. It was not about using anji X. Let's
say I'm using anji rex already. But now, like let's
say we said that the functional elements of it was
the reducer. Like if I'm making sure I'm returning and
(24:33):
copy the data and not the data I received, this
will make it like a pure function with outside effects,
and then this will make it function. What is the
danger with not doing it that way? Like if I
will return what I received and mutated, what will happen?
Speaker 4 (24:53):
What is the danger in there?
Speaker 6 (24:54):
Probably?
Speaker 5 (24:55):
Well, this is going to happen is you will have
your restore is going to have a copy in memory
that it's not what you're ready, what you really get.
So maybe you're going to see that one of your
views is okay and the others not or something like that.
Speaker 6 (25:16):
Why let me think about it. Okay, so you're telling
me that you mutated your store.
Speaker 15 (25:25):
Actually that's not possible unless, yeah, you do the reducer
you mess up with your redeuser. But mostly what it's
going to happen, it's probably what I said. You are
going to your data, the data that you receive it
from from the server or from whatever. It's not going
(25:48):
to be the same that you have in your serve.
So I don't know what you're going to want that.
Speaker 1 (25:57):
Actually, Yeah, sometimes getting into the weeds on NNGRX stuff
is tough because we all have.
Speaker 2 (26:04):
Different needs, right, every single one of our app is so.
Speaker 1 (26:06):
Different and and uh, it's hard to compare. I think
I think that a lot of the disconnect around the
conversation of hey, state, just even that word any more,
that word is so loaded, Like it used to just
mean variables that had values, but now it's so loaded
what state even stands for.
Speaker 2 (26:26):
And so I think people come into the word state
with a lot of like already.
Speaker 1 (26:31):
Established points and assumptions made, and it makes it hard
to sometimes see gide eye on what we're talking about.
Speaker 2 (26:37):
And so there's a lot of confusion anymore.
Speaker 1 (26:40):
At least when I'm like when I'm on the Twitter
or I'm on when I'm talking to those pirates. You
know that I was talking to like stop talking to pirates. Well,
you know, if they talk to you, it's rude to
not talk back. You have to talk.
Speaker 4 (26:53):
Yeah, but they don't. They don't really like no, they like.
Speaker 2 (26:58):
They like me.
Speaker 1 (26:58):
No, they're programming pirates. So anyway, it makes it hard sometimes.
But I am interested in understanding how people can write
better functional RX stuff. And I think that the functional
parts of of NGRX.
Speaker 2 (27:15):
Are RX itself.
Speaker 1 (27:17):
Like when I look at, hey, how do how do
I make my NJRX functional? I go, Okay, Well, in
njr X there's the reducer and you also have the effects,
which even the RX n GRX team feels like NJRXFX
are completely separate from njr X, right, like they want
people to use effects even outside of njr X, And
(27:38):
I'm like, okay, cool, So n g RX effects kind
of are outside of JX.
Speaker 2 (27:42):
So and when you look at an effect, it's really
it's really just r X.
Speaker 6 (27:46):
Yeah.
Speaker 1 (27:48):
And so when I look at at n g r X,
I see wrappers around some RX stuff, and so I
think that the point here being getting good at NJR. Again,
we didn't get at RXS and functional RX and like
state mapping and like deriving one state from a previous
state is really how you how you get good at
(28:12):
functional programming inside of JRX or RX. It's it's almost unrelated.
It's almost a separate conversation to INJEX and it's more
just around our X just in general, unless you're talking
about the reducer function, because the reducer function that actually
is functional, right, Like that that is the piece of
INJEX that is FP. And so that's kind of how
(28:33):
I'm seeing, Like are we talking about the reducer or
are we talking about how we select it back out
of the store and mutate it from an array of
users that's hard to search through into a map of
users that's easy to search through, right, and like stuff
like that, like and how are we doing that kind
of thing? So that that's kind of how I see
(28:54):
when we're talking about functional programming in RX or INJX,
I'm really just seeing a lot of conversations about our exs.
Speaker 2 (29:02):
Is that true role? Or what are you seeing different
than what I'm seeing?
Speaker 5 (29:05):
I agree with you. I think that XS is super important.
I mean we are using heavily obviously here xcs, especially
in the facts as you.
Speaker 6 (29:17):
Said, and also when we get.
Speaker 5 (29:20):
The you know, the success actions when we do a
call and that's the SEXES action, it's a return. We
do some operations maybe on the view whatever, and we
use a lot of xsre too. So yeah, RXS is
definitely super important. If you want to be good probably
with nji X and functional programming, you have to to
(29:43):
work a lot with RXS and be good with that.
Speaker 6 (29:47):
And it's complex until you you get it. It's complex.
Speaker 1 (29:52):
I remember, you know, my first Angular two. I think
I came in on Angular three. No, sorry, Anger three
is visible. Sorry, I think I came in on Angular four. Sorry,
I just stepped into hornetsness. My bad, dude, I didn't
mean to poke the bear. Sorry, I came in on
the imaginary Angular.
Speaker 2 (30:12):
Sorry, no, I came in on Angular four.
Speaker 1 (30:14):
And I kind of just skipped RX because like the
plural site courses that were teaching me and like the
Todd models were like just do to promise.
Speaker 2 (30:26):
And they're basically they're like just step.
Speaker 1 (30:28):
Around it, like just get it back to a promise.
Speaker 6 (30:32):
Yeah.
Speaker 1 (30:32):
So and I'm not blaming them because I think and
I think there's a lot of people that still think
this today. A lot of data doesn't need to be
a stream because it's only coming one time, it's not concurrent,
it's not going to update again and again and again.
Speaker 2 (30:46):
So promises were fine for them.
Speaker 1 (30:48):
So I think that there was some merit to teaching
it that way, but it causes to kind of sidestep
ANGULAR or sorry X because it's it's pokey, right, Like
promises have like two callbacks, right, our X has like
four million and one as of this week, operators like
they got a new one. It's now four million and one, right, Joe, Joe,
(31:09):
am I right, it's up to.
Speaker 2 (31:11):
Four million one, Yes, four million, and you know, okay, cool,
thank you.
Speaker 1 (31:17):
So I think that like there's a reason why everyone
was like, hey, just don't do this, just step around it, right,
And Bonnie at Hirez was like, don't do it, it's bad.
Speaker 2 (31:27):
I'm like, okay, I'm not gonna do it, and so
and so.
Speaker 1 (31:33):
But now I think the community generally is like, all right,
about face, let's let's get serious on this RX stuff.
And even if I only have to learn three or
four of the operators, I at least need to learn it,
and so there seems to be a bit more prowess
now in angular seven. I think a lot of people's reluctant,
like people like me, oh my gosh, Like I got
(31:53):
over the reluctance because I had it identified with that
comment a lot, Joe. But now I love it, Like
I look at like my favorite technologies I've learned in
the last five years, and I think RX is my
number one, Like it is so phenomenal, like.
Speaker 2 (32:08):
It's so amazing.
Speaker 1 (32:09):
But I wasn't there when I started, and I wasn't
there with any either when I started.
Speaker 2 (32:14):
It took me some time to fall in love with it.
Speaker 7 (32:16):
And so yeah, the same way you felt about backbone.
Speaker 1 (32:19):
Uh yeah, no, backbone. I never had a honeymoon phase,
but it never I never got like, oh I like
you now, Like I never got there.
Speaker 2 (32:34):
Backbone was always like this is just as hard as
just jaquerry. So why can't if.
Speaker 7 (32:39):
You never offered let's just be friends, you never asked
said that.
Speaker 8 (32:44):
It's me, it's not you.
Speaker 3 (32:47):
Wait, but let's get back to the just to maybe
I don't know, summarize or just trying to figure out
what we we have learned today.
Speaker 6 (32:57):
Okay, so.
Speaker 3 (33:00):
You know, I'm trying to maybe take the like, you know,
the points that what is important because well the topic
of today is Andrea X like functional ANDNGI X.
Speaker 7 (33:13):
Right.
Speaker 3 (33:14):
I think that we as a panel did like maybe
not so good of a job, maybe interrupting you a
lot with questions. Uh, and we didn't let you maybe
do or say the thing that you wanted to do
or say.
Speaker 4 (33:29):
So I want you to.
Speaker 3 (33:31):
Have, like you know, the the chance now to maybe
talk about what you want to talk or just to
you know, give us the points, the important points you
want to pass m.
Speaker 5 (33:44):
So you don't have any questions, right, and you're just
doing this because you are not more creative.
Speaker 8 (33:49):
Yeah, that's yeah, I can vouch for that. Yeah, it's
a little bit that I think.
Speaker 1 (33:54):
I think Shi feels like we pulled it off the
rails and we didn't we didn't get to hear your message,
and we want to make sure the listeners hear your message.
Speaker 2 (34:02):
Yeah, am I wrong?
Speaker 4 (34:03):
Yeah, That's what I meant.
Speaker 6 (34:04):
Okay, Okay, well.
Speaker 5 (34:08):
A couple of things I think, as you said, uh,
just use funcial pramming and injury X redex and all
the stuff. If you like it, you don't like it,
and you don't feel comfortable with that, just don't do it.
I think that that's that's uh the technology. It's just
to get the best of it. If you're not getting
(34:30):
it or you're not getting the best of it, just
don't do it. Just do whatever you want and do
you think it's right. If you don't like angler, you
can use view yes, or backbone or whatever.
Speaker 7 (34:43):
I highly recommend backbone. I highly recommend that tame here.
Speaker 8 (34:47):
So that's the bone back for life.
Speaker 1 (34:50):
I was on the View Reduced Documents the other day
and they had a statement they said, this is like glasses.
You'll know when you need it, and so if you
don't know you need glasses, then you don't need I'm like,
no one, none of us are like, I don't know
if I need glasses, Shack go buy glasses.
Speaker 8 (35:11):
Like no, no.
Speaker 2 (35:11):
Like.
Speaker 1 (35:12):
I hit thirty nine this year, and this was the
first year I was like, I need a gentleman needs glasses.
Speaker 3 (35:18):
I read the same thing, and I have a problem
with that because people are usually afraid that when you
will know, it will be too late, you know, so
they always have to figure out if I should invest
in this technology or framework whatever or library and to
study it now before it gets too late. And then
I'm I'm in scale and I cannot dog, I cannot
(35:39):
change my code because it's too messy and all that stuff.
Speaker 1 (35:41):
Yeah, it's a balance, right, like you have to balance
the the FOMO or the you don't want to write
legacy code, right. I think reducts is unique because it
has so much and I know that the angie X
team when.
Speaker 2 (35:57):
I hear this is gonna love. It has so much
boiler plate that.
Speaker 1 (36:02):
I think that you do need. Yeah, Brandon loves that part.
Just so everyone knows. Tweet him about it if everyone
wants to tweet Brandon and yeah, hashtag Brandon mentioned Brandon
say thanks for the hashtag, boy. But no, I think
that there is you need to ask a couple box
(36:23):
of questions to make sure it's worth it, because when
it's worth it, it's worth it. But I think there's
a lot of the time that it might be over engineered, right, Like,
no one wants to strap a lawnmore to the bottom
of your teslattle more you're a.
Speaker 8 (36:37):
Fire Yeah wait, like you could do that?
Speaker 2 (36:40):
No, you can, but you no one wants Joe, Joe, Joe,
back it up.
Speaker 7 (36:44):
I'm getting excited now. I know somebody who just bought
a Tesla and I have a lawnmower.
Speaker 2 (36:50):
Well, don't do it, Joe.
Speaker 8 (36:53):
You could do it. No, you could do I could.
Speaker 2 (36:55):
There's a time when it's.
Speaker 1 (36:57):
Like, okay, guys, the only feasible way to manage this
is to put the the lawnmower onto the Tesla. Like
there's a scenario where that's someone is gonna say that
before the world ends.
Speaker 8 (37:06):
But it's not. It's not listen, yeah, like.
Speaker 1 (37:11):
Like there's a scenario where that's a viable solution and
no one has a smile on their face, right, But there's.
Speaker 2 (37:19):
But there's a lot of scenarios I would even argue.
Speaker 1 (37:22):
More where it's okay to put a bully in somewhere
else besides like in the in Therx store.
Speaker 2 (37:30):
And so that's all we're saying.
Speaker 1 (37:32):
And the glasses, despite Shy being a contrarian, the glasses
example is a good example.
Speaker 2 (37:39):
Like everyone understands it. Like I don't know if I
need it.
Speaker 6 (37:42):
Some of me.
Speaker 1 (37:43):
I came on Twitter and they said, hey, this is
not a good example because glasses at leaks fix something
and I don't read like there are some people that
that disagree with it still, so like I'm just having
fun roast over. No know, hey, Twitter taught me this.
I didn't teach this. I'm not saying I would never
(38:03):
say that. Twitter said that.
Speaker 2 (38:05):
I would just asking the question.
Speaker 1 (38:07):
Yeah, no, I'm not saying asking the question just because
I said it doesn't mean I support it.
Speaker 2 (38:13):
You know.
Speaker 10 (38:13):
But now hold on, what about the scenario where I'm
building the next Facebook. In that case, right I need
I need to write, yeah, yeah, I need it right
off that right, I'm building the next Facebook.
Speaker 7 (38:28):
I don't know if you need this, you need it.
Speaker 3 (38:30):
You should, you probably should implement you know what you
said before that State. It used to be about variables,
you know, putting values inside of viables, and now it
became just like this ward, the complicated ward. There's another
aspect that people don't talk about a lot. I feel
when talking about State is cashing. You know, that's a topic, right,
(38:55):
that is very very hard, Like I don't know those
to talking about State because if you think about the
stores in nj X, it's a cash layer, okay that
you could like, you know, use and then you have
other questions do I need a cash layer, okay in
(39:17):
that scenario, do I need it anyway? Or do I
need always the fresh data from the server and all
that question that people don't talk about that enough, I feel,
But that's a topic for maybe a different episode.
Speaker 1 (39:31):
Yeah, I think that cash is something that is helpful
in some scenarios and it makes other apps worse because
cash means you're trying to keep data around for more
than temporary purposes, and you can end up with a
lot of stale data unintentionally, And so if you're going
to cash, you have to have an effective casing strategy otherwise,
(39:55):
like probably with some sort of server push notifications telling.
Speaker 2 (39:58):
You update the cash. Otherwise you're gonna have still data
and stuff. So I think a lot of people look at.
Speaker 1 (40:04):
NJRX erroneously, and I don't. NNGRX wasn't built to be
a client side database. It's not meant to get the data,
put it in there, and then never ask for it again.
It's only meant to be a place where you can
concurrently serve the same piece of data to multiple people
without worrying if they have different copies. But it's not
necessarily meant to be a cash so I think cashing
is a completely different topic separate of NJRX. In my opinion,
(40:26):
I think I think you could solve cashing with NJRX.
Speaker 2 (40:31):
I think you could put it into the store.
Speaker 1 (40:33):
But every app is so different, every need for cash,
Like if I if you were selling donuts, your cash
is so much different than if you're if you're selling
stock options, right or like real time appropriate, because I mean, well,
donuts are static, like they're not going to change, right,
Like so your cash?
Speaker 16 (40:53):
Yeah, the donut like shot you've never had a donut
I ate on and then it changed, and I'm going
to asking why anyway.
Speaker 3 (41:04):
Okay, Okay, forget about the cash. Okay, that's a different topic,
a different episode. I see like people, Okay, yeah, you
could catch it with this plug in. And then it
becomes like, because it's sort of a repository, you have
like one giant object that is the store, which has
lots of properties on it, which is a giant, big store,
which is an anti.
Speaker 4 (41:22):
Pattern if you think about it.
Speaker 3 (41:25):
Okay, a large, large object holding all the stage. Where's
the single responsibility.
Speaker 1 (41:30):
It's even more of an anti pattern if you realize
that it keeps a copy to every old version of
the data as well. Mm hmm hashtag redox tact tools hashtag.
Speaker 3 (41:41):
So okay, but there are good things that we could
take from it, and that's what I wanted to investigate
in this episode.
Speaker 8 (41:51):
Like when you say, what do you mean and X like.
Speaker 3 (41:54):
Like the patterns, like the functional aspects, the functional aspects.
Let's say, okay, here's one benefit that I see two
functional way overwriting okay, testing okay, Like if you have
a functional like a service, or let's say you have
like a pure functions, it's much easier to test it.
(42:17):
Then if you have like a state mutating kind of thing.
It's not that that is not possible to test, but
pure functions are super easy to test and to understand.
So's that's one direction that using a pattern like n
GX maybe drive you in the reducers to make them
(42:38):
pure functions and they're easier to test. That's one benefit
that I see to the functions. That's why I wanted
to investigate. That's why I asked these questions to get
a better understanding what are the benefits. Maybe if I'm
not using an gr X, I could still take these
benefits into my projects. Right, So do you see any
other benefits like these that our listeners could take to
(43:02):
their project.
Speaker 1 (43:04):
Ng X has a ton of good things, Like it
has memoized pipes streams right, like, so your streams are memoized,
meaning it's not gonna fire more than necessary.
Speaker 2 (43:14):
So there's a there's an insane amount like when you
turn on the push on push.
Speaker 1 (43:19):
For change the text of strategy and an angular component
with memoized streams, that's pretty performant and there's no real
way to deny that. And so there's a lot of
really good things that it teaches you. It teaches you
like if you use the facade pattern that Thomas Burlison
talks about on with NNGX, you end up with a
really nice API around your store and teaching people how
(43:41):
to write APIs.
Speaker 2 (43:42):
Around their data access layers really valuable.
Speaker 1 (43:44):
Like, so it actually teaches you a lot of insanely
good patterns.
Speaker 8 (43:49):
And when you know you need it, it's like.
Speaker 1 (43:53):
The most effective way to have highly concurrent, highly shared data,
Like I can't think more easy to trace way of
coding that up on highly concurrent data.
Speaker 10 (44:03):
So did you One of those examples in there was
that an example of how happen to deal with the
complexity at ADS teaches you good things?
Speaker 8 (44:15):
Is that?
Speaker 10 (44:15):
Is that a mean the facade pattern, that's like, I'm
dealing with the complexity I'm doing I'm I'm I'm working
in spite of it. That was that seemed like that
was one of your examples there, right, Like no, I wasn't.
Speaker 1 (44:28):
Yeah, I mean what you're saying is not untrue, but
that's not why I was saying it.
Speaker 2 (44:33):
Like, because you can write in your X in.
Speaker 1 (44:35):
A way where you've broken the log demeter and now
your component knows too much about the store, right, and
like that's crazy. Or maybe you take the selector back
into your component and then you start making immutable streams
in your component when really that should be up inside
of a service so that other people can reuse the
same logic.
Speaker 2 (44:53):
You know what I'm saying.
Speaker 10 (44:54):
And so hey, this is a pretty advanced episode, but
still it might be good to do a quick definition
of law demeter.
Speaker 7 (45:00):
Finty name dropped it.
Speaker 1 (45:03):
It's just trying to draw fences around like pieces of
logic and keep them reasonable in themselves so that you
you don't have one thing that knows too much about
it's it's environment or a component knows too much about
the store.
Speaker 3 (45:19):
A good example for it if when you find yourself
calling an object like a service, get this other service.
If it has a method that gets you another object,
and then you use and call a method on that
other object, this is breaking the law of demeter because
you should have just like a you know, function that
(45:40):
does something and don't get you another object.
Speaker 4 (45:43):
You should inject this object if you need it.
Speaker 1 (45:45):
Yeah, Lucas, and actually I learned this from Lucas and
uh Lucas rouble key.
Speaker 2 (45:51):
Everyone knows, I mean, and he's great, and so it's
really important.
Speaker 1 (45:54):
I think there's a there's a ton of good stuff
to even if you're like I don't need injects, there's
still a lot of patterns from it you should be following.
Speaker 2 (46:01):
And I'll all stand on that hill.
Speaker 5 (46:04):
I think that, Well, there are a lot of things
about ins X about using anji x in your project.
For me, one of them is that if you're working
in kind of big teams, it's going to be very
used to introduce new members because when there is there
(46:25):
is a lot of documentation. There is good a lot
of good examples on internet. Once you have learned how
anti X works to use anterior X. It's it is
maybe you have to write this boilerplate that it's not
boiler plate actually, but boiler plate, okay. And the thing
(46:45):
is that when you have learned that, it is very
easy to to you know, to call service and you
know exactly how the data flows, which is this is
you know, every time that you heard about redex, you say,
what the hell they mean when they say how the
data flows, and you say that sounds like it bullshit, right,
(47:09):
So the thing is it's it's that it's not because
you know that when you call an action from your view,
that action is going to you know, it's going to
be captured or get from on the effect, and then
on the effect you will.
Speaker 6 (47:29):
Call to a service. That service will do some process
or whatever and return you know, value to the defect
and the effect.
Speaker 5 (47:41):
Will return a new action. So you can do this
interactions with your view. So the good thing about that
is it's because because.
Speaker 6 (47:52):
The flow is so it's so clear.
Speaker 5 (47:54):
So you call the action, it goes to the defect,
from the defect to the service, from the service to
the fact back and from the fact it goes back
to the UI because that flowed so easy to understand
when you have done it like a few times, because
it is easy when you have worked with that for
a while.
Speaker 6 (48:14):
It's easy to you know, to put some stuff in
the middle.
Speaker 5 (48:18):
So for example, what we do is we are using
some a thing called decoders and disney coders.
Speaker 6 (48:25):
It's a library that we created, which what.
Speaker 5 (48:28):
It's doing is that when we do a call to
the API, we use disney coders to decode the response
from the server, and if the response from the server
is what we expect, then we return as success. Otherwise
return our failure. Where we are doing that because sometimes
there are bags introduced in the API that can crush
(48:51):
the UI, and with those decoders we can prevent that.
And that kind of things are very easy to understand
if you so if you are following that architecture and
patterns are good because force you to do the things
in bangue. So there is not going to be a
mother of choice of this developer or this order developer.
(49:13):
You know, you're going to do this in that way
because it's how you should do that, because it's the
proper way, and that's it. So it's going to be
easy to understand for everybody. I'm comfortable with that. I'm
comfortable using patterns and libraries and the good things.
Speaker 1 (49:30):
All Right, we're late in the show, so Ral, if
anyone wants to reach out to you, have any questions
for you, where can they find you?
Speaker 2 (49:37):
On Twitter?
Speaker 5 (49:38):
On alcraft which is E L E C A as
H on Twitter with the same user they will follow
phone me on GitHub too, and probably other networks.
Speaker 1 (49:54):
Okay, cool, Well, thanks for coming on, Thanks for letting
us brande you with questions and for helping us dive
into functional programming with NJRX and with our Yes, it's appreciated.
Let's go, let's move in the picks. Does anyone want
to start the pick section? Yeah?
Speaker 3 (50:10):
I want to recommend I tweeted about it today and
also let talk by Steve Freeman, who is one of
the goose, the growing object or in the Software Guided
by testbook, which gave a lecture two years ago about
TDD and how we meant it to be. So that's
(50:34):
uh that I will put the link and that's it
for me today.
Speaker 1 (50:39):
Perfect, Joe, you want to go, Yeah, I'm gonna pick
type script.
Speaker 7 (50:45):
I like, yeah, type God's pretty cool.
Speaker 10 (50:48):
I started like playing around with a few things, and
I was looking at some computer science stuff and I
don't know if any of you knew this. I'm gonna
anybody who knows this, I'll buy you a swig. Did
you know that typescript supports tuples? Yep, you did you
get a swig? No, they're tuples. It's it's also gift
(51:09):
not twops.
Speaker 7 (51:11):
I've heard it both ways.
Speaker 4 (51:13):
That stupid.
Speaker 2 (51:13):
That's what the Jiff people say, Joe, that's what the gif.
Speaker 7 (51:17):
That's what the Jeff chef.
Speaker 10 (51:21):
Anyway, Typescript supports them tuple tuples, and I did not
know that until I was like looking around in the
corner anyway. So type actually pretty cool. What I like
about it is it's fairly easy to like learn on
top of JavaScript, and there's really not that much you
learned to need to learn to be pretty good at it.
So I actually did throw together a quick little like
video lesson on five essential lips lessons for top typescript Competence.
(51:45):
So if you google that five Essential Lessons for Typescript Competence,
you'll find it.
Speaker 7 (51:48):
I put it up over on Thinkster, but it's free
to the public.
Speaker 2 (51:52):
Type script pipescript all right, I might take a pic here.
I'm at two picks today. Okay.
Speaker 1 (52:01):
The first pick is the company I'm working with, Hero Devs,
is launching a new conference. It's called rx Just Live.
It's gonna be in Vegas on September fifth and sixth.
Speaker 6 (52:11):
Uh.
Speaker 2 (52:12):
The CFP is opening tonight, all RXGS conference. If you
want to go check it out.
Speaker 1 (52:16):
It's RxJS dot live and you can go on Twitter
rx just Live the Twitter account.
Speaker 2 (52:22):
Do a follow there to.
Speaker 1 (52:23):
Follow for announcements for the CFP for tickets. Tickets go
on sale by the time this happens. The CFP and
the tickets will already be on sale by the time
this podcast goes out. So anyway, if you're out there saying, hey,
I need to get better at this rx stuff.
Speaker 2 (52:35):
I need to understand streams and observables and these patterns.
Speaker 3 (52:38):
And dude, that's just like the whole world.
Speaker 8 (52:42):
Yeah, I know.
Speaker 1 (52:42):
But if you're if you want to come, it's a
first year conference.
Speaker 2 (52:46):
It's gonna be a lot of fun.
Speaker 1 (52:47):
There's gonna be a lot of you know, Podwazaki, Ben
Lesch people there that are They're gonna teach us and
we're gonna spend a couple days of community learning So.
Speaker 2 (52:54):
That's my first pick is RX Just Life. Second pick
a book called The Go Giver.
Speaker 1 (53:00):
I read it and I had a moment where it
added some clarity. And I read a book, a small
book like this about a decade ago that changed me.
And as I was reading The Go Giver, I could
tell this was going to change the way I approached
a lot of things. And as I read it, I
started thinking about some people a lot of you guys
will know, Like I started thinking about Joe Eames, I
(53:23):
started thinking about Jesse Sanders, I started thinking about Jorge
Kano and just people that give really endlessly and like
I'm amazed at how their giving makes me want to
be a soldier for them.
Speaker 2 (53:38):
And this book was like, hey, when.
Speaker 1 (53:40):
You give people, people are on your team now and
they love you and they're looking out for your And.
Speaker 2 (53:46):
So it's called the Go Giver. It helps you put.
Speaker 1 (53:49):
Some terms around all the giving that you do. You know,
certainly Hires gives a lot to the community. Hi Rez
would be part of this giver category. So I wanted
to just put it out there for people about giving
and how to kind of grow as an influencer.
Speaker 2 (54:02):
Is called the Go Giver and you can check it
out on audible. It's only about three hours. So those
are my two picks this week.
Speaker 3 (54:07):
By the way, you're one of my inspirations, Frost, forgiving
from seeing the behind the scenes of Energi Coon and
how much you put an effort to give back to
the attendees.
Speaker 8 (54:18):
So just know that.
Speaker 2 (54:20):
Thanks man, appreciate it. Well, you want to take a
chance at some add some picks.
Speaker 5 (54:25):
Yeah, obviously I use this this thing called quick time
dot io.
Speaker 6 (54:31):
I don't know if you know it.
Speaker 5 (54:33):
This is a great tool where you can transform your
you know, your a Jason files to interfaces and so on.
It is very very useful and using it a lot
and I like it a lot. And the other thing
that I will like you it's my my friends at
a Grid.
Speaker 6 (54:51):
They are great. I don't know if you know about
the ag greed, but age Grid is the best grid
in the world, and I love the guys behind it, yus.
They are very very very very nice.
Speaker 7 (55:05):
Second that.
Speaker 6 (55:08):
And that's it. I think that those are two very
good things.
Speaker 7 (55:13):
Cool.
Speaker 1 (55:14):
Well, thanks for coming on everybody, Thanks for listening. If
you want to reach out to us, go follow us
on Twitter, Angular Podcast and we will be tweeting some
new announcements from there going forward. So thank you and
we'll catch you all next time.
Speaker 6 (55:27):
Thank you, rool, Thank you everybody,
Hey, everybody, welcome to another episode of Adventures and Angulare.
Speaker 2 (00:10):
I'm Aaron Frost, the host.
Speaker 1 (00:11):
I work with Hero Devs and Ngi komf And today
on the panel we have Shai Resnik, shay I Insroy yourself.
Speaker 3 (00:20):
Hello, I'm Shy Resnik, I run Testanngelar dot com and
Hires dot A, thank you very much.
Speaker 1 (00:28):
We got Joe Emes go ahead, Eyboddy, Joe Eames from
Thinkster dot I O.
Speaker 3 (00:37):
And uh.
Speaker 1 (00:38):
Notably missing is one of the world's newest moms, Alyssa Nichael.
Speaker 2 (00:45):
Oh my god.
Speaker 1 (00:47):
Well, I mean by the time this comes out, be
on my It's anytime this week though, So I's gonna.
Speaker 4 (00:52):
Be gone that we don't know.
Speaker 2 (00:54):
No, I don't know anything. But that's why she's not here.
Speaker 1 (00:57):
She's resting up for mom anyway.
Speaker 2 (01:01):
So she's gonna be out for a few epistols.
Speaker 1 (01:02):
But everyone follow her on Twitter and wish your good
luck as a new mom.
Speaker 2 (01:07):
I'm excited for.
Speaker 1 (01:08):
And then as our guest, we have Rauz. We're gonna
have Ral go ahead and introduce yourself.
Speaker 2 (01:14):
To the to the crowd.
Speaker 5 (01:18):
Vold and I'm the CEO for a small company called
Bite Default and we worked for all the world and.
Speaker 6 (01:27):
We do a lot of time.
Speaker 7 (01:29):
What's the name of your company?
Speaker 6 (01:31):
By default?
Speaker 4 (01:32):
It's yeah, bite bite default, yeah bite.
Speaker 2 (01:38):
What was the name of your old your old company.
Speaker 6 (01:42):
I didn't have an old company.
Speaker 2 (01:43):
No, you did.
Speaker 1 (01:44):
You had a company with you and another guy.
Speaker 2 (01:46):
It was you had to developers. What was the name
of your company?
Speaker 6 (01:49):
Ah, that wasn't a company. Actually that was just a
blog and it was too fucking developers.
Speaker 8 (01:55):
Yeah to.
Speaker 4 (01:57):
Hey, hey, code of condo.
Speaker 1 (01:59):
Yeah, the phone, it's the name of a company. Calm down,
telling me you're don't judge his company. You're judging his
company now.
Speaker 4 (02:09):
All right, you're a dumb American.
Speaker 1 (02:12):
Okay, everybody, welcome to the show.
Speaker 8 (02:22):
All right.
Speaker 2 (02:23):
We invited Raoul the.
Speaker 1 (02:25):
Soothing tones of Raoul to the show today because Raoul
has some stuff we wants to talk about.
Speaker 8 (02:30):
What are we talking about today, Raoul?
Speaker 2 (02:33):
I see that.
Speaker 5 (02:35):
I found that this is a very interesting topic, which
is the angler.
Speaker 8 (02:43):
And j X.
Speaker 1 (02:45):
Okay, so a lot of people are like, dude, so
many keywords.
Speaker 2 (02:49):
I don't even know what is the keyword? Functional programming?
Speaker 6 (02:52):
Need okay, function programming.
Speaker 5 (02:55):
This is like programming or functional programming.
Speaker 4 (03:03):
It's like when you use the function.
Speaker 5 (03:06):
Now, yeah, it's actually it's it's like objects are into programming,
but you're not using objects mostly all the time.
Speaker 6 (03:14):
You are composing functions instead of objects.
Speaker 3 (03:17):
So I think it's it's when you are dealing with
functions that like produce no side effects, right or am
I wrong?
Speaker 6 (03:27):
Yeah, well that's that's part of it. Yeah, but that's
that's very true.
Speaker 1 (03:33):
What's the difference between functional programming and pure functional programming pure.
Speaker 6 (03:37):
Fictional program Probably I don't know.
Speaker 5 (03:40):
I'm going to just guess that pure functional programming doesn't
have a child say it said the effects or you're
not going to adach anything to global objects or whatever.
Speaker 7 (03:55):
So is there like dirty functional program.
Speaker 4 (04:00):
Don't go there, it's a trap.
Speaker 6 (04:02):
Yeah, I know, I know it is that then.
Speaker 7 (04:05):
Just impure functional programming. Functional programming.
Speaker 2 (04:09):
Oh man, I'm out out the eject button.
Speaker 7 (04:17):
The eject button.
Speaker 9 (04:19):
We just saw right out. James Bond, Stop you two.
You have a conference run, you have a conference run. Okay,
let's stick with functional programming. So functional program can you
tell us what's the problem that it's trying to solve?
Speaker 5 (04:34):
Well, I think that what it's trying to solve, it's.
Speaker 6 (04:40):
Usual problems with extending classes.
Speaker 5 (04:43):
And sometimes to avoid to half states in your objects
that can be you know, maybe contaminated.
Speaker 6 (04:52):
By other states or that kind of stuff.
Speaker 5 (04:56):
So what's it's important is that your function and receive
some parents and return some values and that's it.
Speaker 3 (05:04):
So so they're not producing any side effects. But let's
let's take a real example from Angler, like I have
a component okay, okay, and I have a service Let's say,
like I don't know, like a product component and a
product service and to display products on the play and okay,
(05:28):
what is the where's the functional program goes?
Speaker 4 (05:33):
Like playing in that scenario.
Speaker 6 (05:36):
In that scenario, pro is going to pay.
Speaker 5 (05:38):
If you want to display a list of products, probably
you should use something.
Speaker 6 (05:43):
Like AnGR X or this other library. I don't remember
the name.
Speaker 4 (05:50):
What no our no our X, Yes, and I.
Speaker 6 (05:56):
Don't remember the name. Actually I will find it. I
will find a no no no no.
Speaker 5 (06:01):
It's very similar to nji X, but it just as
the creators and so on.
Speaker 6 (06:08):
So you probably will use one of those.
Speaker 5 (06:10):
And what you're going to do is to use is
anngr X this revex pattern where you are not going
to call the service directly, but you are going to
call an action that it's going to call the service,
and you are going to receive an action with.
Speaker 6 (06:29):
A response from the service.
Speaker 5 (06:31):
In the middle of that process that it's going to
be a store in a thing called a store, very
appropriate name. The thing is that you cannot modify that
the store directly.
Speaker 6 (06:42):
You have to use always, all the time actions.
Speaker 5 (06:45):
So that's to prevent those side effects that you need
that you said before, that's pretty much it is.
Speaker 10 (06:52):
Here's my favorite question about side effects, side effects or
how you actually make a program do something. So why
do I worry about side effects?
Speaker 8 (07:01):
Effects?
Speaker 7 (07:02):
Nothing happens, literally nothing happens without a side effect.
Speaker 2 (07:07):
So like, let's say you have a function. Okay, uh
huh Wesse.
Speaker 1 (07:15):
We'll say you have a function and you pass, uh
you pass like a person object into the function. Yeah,
you don't want the function to mutate the person maybe
I do. Well, that's not functional. That's that would be
a mutation.
Speaker 4 (07:31):
That's not function to function. Why Joe?
Speaker 3 (07:34):
What what Jose is asking is why wouldn't I want
to be.
Speaker 10 (07:40):
So here here's my scenario. I got a function, it's
the radioactive spider function. I pass in the Peter Parker person, right.
Obviously I want the function to mutate the person, right,
that just makes sense.
Speaker 7 (07:52):
But you're saying that with functional program. I don't want
that to app So it's functional program.
Speaker 10 (07:56):
There's no superheroes, right, we don't Marvel does making money.
Speaker 6 (08:02):
That's not true.
Speaker 5 (08:03):
You can you can use you can use effects, and
that can start to mutiate the results that you're getting
from the server if you if that's what you want,
If that's what you want.
Speaker 3 (08:13):
But let's talk about why not, Like what is the
problem that that's the first question.
Speaker 6 (08:18):
What is the.
Speaker 4 (08:19):
Problem that doing this way solve?
Speaker 2 (08:23):
You know, like, well, he's the expert.
Speaker 6 (08:26):
I mean, in my opinion, I'm not the expert. I'm
just using it a lot in my work. That's it.
I'm not going to say that I'm an expert. I'm
not going to say that I'm an expert anything in
my life, I think.
Speaker 5 (08:39):
Okay, So what it's trying to solve is the you know,
when when your applications are growing a lot, it usually
happens that a lot of interactions between your data is
happening there. So if you're using uh, this one direction pattern,
you can know every time that someone or some function
(09:04):
or some component or certain view has modified it.
Speaker 6 (09:08):
That that's that's store. So that's the point of this
thing that you.
Speaker 4 (09:12):
Can How would you change? How would you know that?
Speaker 5 (09:16):
Well, we we use reducs tools, the debt tools for reducts,
and every time that you you can see the.
Speaker 6 (09:26):
Log with all the with all the actions that you
have executed.
Speaker 4 (09:31):
M hm.
Speaker 5 (09:31):
So every time that you do a call to the server,
and every time that you modify your store or you
add an eating to that store, or.
Speaker 6 (09:41):
You remove some things from the store.
Speaker 5 (09:43):
You can know that because you have on the debt tools,
you have all the log So.
Speaker 3 (09:49):
And by the way, I believe that mobiics, which is
a different implementation of state management, has the same thing,
but they use a think setters and getters now they
use proxies I think to achieve the same thing. So
you get a log of all the changes to a
certain thing, and without writing like a special action or
(10:12):
making it functional per se, you can decorate something as
an action and then prevent people from using it in
other like levels of the program.
Speaker 4 (10:23):
But okay, so so.
Speaker 3 (10:25):
You get like the logability, let's say, the logging ability
to know when you do this in that shape.
Speaker 7 (10:34):
Can you also get lovability in there?
Speaker 3 (10:37):
Is that not No, lovability is not related to state management.
It's far far away management pattern you will meet. But
it's hate ability in there.
Speaker 4 (10:53):
Yeah, but that's that's true with.
Speaker 3 (10:55):
Today's But okay, so let's say you have something that
mutate the you know that this is how people worked
for years where they had like I don't know, services
or some cash or some something that holds like the person,
and then something would change it and it will render
(11:19):
you know, and wherever we got to a place where
it doesn't make sense or you know, something happens and
I don't know, like what happens and you know the
problems that you are describing, is it happening like from
your expand you moved to NNGRX for for a reason,
So what led you to move to that?
Speaker 6 (11:41):
Okay, that's a good question.
Speaker 5 (11:44):
Well, first of all, we started in this project like
in Angler alpha, so angie x didn't exist at all. Interesting,
that's the first thing. So after working in the project
for like one year or so, intex looked stable, pre stable,
(12:06):
and we decided to give it a try. Why because well,
you know, functional programming was getting a lot of trauction.
Speaker 6 (12:17):
One of my co workers. He is very into ELM
two and he.
Speaker 5 (12:25):
Kind of combines me, Hey, we should give it a
try to this because we have these benefits, these benefits,
these things.
Speaker 6 (12:31):
And they said, okay, let's let's give you a try.
Speaker 7 (12:34):
Yeah.
Speaker 3 (12:35):
Wait, zooming, what is this benefit and this benefit and
this benefit.
Speaker 5 (12:40):
Well, he explained to me all these the problems about
using all gender interprogramming instead of functional programming, and the
benefits with for example, using braduct step tools and all
that stuff.
Speaker 3 (12:57):
But I did you suffer from anything before you moved
to anngio rex, Like have you experienced any pain or
hate ability with the old way or let's say the
older way of how we did it.
Speaker 5 (13:12):
Not necessarily, but afterwards we think that it was the
right choice because for example, we did some UI refactors,
like we basically redown the whole UI, so we we throw.
Speaker 11 (13:30):
All the ACL and sas files, keep some components, but
we do it are completely right from the of the UI.
Speaker 5 (13:42):
But because we used anchi X, we we were able
to reuse a lot of code, like all the services,
all the redoucers, the effects, the models.
Speaker 6 (13:55):
Basically we were able to reduce a lot of.
Speaker 5 (13:57):
That which you can do that Also, if you're inducing
a YOURX, that's that's true.
Speaker 6 (14:04):
But maybe it's going to be more difficult if you
are not, you.
Speaker 3 (14:09):
Know, make concerns if you put a lot of logic
in the components here.
Speaker 5 (14:14):
Yeah yeah, yeah, And sometimes you can mess up things
easily if you're not using patterns.
Speaker 2 (14:21):
That's shy mm hmm, I objecked. I feel like you're
leading the witness.
Speaker 4 (14:27):
No, I'm asking him to say something.
Speaker 2 (14:29):
Just tell him what to stay.
Speaker 6 (14:31):
He's taking for his work. He's taking.
Speaker 3 (14:34):
Guy, say I love I love you, Shy, say I
love you Shy.
Speaker 7 (14:40):
But I know you and you know.
Speaker 2 (14:44):
See noise bro.
Speaker 5 (14:51):
But no, it's it's okay. I mean I I I.
I can't like the questions. I like to be interrogated.
Speaker 2 (14:58):
No, I think Shy's questions. I think a lot of
us don't know what a redux is.
Speaker 1 (15:02):
We don't know where it came from, we don't know
why we need it, but we know that we keep
hearing about it, so we just adopt it.
Speaker 2 (15:11):
I don't know what it is. I don't know what
it is, but I got to adopt it.
Speaker 1 (15:14):
And so I think that's why I was asking, like, Hey,
what was the pain that pushed you there?
Speaker 7 (15:19):
Why did the new iPhone?
Speaker 10 (15:22):
Yeah, that's what it is.
Speaker 3 (15:26):
The iPhone that red Beat has it, I must have
it as well.
Speaker 10 (15:32):
But what is But I still in line for four
days to get one exactly.
Speaker 1 (15:38):
No, you know, it's funny you say that, but that's
how I feel like. I had no idea what it was.
But people were like, oh, do you have state in
your app? I'm like, oh, yeah, they're like.
Speaker 2 (15:58):
Them, you have some reducs in your apps state And.
Speaker 1 (16:05):
I'm like, I might have a state, you know, but
uh no, And I feel like I got duped a
little bit. And by the time I realized what it is,
I realized, oh, this is overkill for what I need.
I needed a better solution for this. But what I
got was I got the doomsday solution that I only
(16:25):
need if I have like a highly real time, concurrent
data driven app, which most of our apps aren't, and
even in the apps that are, ninety percent of the
data in that app is.
Speaker 2 (16:36):
And so I don't know, I understand that that's a question.
Speaker 3 (16:39):
No, that's a good point for us to because for
that example, let's say like a high uh, you know,
a lot of events push mutifications, and stuff like that.
Maybe in that complexity level, when you have mutable data
that keeps changing a lot, you might have a hard
time to keep track where like you know that come
(17:02):
from mutation happen and then it makes sense to keep it,
uh you know mutable.
Speaker 7 (17:09):
Well, I just want to point out something.
Speaker 10 (17:10):
I'm actually building the next Facebook, so I obviously need it.
Speaker 7 (17:14):
Right, I'm actually doing that.
Speaker 10 (17:15):
I'm building the whatever is going to be replaced Facebook.
Speaker 7 (17:20):
Right, I'm pretty sure.
Speaker 10 (17:21):
I mean everybody in my company says we're building the
next Face. My boss says, we're building the next Facebook.
So we're going to be as performance as Facebook.
Speaker 2 (17:30):
Right, you have a boss, Joe.
Speaker 10 (17:35):
I'm channeling my inner employee, your spirit animals.
Speaker 7 (17:41):
Yeah, yeah, is Dilbert. My spirit animal is Dilbert.
Speaker 3 (17:45):
Okay, So let's get back to njr X and functional
n gr REX. So you're doing NJI REX, which is
divided into instead of mutating something, you raise an action,
your mit an action or something like that, and which
is like an event, and like you have the reducer, which, yeah, the.
Speaker 2 (18:07):
State, right I have I have the same question.
Speaker 1 (18:11):
So I understand reducts, actions, side effects, reducer selectors. Right,
how is functional programming with anji x different than programming
with anji X.
Speaker 2 (18:22):
Like, what's the difference between functional.
Speaker 1 (18:25):
Inj X and non functional injections? I know anj X
the way we learned it. Like, what makes your inter
x functional? I guess programming.
Speaker 6 (18:35):
In Yeah, I will say that anji x is functional
by default. So if you are doing interi X, you're
doing functional programming.
Speaker 3 (18:45):
So the reducers themselves are return and immutable data like
luted the actual data they receive, but a new copy
of the data. And that makes them functional because they
don't produce any side effect. They don't change maybe the
state that they got, right.
Speaker 6 (19:01):
This is if you are doing properly.
Speaker 1 (19:04):
Yeah, So the reducer is what's known as a pure function.
If you give it the same input, it will put
out the same output every single time.
Speaker 2 (19:14):
That's supposed to be what your reducer does.
Speaker 1 (19:16):
If you have a reducer that, given the same input,
would ever output a different output, then you're not necessarily
dealing with a functional of a pure function as a reducer,
which is what they're supposed to be.
Speaker 8 (19:27):
Right.
Speaker 1 (19:29):
So when we talk about functional programming with injurax, are
we talking about the reducer or were talking about like
the selectors, because really that's where these two paradigms are
going to come in. Are going to be in the
reducer or the selector. It's not necessarily going to be
in the side effect of the actions.
Speaker 2 (19:44):
So what does functional programming and inji act mean?
Speaker 6 (19:48):
Who's a g X here?
Speaker 2 (19:51):
When I get forced to, I do okay.
Speaker 6 (19:53):
And I'm engine okay, okay, who like it?
Speaker 1 (19:57):
It was bro that was this since your comment, I
use it when enforced you, I'm being honest.
Speaker 6 (20:01):
Okay, do you like it? Oh? No, you hate it? Yeah?
Speaker 1 (20:07):
I mean it's I love my friends that build it,
So I won't say what I really think.
Speaker 2 (20:12):
I just think.
Speaker 1 (20:13):
Also it's it's a bit over architectured for most of
what I do.
Speaker 4 (20:18):
But I think we talked about it like two episodes ago.
Speaker 3 (20:21):
They also say that you might not need Angie rex
in everything that you do. You have use cases for that,
and that's cool.
Speaker 4 (20:29):
That's okay.
Speaker 3 (20:30):
That's why I asked, and I asked from a sincere
place the use case. The troll went through why he
needed or they needed to use it. Because this is
what I want to know myself when I will encounter
a use case like that I really want to know,
because if I will encounter this use case, I want
(20:50):
to know if I should implement it or not. What
is your experience if it was helpful. I'm not asking
it to troll. I'm asking from a sincere place.
Speaker 6 (20:59):
Okay, thank you, Shay. I know that you are not
controlled all the time, all the time, all the time.
Speaker 12 (21:06):
I don't know if when we choose at the moment,
when we chosen that angur X or you know state
management thing.
Speaker 5 (21:20):
I don't know if it was a good decision or
if it was a very good, you know, solution for
our problem. Because in most cases of URAP, we are
just displaying list and that kind of things, which is
like the ninety nine percent of the apps are doing.
(21:42):
But we have a particular case where we have to
generate forms dynamically and store the data and all that stuff.
Speaker 6 (21:51):
We're using anj X for all that.
Speaker 5 (21:53):
Yep, it's pretty complex to explain all what we do.
Speaker 13 (21:58):
But I do you really know, as I said before,
that it was very good because when we did this
you know, this refractor, it was so easy to do
that refractor.
Speaker 3 (22:11):
Okay, let me ask you, like I don't know, backward
questions like if I want do n g X in
a functional way, what will be the danger in that?
Speaker 6 (22:22):
Like?
Speaker 3 (22:22):
What am I missing? What's the pain there?
Speaker 14 (22:25):
It is true, and I agree with Aaron that it
is not maybe what you should use for everything, for
every single app that you're going to do, you should not.
Speaker 6 (22:38):
Probably use and your X for everything.
Speaker 5 (22:41):
I really think that if your app is pretty big
and you expect that your RAPP is going to grow
a lot, you are going to get more benefits a
long time. Why I do think that because when your
app is growing and you have a lot of screens,
(23:02):
and those screens are growing, and you have you know,
for example, now you have this upload component where you
can do multiple uploads and then you can move along
your app and you can still see your uploads there.
Speaker 6 (23:17):
And all that and that can stuff.
Speaker 5 (23:20):
Okay, you are going to be able to reuse a
lot of code across old the screens, and it's going
to be very easy to use the same services and
all that stuff across all those views when your app
this is growing and growing. And this is something that
I've noticed, As I said, we've been working in this
(23:41):
play for since Anglaropha and we started using a ger
X I think that when vers in two.
Speaker 6 (23:50):
What's released.
Speaker 5 (23:51):
So we've been using jr X for a long long
time I will say almost two years maybe, and this
is something that we we really noticed that it helped
us to right now to create new screens for us.
It's very very fast. A big part of that is
because we are using a ger X I think.
Speaker 3 (24:12):
Okay, sorry to cut you there, just focusing again, reiterating
my question. It was not about using anji X. Let's
say I'm using anji rex already. But now, like let's
say we said that the functional elements of it was
the reducer. Like if I'm making sure I'm returning and
(24:33):
copy the data and not the data I received, this
will make it like a pure function with outside effects,
and then this will make it function. What is the
danger with not doing it that way? Like if I
will return what I received and mutated, what will happen?
Speaker 4 (24:53):
What is the danger in there?
Speaker 6 (24:54):
Probably?
Speaker 5 (24:55):
Well, this is going to happen is you will have
your restore is going to have a copy in memory
that it's not what you're ready, what you really get.
So maybe you're going to see that one of your
views is okay and the others not or something like that.
Speaker 6 (25:16):
Why let me think about it. Okay, so you're telling
me that you mutated your store.
Speaker 15 (25:25):
Actually that's not possible unless, yeah, you do the reducer
you mess up with your redeuser. But mostly what it's
going to happen, it's probably what I said. You are
going to your data, the data that you receive it
from from the server or from whatever. It's not going
(25:48):
to be the same that you have in your serve.
So I don't know what you're going to want that.
Speaker 1 (25:57):
Actually, Yeah, sometimes getting into the weeds on NNGRX stuff
is tough because we all have.
Speaker 2 (26:04):
Different needs, right, every single one of our app is so.
Speaker 1 (26:06):
Different and and uh, it's hard to compare. I think
I think that a lot of the disconnect around the
conversation of hey, state, just even that word any more,
that word is so loaded, Like it used to just
mean variables that had values, but now it's so loaded
what state even stands for.
Speaker 2 (26:26):
And so I think people come into the word state
with a lot of like already.
Speaker 1 (26:31):
Established points and assumptions made, and it makes it hard
to sometimes see gide eye on what we're talking about.
Speaker 2 (26:37):
And so there's a lot of confusion anymore.
Speaker 1 (26:40):
At least when I'm like when I'm on the Twitter
or I'm on when I'm talking to those pirates. You
know that I was talking to like stop talking to pirates. Well,
you know, if they talk to you, it's rude to
not talk back. You have to talk.
Speaker 4 (26:53):
Yeah, but they don't. They don't really like no, they like.
Speaker 2 (26:58):
They like me.
Speaker 1 (26:58):
No, they're programming pirates. So anyway, it makes it hard sometimes.
But I am interested in understanding how people can write
better functional RX stuff. And I think that the functional
parts of of NGRX.
Speaker 2 (27:15):
Are RX itself.
Speaker 1 (27:17):
Like when I look at, hey, how do how do
I make my NJRX functional? I go, Okay, Well, in
njr X there's the reducer and you also have the effects,
which even the RX n GRX team feels like NJRXFX
are completely separate from njr X, right, like they want
people to use effects even outside of njr X, And
(27:38):
I'm like, okay, cool, So n g RX effects kind
of are outside of JX.
Speaker 2 (27:42):
So and when you look at an effect, it's really
it's really just r X.
Speaker 6 (27:46):
Yeah.
Speaker 1 (27:48):
And so when I look at at n g r X,
I see wrappers around some RX stuff, and so I
think that the point here being getting good at NJR. Again,
we didn't get at RXS and functional RX and like
state mapping and like deriving one state from a previous
state is really how you how you get good at
(28:12):
functional programming inside of JRX or RX. It's it's almost unrelated.
It's almost a separate conversation to INJEX and it's more
just around our X just in general, unless you're talking
about the reducer function, because the reducer function that actually
is functional, right, Like that that is the piece of
INJEX that is FP. And so that's kind of how
(28:33):
I'm seeing, Like are we talking about the reducer or
are we talking about how we select it back out
of the store and mutate it from an array of
users that's hard to search through into a map of
users that's easy to search through, right, and like stuff
like that, like and how are we doing that kind
of thing? So that that's kind of how I see
(28:54):
when we're talking about functional programming in RX or INJX,
I'm really just seeing a lot of conversations about our exs.
Speaker 2 (29:02):
Is that true role? Or what are you seeing different
than what I'm seeing?
Speaker 5 (29:05):
I agree with you. I think that XS is super important.
I mean we are using heavily obviously here xcs, especially
in the facts as you.
Speaker 6 (29:17):
Said, and also when we get.
Speaker 5 (29:20):
The you know, the success actions when we do a
call and that's the SEXES action, it's a return. We
do some operations maybe on the view whatever, and we
use a lot of xsre too. So yeah, RXS is
definitely super important. If you want to be good probably
with nji X and functional programming, you have to to
(29:43):
work a lot with RXS and be good with that.
Speaker 6 (29:47):
And it's complex until you you get it. It's complex.
Speaker 1 (29:52):
I remember, you know, my first Angular two. I think
I came in on Angular three. No, sorry, Anger three
is visible. Sorry, I think I came in on Angular four. Sorry,
I just stepped into hornetsness. My bad, dude, I didn't
mean to poke the bear. Sorry, I came in on
the imaginary Angular.
Speaker 2 (30:12):
Sorry, no, I came in on Angular four.
Speaker 1 (30:14):
And I kind of just skipped RX because like the
plural site courses that were teaching me and like the
Todd models were like just do to promise.
Speaker 2 (30:26):
And they're basically they're like just step.
Speaker 1 (30:28):
Around it, like just get it back to a promise.
Speaker 6 (30:32):
Yeah.
Speaker 1 (30:32):
So and I'm not blaming them because I think and
I think there's a lot of people that still think
this today. A lot of data doesn't need to be
a stream because it's only coming one time, it's not concurrent,
it's not going to update again and again and again.
Speaker 2 (30:46):
So promises were fine for them.
Speaker 1 (30:48):
So I think that there was some merit to teaching
it that way, but it causes to kind of sidestep
ANGULAR or sorry X because it's it's pokey, right, Like
promises have like two callbacks, right, our X has like
four million and one as of this week, operators like
they got a new one. It's now four million and one, right, Joe, Joe,
(31:09):
am I right, it's up to.
Speaker 2 (31:11):
Four million one, Yes, four million, and you know, okay, cool,
thank you.
Speaker 1 (31:17):
So I think that like there's a reason why everyone
was like, hey, just don't do this, just step around it, right,
And Bonnie at Hirez was like, don't do it, it's bad.
Speaker 2 (31:27):
I'm like, okay, I'm not gonna do it, and so
and so.
Speaker 1 (31:33):
But now I think the community generally is like, all right,
about face, let's let's get serious on this RX stuff.
And even if I only have to learn three or
four of the operators, I at least need to learn it,
and so there seems to be a bit more prowess
now in angular seven. I think a lot of people's reluctant,
like people like me, oh my gosh, Like I got
(31:53):
over the reluctance because I had it identified with that
comment a lot, Joe. But now I love it, Like
I look at like my favorite technologies I've learned in
the last five years, and I think RX is my
number one, Like it is so phenomenal, like.
Speaker 2 (32:08):
It's so amazing.
Speaker 1 (32:09):
But I wasn't there when I started, and I wasn't
there with any either when I started.
Speaker 2 (32:14):
It took me some time to fall in love with it.
Speaker 7 (32:16):
And so yeah, the same way you felt about backbone.
Speaker 1 (32:19):
Uh yeah, no, backbone. I never had a honeymoon phase,
but it never I never got like, oh I like
you now, Like I never got there.
Speaker 2 (32:34):
Backbone was always like this is just as hard as
just jaquerry. So why can't if.
Speaker 7 (32:39):
You never offered let's just be friends, you never asked
said that.
Speaker 8 (32:44):
It's me, it's not you.
Speaker 3 (32:47):
Wait, but let's get back to the just to maybe
I don't know, summarize or just trying to figure out
what we we have learned today.
Speaker 6 (32:57):
Okay, so.
Speaker 3 (33:00):
You know, I'm trying to maybe take the like, you know,
the points that what is important because well the topic
of today is Andrea X like functional ANDNGI X.
Speaker 7 (33:13):
Right.
Speaker 3 (33:14):
I think that we as a panel did like maybe
not so good of a job, maybe interrupting you a
lot with questions. Uh, and we didn't let you maybe
do or say the thing that you wanted to do
or say.
Speaker 4 (33:29):
So I want you to.
Speaker 3 (33:31):
Have, like you know, the the chance now to maybe
talk about what you want to talk or just to
you know, give us the points, the important points you
want to pass m.
Speaker 5 (33:44):
So you don't have any questions, right, and you're just
doing this because you are not more creative.
Speaker 8 (33:49):
Yeah, that's yeah, I can vouch for that. Yeah, it's
a little bit that I think.
Speaker 1 (33:54):
I think Shi feels like we pulled it off the
rails and we didn't we didn't get to hear your message,
and we want to make sure the listeners hear your message.
Speaker 2 (34:02):
Yeah, am I wrong?
Speaker 4 (34:03):
Yeah, That's what I meant.
Speaker 6 (34:04):
Okay, Okay, well.
Speaker 5 (34:08):
A couple of things I think, as you said, uh,
just use funcial pramming and injury X redex and all
the stuff. If you like it, you don't like it,
and you don't feel comfortable with that, just don't do it.
I think that that's that's uh the technology. It's just
to get the best of it. If you're not getting
(34:30):
it or you're not getting the best of it, just
don't do it. Just do whatever you want and do
you think it's right. If you don't like angler, you
can use view yes, or backbone or whatever.
Speaker 7 (34:43):
I highly recommend backbone. I highly recommend that tame here.
Speaker 8 (34:47):
So that's the bone back for life.
Speaker 1 (34:50):
I was on the View Reduced Documents the other day
and they had a statement they said, this is like glasses.
You'll know when you need it, and so if you
don't know you need glasses, then you don't need I'm like,
no one, none of us are like, I don't know
if I need glasses, Shack go buy glasses.
Speaker 8 (35:11):
Like no, no.
Speaker 2 (35:11):
Like.
Speaker 1 (35:12):
I hit thirty nine this year, and this was the
first year I was like, I need a gentleman needs glasses.
Speaker 3 (35:18):
I read the same thing, and I have a problem
with that because people are usually afraid that when you
will know, it will be too late, you know, so
they always have to figure out if I should invest
in this technology or framework whatever or library and to
study it now before it gets too late. And then
I'm I'm in scale and I cannot dog, I cannot
(35:39):
change my code because it's too messy and all that stuff.
Speaker 1 (35:41):
Yeah, it's a balance, right, like you have to balance
the the FOMO or the you don't want to write
legacy code, right. I think reducts is unique because it
has so much and I know that the angie X
team when.
Speaker 2 (35:57):
I hear this is gonna love. It has so much
boiler plate that.
Speaker 1 (36:02):
I think that you do need. Yeah, Brandon loves that part.
Just so everyone knows. Tweet him about it if everyone
wants to tweet Brandon and yeah, hashtag Brandon mentioned Brandon
say thanks for the hashtag, boy. But no, I think
that there is you need to ask a couple box
(36:23):
of questions to make sure it's worth it, because when
it's worth it, it's worth it. But I think there's
a lot of the time that it might be over engineered, right, Like,
no one wants to strap a lawnmore to the bottom
of your teslattle more you're a.
Speaker 8 (36:37):
Fire Yeah wait, like you could do that?
Speaker 2 (36:40):
No, you can, but you no one wants Joe, Joe, Joe,
back it up.
Speaker 7 (36:44):
I'm getting excited now. I know somebody who just bought
a Tesla and I have a lawnmower.
Speaker 2 (36:50):
Well, don't do it, Joe.
Speaker 8 (36:53):
You could do it. No, you could do I could.
Speaker 2 (36:55):
There's a time when it's.
Speaker 1 (36:57):
Like, okay, guys, the only feasible way to manage this
is to put the the lawnmower onto the Tesla. Like
there's a scenario where that's someone is gonna say that
before the world ends.
Speaker 8 (37:06):
But it's not. It's not listen, yeah, like.
Speaker 1 (37:11):
Like there's a scenario where that's a viable solution and
no one has a smile on their face, right, But there's.
Speaker 2 (37:19):
But there's a lot of scenarios I would even argue.
Speaker 1 (37:22):
More where it's okay to put a bully in somewhere
else besides like in the in Therx store.
Speaker 2 (37:30):
And so that's all we're saying.
Speaker 1 (37:32):
And the glasses, despite Shy being a contrarian, the glasses
example is a good example.
Speaker 2 (37:39):
Like everyone understands it. Like I don't know if I
need it.
Speaker 6 (37:42):
Some of me.
Speaker 1 (37:43):
I came on Twitter and they said, hey, this is
not a good example because glasses at leaks fix something
and I don't read like there are some people that
that disagree with it still, so like I'm just having
fun roast over. No know, hey, Twitter taught me this.
I didn't teach this. I'm not saying I would never
(38:03):
say that. Twitter said that.
Speaker 2 (38:05):
I would just asking the question.
Speaker 1 (38:07):
Yeah, no, I'm not saying asking the question just because
I said it doesn't mean I support it.
Speaker 2 (38:13):
You know.
Speaker 10 (38:13):
But now hold on, what about the scenario where I'm
building the next Facebook. In that case, right I need
I need to write, yeah, yeah, I need it right
off that right, I'm building the next Facebook.
Speaker 7 (38:28):
I don't know if you need this, you need it.
Speaker 3 (38:30):
You should, you probably should implement you know what you
said before that State. It used to be about variables,
you know, putting values inside of viables, and now it
became just like this ward, the complicated ward. There's another
aspect that people don't talk about a lot. I feel
when talking about State is cashing. You know, that's a topic, right,
(38:55):
that is very very hard, Like I don't know those
to talking about State because if you think about the
stores in nj X, it's a cash layer, okay that
you could like, you know, use and then you have
other questions do I need a cash layer, okay in
(39:17):
that scenario, do I need it anyway? Or do I
need always the fresh data from the server and all
that question that people don't talk about that enough, I feel,
But that's a topic for maybe a different episode.
Speaker 1 (39:31):
Yeah, I think that cash is something that is helpful
in some scenarios and it makes other apps worse because
cash means you're trying to keep data around for more
than temporary purposes, and you can end up with a
lot of stale data unintentionally, And so if you're going
to cash, you have to have an effective casing strategy otherwise,
(39:55):
like probably with some sort of server push notifications telling.
Speaker 2 (39:58):
You update the cash. Otherwise you're gonna have still data
and stuff. So I think a lot of people look at.
Speaker 1 (40:04):
NJRX erroneously, and I don't. NNGRX wasn't built to be
a client side database. It's not meant to get the data,
put it in there, and then never ask for it again.
It's only meant to be a place where you can
concurrently serve the same piece of data to multiple people
without worrying if they have different copies. But it's not
necessarily meant to be a cash so I think cashing
is a completely different topic separate of NJRX. In my opinion,
(40:26):
I think I think you could solve cashing with NJRX.
Speaker 2 (40:31):
I think you could put it into the store.
Speaker 1 (40:33):
But every app is so different, every need for cash,
Like if I if you were selling donuts, your cash
is so much different than if you're if you're selling
stock options, right or like real time appropriate, because I mean, well,
donuts are static, like they're not going to change, right,
Like so your cash?
Speaker 16 (40:53):
Yeah, the donut like shot you've never had a donut
I ate on and then it changed, and I'm going
to asking why anyway.
Speaker 3 (41:04):
Okay, Okay, forget about the cash. Okay, that's a different topic,
a different episode. I see like people, Okay, yeah, you
could catch it with this plug in. And then it
becomes like, because it's sort of a repository, you have
like one giant object that is the store, which has
lots of properties on it, which is a giant, big store,
which is an anti.
Speaker 4 (41:22):
Pattern if you think about it.
Speaker 3 (41:25):
Okay, a large, large object holding all the stage. Where's
the single responsibility.
Speaker 1 (41:30):
It's even more of an anti pattern if you realize
that it keeps a copy to every old version of
the data as well. Mm hmm hashtag redox tact tools hashtag.
Speaker 3 (41:41):
So okay, but there are good things that we could
take from it, and that's what I wanted to investigate
in this episode.
Speaker 8 (41:51):
Like when you say, what do you mean and X like.
Speaker 3 (41:54):
Like the patterns, like the functional aspects, the functional aspects.
Let's say, okay, here's one benefit that I see two
functional way overwriting okay, testing okay, Like if you have
a functional like a service, or let's say you have
like a pure functions, it's much easier to test it.
(42:17):
Then if you have like a state mutating kind of thing.
It's not that that is not possible to test, but
pure functions are super easy to test and to understand.
So's that's one direction that using a pattern like n
GX maybe drive you in the reducers to make them
(42:38):
pure functions and they're easier to test. That's one benefit
that I see to the functions. That's why I wanted
to investigate. That's why I asked these questions to get
a better understanding what are the benefits. Maybe if I'm
not using an gr X, I could still take these
benefits into my projects. Right, So do you see any
other benefits like these that our listeners could take to
(43:02):
their project.
Speaker 1 (43:04):
Ng X has a ton of good things, Like it
has memoized pipes streams right, like, so your streams are memoized,
meaning it's not gonna fire more than necessary.
Speaker 2 (43:14):
So there's a there's an insane amount like when you
turn on the push on push.
Speaker 1 (43:19):
For change the text of strategy and an angular component
with memoized streams, that's pretty performant and there's no real
way to deny that. And so there's a lot of
really good things that it teaches you. It teaches you
like if you use the facade pattern that Thomas Burlison
talks about on with NNGX, you end up with a
really nice API around your store and teaching people how
(43:41):
to write APIs.
Speaker 2 (43:42):
Around their data access layers really valuable.
Speaker 1 (43:44):
Like, so it actually teaches you a lot of insanely
good patterns.
Speaker 8 (43:49):
And when you know you need it, it's like.
Speaker 1 (43:53):
The most effective way to have highly concurrent, highly shared data,
Like I can't think more easy to trace way of
coding that up on highly concurrent data.
Speaker 10 (44:03):
So did you One of those examples in there was
that an example of how happen to deal with the
complexity at ADS teaches you good things?
Speaker 8 (44:15):
Is that?
Speaker 10 (44:15):
Is that a mean the facade pattern, that's like, I'm
dealing with the complexity I'm doing I'm I'm I'm working
in spite of it. That was that seemed like that
was one of your examples there, right, Like no, I wasn't.
Speaker 1 (44:28):
Yeah, I mean what you're saying is not untrue, but
that's not why I was saying it.
Speaker 2 (44:33):
Like, because you can write in your X in.
Speaker 1 (44:35):
A way where you've broken the log demeter and now
your component knows too much about the store, right, and
like that's crazy. Or maybe you take the selector back
into your component and then you start making immutable streams
in your component when really that should be up inside
of a service so that other people can reuse the
same logic.
Speaker 2 (44:53):
You know what I'm saying.
Speaker 10 (44:54):
And so hey, this is a pretty advanced episode, but
still it might be good to do a quick definition
of law demeter.
Speaker 7 (45:00):
Finty name dropped it.
Speaker 1 (45:03):
It's just trying to draw fences around like pieces of
logic and keep them reasonable in themselves so that you
you don't have one thing that knows too much about
it's it's environment or a component knows too much about
the store.
Speaker 3 (45:19):
A good example for it if when you find yourself
calling an object like a service, get this other service.
If it has a method that gets you another object,
and then you use and call a method on that
other object, this is breaking the law of demeter because
you should have just like a you know, function that
(45:40):
does something and don't get you another object.
Speaker 4 (45:43):
You should inject this object if you need it.
Speaker 1 (45:45):
Yeah, Lucas, and actually I learned this from Lucas and
uh Lucas rouble key.
Speaker 2 (45:51):
Everyone knows, I mean, and he's great, and so it's
really important.
Speaker 1 (45:54):
I think there's a there's a ton of good stuff
to even if you're like I don't need injects, there's
still a lot of patterns from it you should be following.
Speaker 2 (46:01):
And I'll all stand on that hill.
Speaker 5 (46:04):
I think that, Well, there are a lot of things
about ins X about using anji x in your project.
For me, one of them is that if you're working
in kind of big teams, it's going to be very
used to introduce new members because when there is there
(46:25):
is a lot of documentation. There is good a lot
of good examples on internet. Once you have learned how
anti X works to use anterior X. It's it is
maybe you have to write this boilerplate that it's not
boiler plate actually, but boiler plate, okay. And the thing
(46:45):
is that when you have learned that, it is very
easy to to you know, to call service and you
know exactly how the data flows, which is this is
you know, every time that you heard about redex, you say,
what the hell they mean when they say how the
data flows, and you say that sounds like it bullshit, right,
(47:09):
So the thing is it's it's that it's not because
you know that when you call an action from your view,
that action is going to you know, it's going to
be captured or get from on the effect, and then
on the effect you will.
Speaker 6 (47:29):
Call to a service. That service will do some process
or whatever and return you know, value to the defect
and the effect.
Speaker 5 (47:41):
Will return a new action. So you can do this
interactions with your view. So the good thing about that
is it's because because.
Speaker 6 (47:52):
The flow is so it's so clear.
Speaker 5 (47:54):
So you call the action, it goes to the defect,
from the defect to the service, from the service to
the fact back and from the fact it goes back
to the UI because that flowed so easy to understand
when you have done it like a few times, because
it is easy when you have worked with that for
a while.
Speaker 6 (48:14):
It's easy to you know, to put some stuff in
the middle.
Speaker 5 (48:18):
So for example, what we do is we are using
some a thing called decoders and disney coders.
Speaker 6 (48:25):
It's a library that we created, which what.
Speaker 5 (48:28):
It's doing is that when we do a call to
the API, we use disney coders to decode the response
from the server, and if the response from the server
is what we expect, then we return as success. Otherwise
return our failure. Where we are doing that because sometimes
there are bags introduced in the API that can crush
(48:51):
the UI, and with those decoders we can prevent that.
And that kind of things are very easy to understand
if you so if you are following that architecture and
patterns are good because force you to do the things
in bangue. So there is not going to be a
mother of choice of this developer or this order developer.
(49:13):
You know, you're going to do this in that way
because it's how you should do that, because it's the
proper way, and that's it. So it's going to be
easy to understand for everybody. I'm comfortable with that. I'm
comfortable using patterns and libraries and the good things.
Speaker 1 (49:30):
All Right, we're late in the show, so Ral, if
anyone wants to reach out to you, have any questions
for you, where can they find you?
Speaker 2 (49:37):
On Twitter?
Speaker 5 (49:38):
On alcraft which is E L E C A as
H on Twitter with the same user they will follow
phone me on GitHub too, and probably other networks.
Speaker 1 (49:54):
Okay, cool, Well, thanks for coming on, Thanks for letting
us brande you with questions and for helping us dive
into functional programming with NJRX and with our Yes, it's appreciated.
Let's go, let's move in the picks. Does anyone want
to start the pick section? Yeah?
Speaker 3 (50:10):
I want to recommend I tweeted about it today and
also let talk by Steve Freeman, who is one of
the goose, the growing object or in the Software Guided
by testbook, which gave a lecture two years ago about
TDD and how we meant it to be. So that's
(50:34):
uh that I will put the link and that's it
for me today.
Speaker 1 (50:39):
Perfect, Joe, you want to go, Yeah, I'm gonna pick
type script.
Speaker 7 (50:45):
I like, yeah, type God's pretty cool.
Speaker 10 (50:48):
I started like playing around with a few things, and
I was looking at some computer science stuff and I
don't know if any of you knew this. I'm gonna
anybody who knows this, I'll buy you a swig. Did
you know that typescript supports tuples? Yep, you did you
get a swig? No, they're tuples. It's it's also gift
(51:09):
not twops.
Speaker 7 (51:11):
I've heard it both ways.
Speaker 4 (51:13):
That stupid.
Speaker 2 (51:13):
That's what the Jiff people say, Joe, that's what the gif.
Speaker 7 (51:17):
That's what the Jeff chef.
Speaker 10 (51:21):
Anyway, Typescript supports them tuple tuples, and I did not
know that until I was like looking around in the
corner anyway. So type actually pretty cool. What I like
about it is it's fairly easy to like learn on
top of JavaScript, and there's really not that much you
learned to need to learn to be pretty good at it.
So I actually did throw together a quick little like
video lesson on five essential lips lessons for top typescript Competence.
(51:45):
So if you google that five Essential Lessons for Typescript Competence,
you'll find it.
Speaker 7 (51:48):
I put it up over on Thinkster, but it's free
to the public.
Speaker 2 (51:52):
Type script pipescript all right, I might take a pic here.
I'm at two picks today. Okay.
Speaker 1 (52:01):
The first pick is the company I'm working with, Hero Devs,
is launching a new conference. It's called rx Just Live.
It's gonna be in Vegas on September fifth and sixth.
Speaker 6 (52:11):
Uh.
Speaker 2 (52:12):
The CFP is opening tonight, all RXGS conference. If you
want to go check it out.
Speaker 1 (52:16):
It's RxJS dot live and you can go on Twitter
rx just Live the Twitter account.
Speaker 2 (52:22):
Do a follow there to.
Speaker 1 (52:23):
Follow for announcements for the CFP for tickets. Tickets go
on sale by the time this happens. The CFP and
the tickets will already be on sale by the time
this podcast goes out. So anyway, if you're out there saying, hey,
I need to get better at this rx stuff.
Speaker 2 (52:35):
I need to understand streams and observables and these patterns.
Speaker 3 (52:38):
And dude, that's just like the whole world.
Speaker 8 (52:42):
Yeah, I know.
Speaker 1 (52:42):
But if you're if you want to come, it's a
first year conference.
Speaker 2 (52:46):
It's gonna be a lot of fun.
Speaker 1 (52:47):
There's gonna be a lot of you know, Podwazaki, Ben
Lesch people there that are They're gonna teach us and
we're gonna spend a couple days of community learning So.
Speaker 2 (52:54):
That's my first pick is RX Just Life. Second pick
a book called The Go Giver.
Speaker 1 (53:00):
I read it and I had a moment where it
added some clarity. And I read a book, a small
book like this about a decade ago that changed me.
And as I was reading The Go Giver, I could
tell this was going to change the way I approached
a lot of things. And as I read it, I
started thinking about some people a lot of you guys
will know, Like I started thinking about Joe Eames, I
(53:23):
started thinking about Jesse Sanders, I started thinking about Jorge
Kano and just people that give really endlessly and like
I'm amazed at how their giving makes me want to
be a soldier for them.
Speaker 2 (53:38):
And this book was like, hey, when.
Speaker 1 (53:40):
You give people, people are on your team now and
they love you and they're looking out for your And.
Speaker 2 (53:46):
So it's called the Go Giver. It helps you put.
Speaker 1 (53:49):
Some terms around all the giving that you do. You know,
certainly Hires gives a lot to the community. Hi Rez
would be part of this giver category. So I wanted
to just put it out there for people about giving
and how to kind of grow as an influencer.
Speaker 2 (54:02):
Is called the Go Giver and you can check it
out on audible. It's only about three hours. So those
are my two picks this week.
Speaker 3 (54:07):
By the way, you're one of my inspirations, Frost, forgiving
from seeing the behind the scenes of Energi Coon and
how much you put an effort to give back to
the attendees.
Speaker 8 (54:18):
So just know that.
Speaker 2 (54:20):
Thanks man, appreciate it. Well, you want to take a
chance at some add some picks.
Speaker 5 (54:25):
Yeah, obviously I use this this thing called quick time
dot io.
Speaker 6 (54:31):
I don't know if you know it.
Speaker 5 (54:33):
This is a great tool where you can transform your
you know, your a Jason files to interfaces and so on.
It is very very useful and using it a lot
and I like it a lot. And the other thing
that I will like you it's my my friends at
a Grid.
Speaker 6 (54:51):
They are great. I don't know if you know about
the ag greed, but age Grid is the best grid
in the world, and I love the guys behind it, yus.
They are very very very very nice.
Speaker 7 (55:05):
Second that.
Speaker 6 (55:08):
And that's it. I think that those are two very
good things.
Speaker 7 (55:13):
Cool.
Speaker 1 (55:14):
Well, thanks for coming on everybody, Thanks for listening. If
you want to reach out to us, go follow us
on Twitter, Angular Podcast and we will be tweeting some
new announcements from there going forward. So thank you and
we'll catch you all next time.
Speaker 6 (55:27):
Thank you, rool, Thank you everybody,
Popular Podcasts
CrimeLess: Hillbilly Heist
It’s 1996 in rural North Carolina, and an oddball crew makes history when they pull off America’s third largest cash heist. But it’s all downhill from there. Join host Johnny Knoxville as he unspools a wild and woolly tale about a group of regular ‘ol folks who risked it all for a chance at a better life. CrimeLess: Hillbilly Heist answers the question: what would you do with 17.3 million dollars? The answer includes diamond rings, mansions, velvet Elvis paintings, plus a run for the border, murder-for-hire-plots, and FBI busts.
Crime Junkie
Does hearing about a true crime case always leave you scouring the internet for the truth behind the story? Dive into your next mystery with Crime Junkie. Every Monday, join your host Ashley Flowers as she unravels all the details of infamous and underreported true crime cases with her best friend Brit Prawat. From cold cases to missing persons and heroes in our community who seek justice, Crime Junkie is your destination for theories and stories you won’t hear anywhere else. Whether you're a seasoned true crime enthusiast or new to the genre, you'll find yourself on the edge of your seat awaiting a new episode every Monday. If you can never get enough true crime... Congratulations, you’ve found your people. Follow to join a community of Crime Junkies! Crime Junkie is presented by audiochuck Media Company.
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.