December 26, 2024 • 55 mins
Joaquin Cid is an Argentinian developer who has built a plugin for NGXS state library that allows developers to connect to Firebase and have their queries automatically import into NGXS. Further, it also allows them to define actions that will update their datastore when triggered.
The new Adventures in Angular panel dives into the ins and outs of using NGXS and Firebase to build rich applications with Angular and these technologies.
Links
Picks
Become a supporter of this podcast: https://www.spreaker.com/podcast/adventures-in-angular--6102018/support.
The new Adventures in Angular panel dives into the ins and outs of using NGXS and Firebase to build rich applications with Angular and these technologies.
Links
- Firebase + NGXS, the perfect couple
- NGXS loading spinners and actions executing
- GitHub | ngxs-labs/action-lifecycle-hooks
- GitHub | ngxs-labs/firestore-plugin
- GitHub | angular/angularfire
- Twitter: joaquin cid ( @joaqcid )
Picks
- Charles- Who Not How
- Charles- As a Man Thinketh
- Joaquin- Newell's Old Boys
- Joaquin- NGXS
- Richard- Chania, Crete, Greece
- Richard- My team (Dodo) from Optimal Systems
- Richard- Building Performance Optimized Web Apps with Angular and Firebase - YouTube
- Subrat- NestJS
- Subrat- Lucifer
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:00):
Welcome to Adventures in Angler, the largest and most popular
podcasts in the world about web development with Angler, This
show is brought to you by Void and top Endavs.
Unvoid provides high quality design and software development services on
a client friendly business model. Unlike all other agencies, Unvoid
(00:22):
allows clients to only pay after the work is delivered
and approved. Visit unvoid dot com to learn more and
reach out. If you know a company that needs more
professionals to help with design and software development, that's u
n vod dot com and top and Davs helps you
(00:44):
stay up to date with cutting edge technologies like JavaScript, Ruby, Elixir,
and AI. Visit topd davs dot com to join their
AIDV book camp, weekly community meetups and access expert tutorials.
Lucas Paganini, founder of on Void and host of this podcast,
(01:04):
Thank you for tuning in. Let's jump into the episode.
Speaker 2 (01:14):
Hey everybody, and welcome back to another Adventures in Angular.
This week, on our panel, we have two new panelists.
We have Richard Stourle. Hey, hey, hey, you want to
remind people who you are because we haven't had you
on for a few weeks.
Speaker 3 (01:30):
Yeah, my name is Richard.
Speaker 4 (01:31):
I am a front and leave developer for a company
called Optimal Systems. I am based in Berlin, Germany, originally
from Johannesburg, South Africa. And yeah, I'm really loving the show.
I'm a big fan of Anglia Adventures in Angular and yeah,
I'm happy to be back again.
Speaker 2 (01:53):
All right, and just to keep it multinational. We also
have another new panelist we have and you can tell
me if I say your name wrong too. It's super Nichra.
Speaker 3 (02:03):
Yeah, yeah, it's correct. And Hi guys, I.
Speaker 2 (02:05):
Do you want to remind you of who you are?
It's been a few months that you've been on.
Speaker 5 (02:09):
Yeah, so I'm as Stol, I'm Super Wednister. I'm from
India and currently I'm in Bangalore and I'm a full
stack developer. Currently I'm working in society General and I
think once in last year I was in the show
at a as a guest and now I'm very happy
(02:31):
to be as a panelists.
Speaker 3 (02:32):
It will be a wonderful experience.
Speaker 5 (02:34):
And I had a I have a YouTube channel that
is on basically on Angler and that is fun of Heuristic.
Speaker 3 (02:42):
So everything is going on together awesome.
Speaker 2 (02:46):
I'm Charles max Wood from dev chat dot tv. Maybe
I should do a little intro too. So I started
the show with a bunch of friends of mine, what
like seven years ago or something, And yeah, we've been
doing the show for a while. I kind of handed
it off some other folks wound up taking it back
over January timeframe. Shy and I were doing it for
(03:06):
a while. I interviewed a few folks like Richard, and yeah,
I wanted to bring some more people back in and so, yeah,
I'm excited to be talking to some new friends. And yeah,
we have a guest today. That's walking, is it seed?
Speaker 3 (03:21):
Yep?
Speaker 6 (03:21):
Yeah, that's good. That's good.
Speaker 3 (03:23):
That's good.
Speaker 2 (03:23):
That's good. That means I said it wrong. Why don't
you go ahead and introduce yourself and we'll dive into
our topic here in a minute.
Speaker 6 (03:30):
Okay. Yeah, So I'm a full stack developer. I'm currently
working as a freelance I'm from Rosario, Argentina, and I'm
currently living in Buenos Aires. And yeah, I've been writing
a couple of articles around ngccess and Firebase, which I've
(03:50):
also been working on for the last few years. And
last year I wrote a plugging plugging with the help
with the angi Exist team, applying that connects ng access
and Firebase, and yeah, happy to be here. Yeah, hopefully
this will help everybody who's listening.
Speaker 2 (04:10):
All right, well, I'm going to start real basic for
some of our newer listeners, newer to Angular and the ecosystem,
and then we can just go as deep as we want.
Do you want to just explain real quick what nng
access is and what Firebase is and then we can
just go for it.
Speaker 6 (04:25):
Okay, yes, So first I'll start with Firebase, which is
a back end. Yeah, it's a platform which helps you
or provides you with mainly a database for you to
build apps, but not only a database. It also provides
you authorization, server less functions or yeah, ability, capability to
(04:52):
run server less code, and it also has a lot
of other tools that makes Yeah, it makes everything you
need to build an app very easy and very accessible.
So you can spin up an app really really simple
and really quick with Firebase. Nd Axcess on their hand,
(05:14):
it's a library state management library that it's within the
Angler ecosystem. It is based on the redax pattern, so
it's kind of similar to n GRX, but it's not
like ANGI rex it has it's different and yeah, so
it basically allows you to manage the state in your
(05:39):
application in a more structure way. It allows you to
organize how you handle the state with actions and stuff
like that. And yeah, basically when you're starting, when you're
building apps, you'll normally get to a point where when
you've got going to need to use a state management
(06:00):
library as you wrap growth and well, NGS is one
of the options out there is the one that I prefer. Yeah,
I don't know if that kind of gives an idea
about purpison in jexcess.
Speaker 5 (06:15):
Yeah, what I think, what what I got? I think
it's for the everyone as well. It's a little new,
newer in market, I guess, And it's kind of a
similar concept as gid X as you tool, but it
has what I'm just seeing here, it has some less components,
so let's less to code.
Speaker 3 (06:38):
That's a good thing.
Speaker 6 (06:40):
Yeah, Yeah, one one of the differences, or I guess that, Yeah,
the main difference between ngxs and and gi X is
that it was built to keep simplicity, like with simplicity
as the first thing in mind. So and also yeah,
idea about the NGXY is that it was or it
(07:03):
feels that it's similar to everything else that you do
in Angular. So in Angular you have classes and components,
and in NGXS you have your state which is also
a class, and you decorated with a state decorator, and
you have your actions, which are also functions that you
(07:24):
decorate with the with an action decorator. And then within
your state class you can inject other services the same
way that you inject services in your components. So it's
basically pretty. You feel that you're writing similar code to
everything else you're writing your Angular applications. And the other
(07:49):
main difference with ji X is that since you can
have a sync functions as a first citizen of NNGXS,
you don't need what in any direct arects they call effects,
which are things that you have to connect like in
a separate file or yeah, you have to configure it
(08:10):
in when. When you have when you call an API
and all that. So in JXS you can directly inject
your API in a state class for example, and then
create an action that it's actually a promise or unservable,
so that means that it's a synchronous and the library
(08:31):
will all handle that synchronous for you, so you don't
have to worry to subs, subscribing and all that. So
the livery will do that for you, and yeah, that
for me, that that's that's something that Also it makes
things easier because you can have all that in the
same action, so it's easier to understand the code and
(08:53):
all that.
Speaker 4 (08:54):
So yeah, I think so, I think that's a very
good comparison. And I'm very glad that we addressed the
elephant in the room because I think I had one
of those questions lined up as well, and it would
be remiss if we didn't ask that question. But you
also mentioned some very key differences there. But my question
would be based on your experience and your humble opinion,
(09:18):
and I presume you've used your ex as well, even
though you're a core member of the NJXS team. Would
you what would be a good use case for using
this tech that you you wrote an article about so
using Firebase and NJXS.
Speaker 6 (09:35):
So yeah, so basically, this this plugging came out, came
out as an idea for me because I was I
started working on a project and we started working with
firebase right as a back end, which also Firebase another
cool feature is that allows you to build reactive apps
(09:57):
right since fire Base lets you connect with the query
to the back end database. Every change that occurs in
the database is pushed to their clients that are connected,
without clients needing to pull for every time they want
new the new the latest data let's say, or the
(10:19):
latest value. So all the all the new new changes
or the new values that happen in the database are
pushed to the to the clients that are connected to them.
So I started working on a project with Firebase. I
initially started using just the Firebase library, which is a
(10:42):
service that you can inject in your components. And then
as my app grew, I had to start doing something
with the about the state in the applicacy is becoming
to conerson to understand how everything was connected and all that.
And at that point I made a research on which
were the different libraries that I could use to manage
(11:07):
state and so the three that I liked more ng
X which was the most popular, one, NGXS which actually
a friend of mine told me about that one, and
then the album was a Kita. So what I did
is I created the same feature with the three libraries,
(11:28):
and I ended up deciding for NGXS because that was
the one that I liked the most, and that I
felt that was the simpler and the one that would
help him better in my project. I mean if right
now or actually after that, I wrote the plugging which
(11:49):
also improved further or make things easier even easier between
ngxcess and Firebase. I don't know if there's something such
a connect between n g r X and Firebase. I
honestly didn't make a research on that, but definitely if
if your angler application has Firebase, if you want me,
(12:13):
if you need to implement or to add some state
management in your application, I would say give this plug
in a try, because definitely you're going to feel that
things get easier for you. Yeah, you have, you have
some you have. You will have a learning curve until
(12:33):
you figure out because once once you start using a
state management lebrary like ng Access, but most of them
are similar in that way, you start dispatching actions to
get things done. You modify the state on the in
the in the state class or in the reducers in
case of j X, and then you select slices of
(12:57):
state right that that is the one that you present
to your components or that you're using your components. So
once you have once you learn that. The thing about
this plan is that makes everything feel in the same
way or work in the same way that you would
normally use your NG access state. So you can use
(13:20):
or you can combine data from different APIs or even
the state that you have in your app with the
one that is coming from Firebase, and merging that data
is super easy because everything is in NG access, so
you can combine that data very easily. And yeah, that's
(13:40):
kind of the main the main advantage of using this planning.
Speaker 2 (13:45):
So I guess what I'm trying to figure out is
and I apologize if you cover this in your article
and I just missed it, or if it's covered in
the documentation for your plugin. But so if I have
data that I just want to live in my app,
and I have data that I want to live in Firebase,
is there a way to differentiate that and how does
that work?
Speaker 6 (14:04):
So basically, when you use Firebase, maybe maybe I should
have started I should have started there. So when you
use Firebase, you need the service that the angler fire
library has or provides, and with that you connect to
the database. So when you can create a connection to
(14:25):
the database is when Firebase starts sending your data with
the from the party that you you wrote, right, and
then you can make updates or create new documents and
that will be of course that that will be sync
into the back end database. So essentially, if you're making
(14:46):
the query, you want that data to live in your app.
If you want that data to be in your app,
it's and you're using estate management, it's better to keep
in your state management lab or along with all the
other app data, right because most most of the times
are going to need to make connections or merch, make
(15:09):
merches between those that data. So let's say you have
a form or you have I don't know, some some
UI data something like that you're keeping in your state
in any access, and then you bring data from Firebase
for example, for example a list of users or whatever.
Let's say you have a filter and the list of users.
(15:30):
So filtering that it's super easy because you have all
the data in ang access and you can then make
the filter with in the same data. Said, you don't
have to make complicated connections between the Angular fire service
and the the data that you have in your store,
(15:53):
because I mean you can do that. You can do that,
but it's more complicated. You have to are using a
lot of r rx J. Yes, operators, you have to
start doing a lot of other things that, well, it's
more complicated, I guess.
Speaker 2 (16:12):
Yeah. I think you answered my question when you said
that you first set things up with any other fire
and then use this plug in to kind of connect
and you pull everything into n G access and then
n g axcess just looks at it all as data.
Speaker 6 (16:25):
Right, exactly exactly.
Speaker 2 (16:27):
That makes sense to me that that seems simpler too perfect.
Speaker 6 (16:31):
Yeah, yeah, so basically what the plugging does and yeah,
following the same concept on how you use fire Base,
if you don't use if you don't use ngxcess. So
you have a query, So what what this planning does
is fits that query into the n G access model.
(16:51):
So on on ng access, in order to do something,
you have to dispatch an action, right, So what what
you do with this plan is that you connect an
action with a query and the results of that query,
you you connect those with your store the state right,
(17:12):
So basically what will happen is that you will configure
in your state class that when you dispatch a next action,
a action whatever, or let's say we call it load
users that action when you start that action, you're going
to query the collection users from Firebase right, and with
(17:34):
that query starts a meeting results. And we have to
remember that those results are going to be a stream,
so it's not a one only thing. It's going to
be constantly a meeting as changes occur in the database.
Every time a new emission happens, you're going to grab
those results and insert them in your in your store.
(17:59):
The planning is going to do that for you, so
you don't have to worry. So that's that's kind of
the magic that happens is you don't have to worry
about updating the state every time. You just configure the
which action is going to start the querry and how
you're going to update your store with the results. Everything
(18:21):
else is handled by by the by the library.
Speaker 3 (18:24):
That's very cool.
Speaker 4 (18:27):
Yeah, I think there was one thing that I picked
out of what you mentioned. Now, well several things, but
the one that really stuck out for me was you
mentioned that just like just like we have in an
j r X, we've got the effects or the concept
of effects, and you said this is not necessary in ANGIXS,
And I'm just wondering, how do you ensure that, First
(18:48):
of all, where do you handle your ACYNC code and
your side effects, and how do you ensure that your
stay remains your store remains immutable?
Speaker 6 (18:57):
Right? So well, when and energy exist, actions can can
be asynchronous, right. So that means or the way that
you do that is that you from that action you
return either a promise or observable. So the state is
going to be immutable because when you write the action,
(19:19):
there's a context that gets passed to that action, which
is the one that you used to patch the state
or to make modifications to the state, right, and those
changes are going to be immutable. And that's that is
something that that context that gets passed or injected to
you in the action ensure I don't know if that
(19:42):
answers your question, but basically the state is immutable. And
the asynchronous thing about NGXS is just that if we
compare with n gi xis that it includes the effect
in the same action. We can maybe we can image
you need like that because you can have an observable
(20:03):
or a promise and the library is going to handle
that for you. So it's going to wait or to
subscribe to an observable or is going to do then
to a promise let's say and run the next the
subsequent code for you. But the way that you patch
(20:24):
the state or that you make modifications, it's always immutable.
Speaker 3 (20:28):
Yeah, that's that's very neat.
Speaker 5 (20:31):
Yeah yeah, yeah, yeah, go ahead, Sorry, no, no.
Speaker 6 (20:37):
So the other thing about having the bit or having
the future of as synchronous actions is that actions have
a life cycle. So actions get dispatched and actions then
are completed or canceled, and they can be completed with
an error or or successful. So an error can occur
(21:02):
within the action. So you have like different events that
will occur during the action life cycle, and you can
have different states have the action can finish. And that's
also very very interesting because with that you can then
know when an action has started and when an action
(21:22):
has finished, and that's super helpful. Actually, there's another plugging
on ngxaid that it's also very very nice that you
can subscribe to know when an action is being executed.
So let's this is the famous or the yeah, the
very common the loading load the loading feature right rather spinner,
(21:47):
So basically you always want to put a loading or
spinner when when an action or something is going on. Right,
So with that life cycle, NGXA makes it super easy
for you because you can track when the action is
dispatched and start spinning, and when the action has completed,
you stop, so you don't Angie access will handle that
(22:11):
state for you. So you just query when the action
has started and when it has ended. And I think
that in injuries you kind oft do that. You have
to manually like start a loader before an action is dispatched,
and so you have to do another thing right in
order to do that.
Speaker 4 (22:31):
Yeah, I'm actually giggling because, yeah, that's exactly. I remember
my own experience with my team a couple of years back.
We were using an English shop and we use NNGRX
and exactly the scenario that you've just described. Now, yeah,
you had to jump through certain hooks to manage that
what appears to be a very.
Speaker 3 (22:50):
Straightforward and simple scenario.
Speaker 4 (22:52):
But yeah, it's very interesting to hear that that is
manage internality within the library.
Speaker 3 (22:57):
It's very cool. Yeah, I have a.
Speaker 5 (23:00):
Question, like, like, I think you have just explained that one,
so I just want to clarify what I got is correct.
So we basically make make APA calls inside our state
once accident is dispatched, and update the state itself inside
the state. Like in the case of ng X, we
use a reducer and sorry effects and reducer. So here
(23:24):
everything will happen inside the state. Is that correct?
Speaker 6 (23:27):
Exactly? All the gode lives in that state class, so
you can have like the comparison to the reducer in
energy excess. It's an action and within the action you
can call an API for example far Base or whatever
a PA you want to call, and then you can
(23:48):
patch or make the modification to the state. So you
have both things in the same like, yeah, it's called
the action the same code blog.
Speaker 3 (23:59):
Let's say, yeah, so I have one more question.
Speaker 5 (24:02):
So if you check in engie erics, so you store
it mapped with the reducer to change the state of
your of your application. Like suppose I have two three
one user model and one supports some items. Then I
if I want to uproducer, I will use the user
reducer and unto updateight term, I will update use the
(24:26):
item reducer.
Speaker 3 (24:28):
But how it maps here, that will.
Speaker 6 (24:30):
Work right, So when you want to change something, you
create an action. The action can receive a payload. So
let's say yeah, if it's you can dispatch. When you
dispatch an action, you can pass a parameter with values
and you receive that in the action block action code
(24:50):
blog and so as I mentioned earlier, so there's a context.
So I think in you jer x, you have to
return the new value, right, you just returned in the
reducer you read. So in anti access it's a bit
more imperative. So you get a context injected in the action.
(25:12):
It comes as a parameter in the action. And then
with that context, you have a method that is called
patch state, and that patch state is the one that
you have to pass the new value that you want
the state to have so you can perform whatever operation
you need or and when when that patch state is executed,
(25:34):
the store gets updated in a in the middle way,
and all these selectors that depend on that data will
push the the new values to all the components that
are connected to that selector.
Speaker 5 (25:51):
Right, So the selector is basically seen as Watson enngietics.
Speaker 6 (25:55):
Yes, yes, it's the sane.
Speaker 2 (25:57):
So I have to ask this because I have the
guy that touches like every line of code that I write,
and he's a complete idiot, and his name is Chuck
from yesterday, all right, And the only way that I
can keep this guy in line is to write tests. Okay,
I mean chuck from today, he's fine, but Chuck from yesterday.
The guy's more on okay, and he screws stuff up,
(26:20):
and I find his mistakes in the code that I write, right,
because I have to go back and I have to
fix them. And so, but if I write tests, then
a lot of times I can avoid writing some of
these bugs in my code. Not that I ever write
bugs in my code, but how do I test this stuff? Right?
How do I make sure that I'm not writing bugs
in my in my in my stuff right?
Speaker 6 (26:43):
So, and she exists, I mean for testing the actions
and all that. There's so if you go to the
dogs there there is some documentation on how to make
tests with Firebase the plugging. So you're basically you will
have to mock the query right, because what you're doing
(27:06):
is that the library is connecting the query with an action.
So what you have to mock is the results that
the query is going to admit, and how the given
that the store is going to get changes updated or
(27:27):
inserted in the store. So that's kind of what you
would want to test. How the mock the results of
the query that are going to get admitted and what
will happen after that?
Speaker 2 (27:38):
Right the thing?
Speaker 6 (27:40):
So yeah, honestly, there I think there are a lot
of libraries to mock obserbles. You can even create a
behavior subject for example, and use that as the mock,
which is what I do sometimes. If I have to
be completely honest, I mostly use or I try to
(28:01):
use more Cypress to make tests sometimes not a lot
of not a lot of unit tests. And so one
of the things about using or the way that I
like to use this plugging and that I try to
keep the code in my applications, even though sometimes it's
(28:21):
not very easy, is to try to keep it as
simple as possible, right, so, because that is less prone
and it also it's more maintainable. So this library helps
you with that. So and the way that you should
(28:41):
or that I try to use this to try to
be the less complicated as possible. I mean, the common
the most common operations that you would need to do
in your application is bring a list of items from
the database or a specific items from the database. And
(29:02):
so basically your state is going to typically typically look
like have a couple of a couple of connections, So
want to get a list or all of the items
and want to get a specific item, right, and those
the result is going to be stored in that state
(29:23):
and that state class let's call it users for example,
want to get all the users, want to get a
specific user, and they're all going to live in that
state as an array, right, and then you have the
selectors to get active users, to get users that have
signed in last day. And so yeah, that's when I
(29:45):
try to keep the state or yeah, how to write
the code most of the times, right, of course, there
are sometimes that things get complicated because it is what
it is, right, and for that situations you you probably
need to make some tests. Also, one cool feature about
(30:07):
and you ex says is that the selectors are written
as functions, as pure functions, so it's very easy to
to create tests around the selectors. So this is different
from from the library, right, but you can you can
easily inject, so you basically provide the function the set
(30:27):
of results that is going to be your mock, and
then you you expect something and you just write execute
that function. So it's it's super easy to test selectors
in that way. Yeah, so I hope hopefully that that helps.
Speaker 2 (30:44):
No, it makes sense, and I mean it was mostly
the angular part of it, or not the angular part
of it. I was hoping to mark the angular part
of it. Yeah, that's genius check things. No, it was
the fire based part of it that I was trying
to figure out. Yeah, if there was a way to
mock that because I can kind of see Yeah, I'm like,
can I reliably get the right data back and have
(31:07):
it come into my state the right way? And and yeah,
the more I think about that, the more Cyprus kind
of feels like the right level to be testing that
at because essentially then yeah, what I want to know
is maybe at the component level, if I if I have,
if I trigger some kind of action, yeah, is it
going to follow through the system make the query on
(31:30):
the back end, But I don't want it to make
a query because I don't want to go to an in,
run out to Google, and then is it going to update?
Is it going to make the proper updates on the
other end, right, depending on what data gets back? So
I just need to mock that data out, So that
makes sense.
Speaker 4 (31:43):
Yeah, I'm I've got a very So I'm I suppose
there's someone out there listening to this podcast and wondering, like,
whoa Okay, JXS sounds super cool. You know, they can't
wait to jump right in and get thoughted. I guess
my question would be, like, what other common pitfalls people
(32:04):
fall into when starting out with NJXS and what advice
would you give them to avoid them?
Speaker 6 (32:11):
Right? So, yeah, that's that's an interesting question. So my experience,
I think, or yeah, my experience and from what I've
seen in the slack community that JXS has, which by
the way, is very active, and yeah, people ask about
for best practices and all that. Yeah, some of us reply,
(32:34):
or even people that are there, so that's that's very cool.
So I think that basically, or what most of it
happens is that you start writing your your JS code
or your state code with a lot of how to
say it, it's it's I don't want to say complicated,
(32:55):
but because it's like you start doing it very specific
to your to your use case, and over time you
start noticing that you have to keep your state as
generic as possible. So like in the in your life cycle,
you would probably start because maybe your app requires in
(33:16):
some place that you display a product let's say a
product detail, right, and so with that in mind, you
probably create some state for just that product and stuff
like that, right, and then you then quickly realize that
you're going to have to keep the product available for
(33:38):
other places, for other pages, and you're most likely going
to have to load a lot of products. Right that
That's kind of what happened to me and what I've
seen in the in the community asking, right. So with
that in mind, you would probably start your designing your
state to keep one product living in your application, right,
(33:59):
and then you realize that you have it's better to
keep it as an array and create selectors that reflect
what each component needs.
Speaker 3 (34:10):
Right.
Speaker 6 (34:11):
So, so basically I would say that that's one of
one of the main things. It's not designing your state
with the needs of your components. So let the selectors
do that for you because they are super flexible and
very easy to change. And try to keep your state
as generic and as raw as possible, so meaning if
(34:35):
you're going to if you have products, or if you
have users, or if you have I don't know, yeah, invoices, whatever,
So try to keep them as rass possible in the state,
and then let the selectors make the specific give the
specificity for each component that you need in your application.
So that's yeah, I would say that that's one of
(34:57):
the main things. The other main thing is is as
synchronous actions. So I think that sometimes because people is
used to use n g X, they usually follow the
pattern of having a load action and the success or
fail action of that load, and that in nj X
(35:19):
that is glued together with the effects, right, So in
NGXS you don't need that. You can just have the
load and what the load finishes. You will get the
result in the same block of code and make something
or it would fail in the same block of code
and you can do something about it. So the patterns
about that, it's also something that frequently I see it
(35:44):
in that people that people ask ask a lot about.
So in my experience, from what we most mostly recommend
is that you should in jexcess, you should go out
from the or not use that pattern of the three
actions for loading something. You would prefer just keeping a
load action and keep everything within that block of code,
(36:08):
which also makes a lot more sense when you need
to start fixing things or you need to change because
everything is going to live in a single.
Speaker 4 (36:15):
Place, right, Yeah, that makes a whole lot of sense.
Keep your states as generic as possible. And use your
selectors to you know, to get a slice of the
data that you're interested in. It's very cool talk. I
don't know about you, but I'm very I'm itching to
hear you came about how he managed to become a
(36:35):
co member of ang XS. You know, how did you
join the team and what was your journey?
Speaker 6 (36:41):
Like, well, that's that's a very very good question. So yeah,
so it all started last year with the pandemic, so
that that was one good thing that the pandemic brought
for me. Actually, yeah, so since I started using ang
excess in my project, I started participating on Slack in
(37:05):
the community a lot. I have a couple of yeah
questions and suggestions and the team was very yeah, so
they received my suggestions very well. There was a point
I think that I came out with the idea of
writing this this plugging. And at that point when the
(37:30):
core the team leader of the of the core team yeah,
asked me if if I wanted to join to join
the team. So we we kind of work together on
this plugging and yeah, I've been participating on on the
on the team meetings and all that since then. But
(37:53):
basically it was I started, uh actively contributing in slack. I. Yeah,
I think that there were a couple of issues that
came out on the on the enge exist that I
collaborate as well to fix those, and then I started suggesting, yeah,
(38:14):
this kind of plug ins or making a couple of changes,
and yeah, they they liked the ideas that I had,
so in the end they proposed being part of the team.
Speaker 4 (38:26):
Wow, that's that's a very interesting Sorry.
Speaker 5 (38:29):
So how many Yeah, so how many days it took
you to finish? I think it's seeing a lot of
good in pandemic.
Speaker 6 (38:40):
Yeah, I think it's It was around I don't know,
two three months. So the thing is that, or at
least in the process for me, was that I came
up with the idea. I wrote like the first version
of it, which was completely different from the one that
it's out there now, and I that was read that
(39:00):
one to the team leader, which is called Mark whitfelt.
He really liked it. He liked the idea and he
suggested changes to make it more ergonomic and easier to use.
And yeah, since then, I yeah, it was a second version.
So I think that the whole process was around two
(39:21):
three months, But it was not like all the time
working on it. It was a lot of time spent
thinking about it, how it should work. And then when
I finally did the first version and that something it
was possible and it was helpful. Then it was trying
to polish it and make it better and easier to use.
Speaker 4 (39:45):
Cool So do you have any number of terms of
usage of the plug in you? Are you aware of
how it's been used out in the wilds so to speak?
Speaker 6 (39:53):
No, to be honest, no, I know that. I know that,
I know that it has been used, So it has
I have been a lot. There have been a lot
of questions coming to the to the gift repository, So
that's a way of knowing that someone is using it.
The are they We also did an angular session with
(40:18):
Beman and so there was I participated there as well,
and there were a couple of questions about the plugging,
so that also at least interesting about about it. But yeah,
if I have to be honest, I wouldn't know how
many how many people are using it. I guess that
(40:39):
I could look at the downloads, but I don't know
if that's that like completely the usage.
Speaker 2 (40:47):
Yeah, I know the projects, not necessarily people.
Speaker 6 (40:50):
Right, So I know that the ant Excess team lead
uses is used it in one of their projects.
Speaker 5 (40:57):
So yeah, yeah, right, yeah, that's so one question I
was like having, like if I use this one in
my project? So I think you may have covered they
I haven't gone through the plug in, so just asking,
like suppose if I make a call to serve and
somehow might state got update date, but like means my
(41:19):
data got updated, but the state is not and and
at that moment somehow the connection failed, how it managed
the state, like is it will fire away? Fireways will
meet it again if you're if you're without any changes, So.
Speaker 6 (41:35):
You're asking what happens when when the connection fails or
you have your out of connection with Firebase.
Speaker 5 (41:44):
That yeah, But scenario is like suppose your database is
updated but while getting a response, your connection failed due
to internet connections, so that it's handled here like kind
of because that is we are not ready to state
and now we can add one more, right.
Speaker 6 (42:05):
Right, So that's that's the beauty. That's the beauty of Firebase.
And the good thing about using this this plugging is
that it doesn't interfere with Firebase already does for you,
which by the way, it's it's a lot, and it
handles it very well. So the way that Firebase works
is that they initially update the in the client site
(42:28):
locally and then it tries to sink with sink with
the server. It is going to retry until it works.
So basically, basically you don't have to worry about that
because Firebase is taking care of that for you. You
can get confirmations when it actually has updated the database,
(42:50):
but most of the times it's going to you're not
going to need that because your fire Base is working
on a is working like in a law side. First,
you're always going to be updated in in the in
your application. So so it's like when you make an
(43:11):
update for example, you will see reflected in your in
your application instantly right and then it's going to update
it in the back end, which which also that model.
It is very very good to for reactivity in your
application because that's something that I haven't mentioned and I
(43:32):
think it's a very important thing. So with anti Access
and Firebase, you can make and you will make your
application reactive from from the front end to the back end.
Because Angie Access it's also a reactive it's a reactive
state management library and every time something changes in the store,
(43:53):
all the components get senked with the new with the
new value. And in Firebase, every time something change just
in the in the database, all changes are pushed to
the connected clients right away. So you don't have when
every time or after you create a connection or a query,
(44:14):
you don't have to worry anymore about pulling data and
like you have like a two way data to fetch data. Right,
it's already connected and data is flowing through the connections
all the time.
Speaker 5 (44:29):
So buy back to all the get calls. Sorry, so
we can say by buy back to all the get calls.
So in normal application, we used to make a get call,
then put updates and again we'll get.
Speaker 6 (44:42):
So right right, exactly, exactly exactly.
Speaker 3 (44:46):
I think. For yeah, yeah, that's very interesting.
Speaker 4 (44:49):
I mean I've had the pleasure of working with fire
Base in the past a couple of years back, and
I'm sure a whole lot of things have changed since then.
But I mean it's as a platform, I think it's
it's great. I mean you can literally pull together simple
something that is typically not so easy to do by hand,
(45:10):
for example, handling authentication. You've got that fire Store database,
real time database storage, hosting and functions and so forth.
And I've had a pleasure to to play around with
all of those for one of my previous customers, and
I absolutely love it. I think all the points that
you've mentioned today, it's it's all valid, and I would
(45:30):
urge people out there to to give it a try.
But for me, I'm always very curious, like when someone
mentioned something that sounds so good like you have today,
I'm always thinking about maintenance, right, how easy is it
to debug apps that are built with the enge access?
Do you have something similar like redux def tools for example.
Speaker 6 (45:53):
Yes, yes you do, and I would say yeah, I
mean for me, of course, you'll always you always have
to learn right to in order to use your to
use your your new library. Uh there, there's going to
be some learning career. But and the access so since then,
(46:15):
since all the acing actions or acink is allowed in
your actions, you can place debuggers within your block of code.
So it's going to stop there, and that that makes
it easier to the bag. And as far as changes
in your store or how they're there, they are the
state is changing after actions are executed. You can hook
(46:38):
you can use the redax dep tools it's the same,
the same plugging, the chrome plugging, and you will see
changes that happen in your store after each action, so
you can be bag the bag that way as well.
Speaker 2 (46:54):
All right, great stuff. Now I'm going to go play
with it. So we've already burned an hour on this
and now we're gonna go burn more, right of course.
But yeah, before we do that, I'm gonna push it
over to picks because, yeah, we're kind of getting to
our time. I want to make sure that, yeah, we
wrap this up before people have to run off and
do other stuff. So yeah, let's go ahead and do picks.
(47:17):
I'm pretty sure everybody here has done it before except
maybe Joaquin. So yeah, let's let's go ahead and have
Richard do it first. Richard, do you have some picks
for us today?
Speaker 3 (47:26):
Yes, I've got two today.
Speaker 4 (47:28):
The first one is if you remember, Chuck, we spoke
a couple of weeks ago about my pending trip to
Crete in Greece. I, yeah.
Speaker 2 (47:38):
I had a punchels.
Speaker 3 (47:41):
Yeah.
Speaker 4 (47:41):
It was a small little town called Kanya as the
locals call it. But it's just picturesque. It's so beautiful
and tranquil. Yeah, and I had a chance to go
and recharge my batteries so to speak. Came back feeling
super refreshed and ready to rock and roll again. So yeah,
if you do get an opportunity to travel, I would
(48:02):
definitely pick that up. Let me know, if you want
to know where all the cool beaches are at, I'll be.
And then the other one is So the funny thing
is the company I work for, all the different teams
have names of birds, and my team's The name of
our team is called Dodo. If you know of this
(48:23):
extint bird called Dodo. But yeah, I just want to
send a shout out to my team. They're they're fantastic.
They're great bunch of boys and girls and we work
great together. So yeah, I just want to say shout
out to them. Awesome super yes picks for us.
Speaker 3 (48:39):
Yeah yeah, yeah.
Speaker 5 (48:40):
So first one will be technical picks and that I
recently came across. You're back in frame work for no Jazz.
It's a nest Jazz. It's not next, but I was
also a little kind of at the begining. So it's
Nest Chess. And the true cool thing is it's like
(49:02):
you can say, seventy to eighty percent similar ads angler
We have services, we have models, we have everything. So
it's a pretty gift for Angler developer to develop the
back end, and every Angle Angler developer should check it
once because again, be full start developer with that. And
(49:25):
the second one will be a Netflix city that I
think everybody knows is Lucifer.
Speaker 3 (49:31):
I'm watching that right now, and that's all it is
for me this week.
Speaker 2 (49:35):
Awesome. Yeah, and if you could put your links to
your picks in the chat, then we'll make sure we
get them in the show notes. So I'll throw in
my picks here real quick. Now. I've picked this on
like every show because it's still bending my brain. I
am so I listened to the book. Now I'm reading
the book. I probably listen to it again here soon.
It's called Who Not How. It is very much more
(49:55):
of a business book, I guess, than a technical book.
But I'm finding it applicable in a whole bunch of
areas of my life. So if you're trying to get
more done in life, then this is the book for you, Okay,
and let me just give you the rundown real quick.
So for me, I'm working a full time job. I'm
trying to run a podcast network. I have five kids.
I trained for a marathon that I did not run
(50:16):
on Saturday because my nephew got me sick. I will
spare you the gory details because it's kind of gross
how some of this stuff manifests. But anyway, so, yeah,
you know, I have all this stuff going on in life,
and I was trying to do everything myself, and to
a certain degree I still am. But I started reading
(50:36):
this book and I realized that I don't have to
do everything myself. So I've started bringing people in to
do more of this stuff. And yeah, some of it
I feel like, oh, it's not going to get done
the way that I want or exactly how I want
or as good as I would do it, But holy crap,
I cannot do it all myself. And the other thing
is is the more I free up myself from doing
(50:59):
the things that I don't have to do, the more
I can spend time working on the things that I
do have to do, and especially the things that allow
me to pay the bills at home and pay the
bills for the people that are working for me here
in the podcast network and stuff like that. If you're
my kids screaming, I'm really sorry. So anyway, you get
(51:19):
the idea. That's kind of how it opens up. So
there are four sections. The first one is freedom of money,
the second one's freedom of time. I might have gotten
those backwards. The third one's freedom of relationships, and the
fourth one is freedom of purpose. And those are the
four sections. So the first one, the first two talk
about freedom of time, freedom and money, right, And so
the idea is is you start bringing up your time,
(51:40):
and then once you have time to focus on the
right things, then you start to free up money, right,
because you start focusing on the things and making more money.
And then you can start focusing on the relationships that
matter both in your business and in life. And then
you can start focusing on actually working on the things
that help build your purpose in life. And so anyway,
(52:01):
it completely blew me away to the point where I
just immediately started working through the book the second time.
Loved it. So I'm going to pick that another book
that I listened to that I also really enjoyed, because
I do listen when I'm out and about, but I
wanted to actually read the physical book. So this book
is called Sorry my brain just went blank on it.
(52:21):
But it was recommended to Me by my friend Manny
and it's one of his favorite books.
Speaker 3 (52:26):
Oh what's it called.
Speaker 2 (52:28):
I can pull it up on audible as a Man
Thinketh by James Allen, And it's funny because it's an
older book. Like the newer books of this genre, they
tend to tell stories and illustrate their points and stuff
like that. But the older ones like Napoleon Hills, Think
and Grow Rich. You've got what's the other one, the
(52:49):
Carnegie Book, Win Friends and influence people. A lot of
those they have less of the story and less of
the narrative and they more just kind of just tell
you their ideas and just flesh them out. And so
this is one of those, right, And so I like
the stories, and so it was a little bit harder
for me to kind of get through. And there's a
lot to unpack there. So it's very tense, but there
(53:11):
is so much there that is just so there's just
so much there that you can just get so much
out of. And so I encourage you to go take
a minute to go listen to it, because I mean,
just just quality stuff. But the flip side is is that, yeah,
just be aware that you might have to go back
through it in order to get all mine, all the
(53:32):
gold out of it. But yeah, terrific book there as well.
So those are my two picks. I'm going to pick
those two books. And then of course devinfluencers dot Com
slash podcast is the podcast I've been doing every day.
There you go, All right, Joaquin, what are your picks?
Speaker 6 (53:48):
Okay, So I would say my biggest newsul voice. Actually
it's just a shout out to my football team I'm
fan of. We're not in the in the best shape
right now, but probably next season will be will be
better for us, and.
Speaker 2 (54:08):
That's a true fan. I love my football team. It's
not the best year for us, but I'm there for
you guys.
Speaker 6 (54:17):
Yeah, and so Angie excess. Of course. The other pic
I wanted to mention is a TV show I recently
watched a mare of Install which was very very pretty
cool for me, very good and yeah, those are awesome.
Speaker 2 (54:33):
And then if people want to get a hold of
you online, you know, say geth ub Twitter that kind
of stuff where they find you.
Speaker 6 (54:39):
So yeah, I'm in Twitter. My account is j o
a q ce I did. I'm going to send a
link there if you want to post it, but it's
basically a couple of letters of my name and my
my last name. Yeah, I'm in Twitter and agree. I'm
Goodaby with the same account, so.
Speaker 2 (55:00):
The awesome all right, Well thanks for coming. This was
awesome and until next time, folks max out
Welcome to Adventures in Angler, the largest and most popular
podcasts in the world about web development with Angler, This
show is brought to you by Void and top Endavs.
Unvoid provides high quality design and software development services on
a client friendly business model. Unlike all other agencies, Unvoid
(00:22):
allows clients to only pay after the work is delivered
and approved. Visit unvoid dot com to learn more and
reach out. If you know a company that needs more
professionals to help with design and software development, that's u
n vod dot com and top and Davs helps you
(00:44):
stay up to date with cutting edge technologies like JavaScript, Ruby, Elixir,
and AI. Visit topd davs dot com to join their
AIDV book camp, weekly community meetups and access expert tutorials.
Lucas Paganini, founder of on Void and host of this podcast,
(01:04):
Thank you for tuning in. Let's jump into the episode.
Speaker 2 (01:14):
Hey everybody, and welcome back to another Adventures in Angular.
This week, on our panel, we have two new panelists.
We have Richard Stourle. Hey, hey, hey, you want to
remind people who you are because we haven't had you
on for a few weeks.
Speaker 3 (01:30):
Yeah, my name is Richard.
Speaker 4 (01:31):
I am a front and leave developer for a company
called Optimal Systems. I am based in Berlin, Germany, originally
from Johannesburg, South Africa. And yeah, I'm really loving the show.
I'm a big fan of Anglia Adventures in Angular and yeah,
I'm happy to be back again.
Speaker 2 (01:53):
All right, and just to keep it multinational. We also
have another new panelist we have and you can tell
me if I say your name wrong too. It's super Nichra.
Speaker 3 (02:03):
Yeah, yeah, it's correct. And Hi guys, I.
Speaker 2 (02:05):
Do you want to remind you of who you are?
It's been a few months that you've been on.
Speaker 5 (02:09):
Yeah, so I'm as Stol, I'm Super Wednister. I'm from
India and currently I'm in Bangalore and I'm a full
stack developer. Currently I'm working in society General and I
think once in last year I was in the show
at a as a guest and now I'm very happy
(02:31):
to be as a panelists.
Speaker 3 (02:32):
It will be a wonderful experience.
Speaker 5 (02:34):
And I had a I have a YouTube channel that
is on basically on Angler and that is fun of Heuristic.
Speaker 3 (02:42):
So everything is going on together awesome.
Speaker 2 (02:46):
I'm Charles max Wood from dev chat dot tv. Maybe
I should do a little intro too. So I started
the show with a bunch of friends of mine, what
like seven years ago or something, And yeah, we've been
doing the show for a while. I kind of handed
it off some other folks wound up taking it back
over January timeframe. Shy and I were doing it for
(03:06):
a while. I interviewed a few folks like Richard, and yeah,
I wanted to bring some more people back in and so, yeah,
I'm excited to be talking to some new friends. And yeah,
we have a guest today. That's walking, is it seed?
Speaker 3 (03:21):
Yep?
Speaker 6 (03:21):
Yeah, that's good. That's good.
Speaker 3 (03:23):
That's good.
Speaker 2 (03:23):
That's good. That means I said it wrong. Why don't
you go ahead and introduce yourself and we'll dive into
our topic here in a minute.
Speaker 6 (03:30):
Okay. Yeah, So I'm a full stack developer. I'm currently
working as a freelance I'm from Rosario, Argentina, and I'm
currently living in Buenos Aires. And yeah, I've been writing
a couple of articles around ngccess and Firebase, which I've
(03:50):
also been working on for the last few years. And
last year I wrote a plugging plugging with the help
with the angi Exist team, applying that connects ng access
and Firebase, and yeah, happy to be here. Yeah, hopefully
this will help everybody who's listening.
Speaker 2 (04:10):
All right, well, I'm going to start real basic for
some of our newer listeners, newer to Angular and the ecosystem,
and then we can just go as deep as we want.
Do you want to just explain real quick what nng
access is and what Firebase is and then we can
just go for it.
Speaker 6 (04:25):
Okay, yes, So first I'll start with Firebase, which is
a back end. Yeah, it's a platform which helps you
or provides you with mainly a database for you to
build apps, but not only a database. It also provides
you authorization, server less functions or yeah, ability, capability to
(04:52):
run server less code, and it also has a lot
of other tools that makes Yeah, it makes everything you
need to build an app very easy and very accessible.
So you can spin up an app really really simple
and really quick with Firebase. Nd Axcess on their hand,
(05:14):
it's a library state management library that it's within the
Angler ecosystem. It is based on the redax pattern, so
it's kind of similar to n GRX, but it's not
like ANGI rex it has it's different and yeah, so
it basically allows you to manage the state in your
(05:39):
application in a more structure way. It allows you to
organize how you handle the state with actions and stuff
like that. And yeah, basically when you're starting, when you're
building apps, you'll normally get to a point where when
you've got going to need to use a state management
(06:00):
library as you wrap growth and well, NGS is one
of the options out there is the one that I prefer. Yeah,
I don't know if that kind of gives an idea
about purpison in jexcess.
Speaker 5 (06:15):
Yeah, what I think, what what I got? I think
it's for the everyone as well. It's a little new,
newer in market, I guess, And it's kind of a
similar concept as gid X as you tool, but it
has what I'm just seeing here, it has some less components,
so let's less to code.
Speaker 3 (06:38):
That's a good thing.
Speaker 6 (06:40):
Yeah, Yeah, one one of the differences, or I guess that, Yeah,
the main difference between ngxs and and gi X is
that it was built to keep simplicity, like with simplicity
as the first thing in mind. So and also yeah,
idea about the NGXY is that it was or it
(07:03):
feels that it's similar to everything else that you do
in Angular. So in Angular you have classes and components,
and in NGXS you have your state which is also
a class, and you decorated with a state decorator, and
you have your actions, which are also functions that you
(07:24):
decorate with the with an action decorator. And then within
your state class you can inject other services the same
way that you inject services in your components. So it's
basically pretty. You feel that you're writing similar code to
everything else you're writing your Angular applications. And the other
(07:49):
main difference with ji X is that since you can
have a sync functions as a first citizen of NNGXS,
you don't need what in any direct arects they call effects,
which are things that you have to connect like in
a separate file or yeah, you have to configure it
(08:10):
in when. When you have when you call an API
and all that. So in JXS you can directly inject
your API in a state class for example, and then
create an action that it's actually a promise or unservable,
so that means that it's a synchronous and the library
(08:31):
will all handle that synchronous for you, so you don't
have to worry to subs, subscribing and all that. So
the livery will do that for you, and yeah, that
for me, that that's that's something that Also it makes
things easier because you can have all that in the
same action, so it's easier to understand the code and
(08:53):
all that.
Speaker 4 (08:54):
So yeah, I think so, I think that's a very
good comparison. And I'm very glad that we addressed the
elephant in the room because I think I had one
of those questions lined up as well, and it would
be remiss if we didn't ask that question. But you
also mentioned some very key differences there. But my question
would be based on your experience and your humble opinion,
(09:18):
and I presume you've used your ex as well, even
though you're a core member of the NJXS team. Would
you what would be a good use case for using
this tech that you you wrote an article about so
using Firebase and NJXS.
Speaker 6 (09:35):
So yeah, so basically, this this plugging came out, came
out as an idea for me because I was I
started working on a project and we started working with
firebase right as a back end, which also Firebase another
cool feature is that allows you to build reactive apps
(09:57):
right since fire Base lets you connect with the query
to the back end database. Every change that occurs in
the database is pushed to their clients that are connected,
without clients needing to pull for every time they want
new the new the latest data let's say, or the
(10:19):
latest value. So all the all the new new changes
or the new values that happen in the database are
pushed to the to the clients that are connected to them.
So I started working on a project with Firebase. I
initially started using just the Firebase library, which is a
(10:42):
service that you can inject in your components. And then
as my app grew, I had to start doing something
with the about the state in the applicacy is becoming
to conerson to understand how everything was connected and all that.
And at that point I made a research on which
were the different libraries that I could use to manage
(11:07):
state and so the three that I liked more ng
X which was the most popular, one, NGXS which actually
a friend of mine told me about that one, and
then the album was a Kita. So what I did
is I created the same feature with the three libraries,
(11:28):
and I ended up deciding for NGXS because that was
the one that I liked the most, and that I
felt that was the simpler and the one that would
help him better in my project. I mean if right
now or actually after that, I wrote the plugging which
(11:49):
also improved further or make things easier even easier between
ngxcess and Firebase. I don't know if there's something such
a connect between n g r X and Firebase. I
honestly didn't make a research on that, but definitely if
if your angler application has Firebase, if you want me,
(12:13):
if you need to implement or to add some state
management in your application, I would say give this plug
in a try, because definitely you're going to feel that
things get easier for you. Yeah, you have, you have
some you have. You will have a learning curve until
(12:33):
you figure out because once once you start using a
state management lebrary like ng Access, but most of them
are similar in that way, you start dispatching actions to
get things done. You modify the state on the in
the in the state class or in the reducers in
case of j X, and then you select slices of
(12:57):
state right that that is the one that you present
to your components or that you're using your components. So
once you have once you learn that. The thing about
this plan is that makes everything feel in the same
way or work in the same way that you would
normally use your NG access state. So you can use
(13:20):
or you can combine data from different APIs or even
the state that you have in your app with the
one that is coming from Firebase, and merging that data
is super easy because everything is in NG access, so
you can combine that data very easily. And yeah, that's
(13:40):
kind of the main the main advantage of using this planning.
Speaker 2 (13:45):
So I guess what I'm trying to figure out is
and I apologize if you cover this in your article
and I just missed it, or if it's covered in
the documentation for your plugin. But so if I have
data that I just want to live in my app,
and I have data that I want to live in Firebase,
is there a way to differentiate that and how does
that work?
Speaker 6 (14:04):
So basically, when you use Firebase, maybe maybe I should
have started I should have started there. So when you
use Firebase, you need the service that the angler fire
library has or provides, and with that you connect to
the database. So when you can create a connection to
(14:25):
the database is when Firebase starts sending your data with
the from the party that you you wrote, right, and
then you can make updates or create new documents and
that will be of course that that will be sync
into the back end database. So essentially, if you're making
(14:46):
the query, you want that data to live in your app.
If you want that data to be in your app,
it's and you're using estate management, it's better to keep
in your state management lab or along with all the
other app data, right because most most of the times
are going to need to make connections or merch, make
(15:09):
merches between those that data. So let's say you have
a form or you have I don't know, some some
UI data something like that you're keeping in your state
in any access, and then you bring data from Firebase
for example, for example a list of users or whatever.
Let's say you have a filter and the list of users.
(15:30):
So filtering that it's super easy because you have all
the data in ang access and you can then make
the filter with in the same data. Said, you don't
have to make complicated connections between the Angular fire service
and the the data that you have in your store,
(15:53):
because I mean you can do that. You can do that,
but it's more complicated. You have to are using a
lot of r rx J. Yes, operators, you have to
start doing a lot of other things that, well, it's
more complicated, I guess.
Speaker 2 (16:12):
Yeah. I think you answered my question when you said
that you first set things up with any other fire
and then use this plug in to kind of connect
and you pull everything into n G access and then
n g axcess just looks at it all as data.
Speaker 6 (16:25):
Right, exactly exactly.
Speaker 2 (16:27):
That makes sense to me that that seems simpler too perfect.
Speaker 6 (16:31):
Yeah, yeah, so basically what the plugging does and yeah,
following the same concept on how you use fire Base,
if you don't use if you don't use ngxcess. So
you have a query, So what what this planning does
is fits that query into the n G access model.
(16:51):
So on on ng access, in order to do something,
you have to dispatch an action, right, So what what
you do with this plan is that you connect an
action with a query and the results of that query,
you you connect those with your store the state right,
(17:12):
So basically what will happen is that you will configure
in your state class that when you dispatch a next action,
a action whatever, or let's say we call it load
users that action when you start that action, you're going
to query the collection users from Firebase right, and with
(17:34):
that query starts a meeting results. And we have to
remember that those results are going to be a stream,
so it's not a one only thing. It's going to
be constantly a meeting as changes occur in the database.
Every time a new emission happens, you're going to grab
those results and insert them in your in your store.
(17:59):
The planning is going to do that for you, so
you don't have to worry. So that's that's kind of
the magic that happens is you don't have to worry
about updating the state every time. You just configure the
which action is going to start the querry and how
you're going to update your store with the results. Everything
(18:21):
else is handled by by the by the library.
Speaker 3 (18:24):
That's very cool.
Speaker 4 (18:27):
Yeah, I think there was one thing that I picked
out of what you mentioned. Now, well several things, but
the one that really stuck out for me was you
mentioned that just like just like we have in an
j r X, we've got the effects or the concept
of effects, and you said this is not necessary in ANGIXS,
And I'm just wondering, how do you ensure that, First
(18:48):
of all, where do you handle your ACYNC code and
your side effects, and how do you ensure that your
stay remains your store remains immutable?
Speaker 6 (18:57):
Right? So well, when and energy exist, actions can can
be asynchronous, right. So that means or the way that
you do that is that you from that action you
return either a promise or observable. So the state is
going to be immutable because when you write the action,
(19:19):
there's a context that gets passed to that action, which
is the one that you used to patch the state
or to make modifications to the state, right, and those
changes are going to be immutable. And that's that is
something that that context that gets passed or injected to
you in the action ensure I don't know if that
(19:42):
answers your question, but basically the state is immutable. And
the asynchronous thing about NGXS is just that if we
compare with n gi xis that it includes the effect
in the same action. We can maybe we can image
you need like that because you can have an observable
(20:03):
or a promise and the library is going to handle
that for you. So it's going to wait or to
subscribe to an observable or is going to do then
to a promise let's say and run the next the
subsequent code for you. But the way that you patch
(20:24):
the state or that you make modifications, it's always immutable.
Speaker 3 (20:28):
Yeah, that's that's very neat.
Speaker 5 (20:31):
Yeah yeah, yeah, yeah, go ahead, Sorry, no, no.
Speaker 6 (20:37):
So the other thing about having the bit or having
the future of as synchronous actions is that actions have
a life cycle. So actions get dispatched and actions then
are completed or canceled, and they can be completed with
an error or or successful. So an error can occur
(21:02):
within the action. So you have like different events that
will occur during the action life cycle, and you can
have different states have the action can finish. And that's
also very very interesting because with that you can then
know when an action has started and when an action
(21:22):
has finished, and that's super helpful. Actually, there's another plugging
on ngxaid that it's also very very nice that you
can subscribe to know when an action is being executed.
So let's this is the famous or the yeah, the
very common the loading load the loading feature right rather spinner,
(21:47):
So basically you always want to put a loading or
spinner when when an action or something is going on. Right,
So with that life cycle, NGXA makes it super easy
for you because you can track when the action is
dispatched and start spinning, and when the action has completed,
you stop, so you don't Angie access will handle that
(22:11):
state for you. So you just query when the action
has started and when it has ended. And I think
that in injuries you kind oft do that. You have
to manually like start a loader before an action is dispatched,
and so you have to do another thing right in
order to do that.
Speaker 4 (22:31):
Yeah, I'm actually giggling because, yeah, that's exactly. I remember
my own experience with my team a couple of years back.
We were using an English shop and we use NNGRX
and exactly the scenario that you've just described. Now, yeah,
you had to jump through certain hooks to manage that
what appears to be a very.
Speaker 3 (22:50):
Straightforward and simple scenario.
Speaker 4 (22:52):
But yeah, it's very interesting to hear that that is
manage internality within the library.
Speaker 3 (22:57):
It's very cool. Yeah, I have a.
Speaker 5 (23:00):
Question, like, like, I think you have just explained that one,
so I just want to clarify what I got is correct.
So we basically make make APA calls inside our state
once accident is dispatched, and update the state itself inside
the state. Like in the case of ng X, we
use a reducer and sorry effects and reducer. So here
(23:24):
everything will happen inside the state. Is that correct?
Speaker 6 (23:27):
Exactly? All the gode lives in that state class, so
you can have like the comparison to the reducer in
energy excess. It's an action and within the action you
can call an API for example far Base or whatever
a PA you want to call, and then you can
(23:48):
patch or make the modification to the state. So you
have both things in the same like, yeah, it's called
the action the same code blog.
Speaker 3 (23:59):
Let's say, yeah, so I have one more question.
Speaker 5 (24:02):
So if you check in engie erics, so you store
it mapped with the reducer to change the state of
your of your application. Like suppose I have two three
one user model and one supports some items. Then I
if I want to uproducer, I will use the user
reducer and unto updateight term, I will update use the
(24:26):
item reducer.
Speaker 3 (24:28):
But how it maps here, that will.
Speaker 6 (24:30):
Work right, So when you want to change something, you
create an action. The action can receive a payload. So
let's say yeah, if it's you can dispatch. When you
dispatch an action, you can pass a parameter with values
and you receive that in the action block action code
(24:50):
blog and so as I mentioned earlier, so there's a context.
So I think in you jer x, you have to
return the new value, right, you just returned in the
reducer you read. So in anti access it's a bit
more imperative. So you get a context injected in the action.
(25:12):
It comes as a parameter in the action. And then
with that context, you have a method that is called
patch state, and that patch state is the one that
you have to pass the new value that you want
the state to have so you can perform whatever operation
you need or and when when that patch state is executed,
(25:34):
the store gets updated in a in the middle way,
and all these selectors that depend on that data will
push the the new values to all the components that
are connected to that selector.
Speaker 5 (25:51):
Right, So the selector is basically seen as Watson enngietics.
Speaker 6 (25:55):
Yes, yes, it's the sane.
Speaker 2 (25:57):
So I have to ask this because I have the
guy that touches like every line of code that I write,
and he's a complete idiot, and his name is Chuck
from yesterday, all right, And the only way that I
can keep this guy in line is to write tests. Okay,
I mean chuck from today, he's fine, but Chuck from yesterday.
The guy's more on okay, and he screws stuff up,
(26:20):
and I find his mistakes in the code that I write, right,
because I have to go back and I have to
fix them. And so, but if I write tests, then
a lot of times I can avoid writing some of
these bugs in my code. Not that I ever write
bugs in my code, but how do I test this stuff? Right?
How do I make sure that I'm not writing bugs
in my in my in my stuff right?
Speaker 6 (26:43):
So, and she exists, I mean for testing the actions
and all that. There's so if you go to the
dogs there there is some documentation on how to make
tests with Firebase the plugging. So you're basically you will
have to mock the query right, because what you're doing
(27:06):
is that the library is connecting the query with an action.
So what you have to mock is the results that
the query is going to admit, and how the given
that the store is going to get changes updated or
(27:27):
inserted in the store. So that's kind of what you
would want to test. How the mock the results of
the query that are going to get admitted and what
will happen after that?
Speaker 2 (27:38):
Right the thing?
Speaker 6 (27:40):
So yeah, honestly, there I think there are a lot
of libraries to mock obserbles. You can even create a
behavior subject for example, and use that as the mock,
which is what I do sometimes. If I have to
be completely honest, I mostly use or I try to
(28:01):
use more Cypress to make tests sometimes not a lot
of not a lot of unit tests. And so one
of the things about using or the way that I
like to use this plugging and that I try to
keep the code in my applications, even though sometimes it's
(28:21):
not very easy, is to try to keep it as
simple as possible, right, so, because that is less prone
and it also it's more maintainable. So this library helps
you with that. So and the way that you should
(28:41):
or that I try to use this to try to
be the less complicated as possible. I mean, the common
the most common operations that you would need to do
in your application is bring a list of items from
the database or a specific items from the database. And
(29:02):
so basically your state is going to typically typically look
like have a couple of a couple of connections, So
want to get a list or all of the items
and want to get a specific item, right, and those
the result is going to be stored in that state
(29:23):
and that state class let's call it users for example,
want to get all the users, want to get a
specific user, and they're all going to live in that
state as an array, right, and then you have the
selectors to get active users, to get users that have
signed in last day. And so yeah, that's when I
(29:45):
try to keep the state or yeah, how to write
the code most of the times, right, of course, there
are sometimes that things get complicated because it is what
it is, right, and for that situations you you probably
need to make some tests. Also, one cool feature about
(30:07):
and you ex says is that the selectors are written
as functions, as pure functions, so it's very easy to
to create tests around the selectors. So this is different
from from the library, right, but you can you can
easily inject, so you basically provide the function the set
(30:27):
of results that is going to be your mock, and
then you you expect something and you just write execute
that function. So it's it's super easy to test selectors
in that way. Yeah, so I hope hopefully that that helps.
Speaker 2 (30:44):
No, it makes sense, and I mean it was mostly
the angular part of it, or not the angular part
of it. I was hoping to mark the angular part
of it. Yeah, that's genius check things. No, it was
the fire based part of it that I was trying
to figure out. Yeah, if there was a way to
mock that because I can kind of see Yeah, I'm like,
can I reliably get the right data back and have
(31:07):
it come into my state the right way? And and yeah,
the more I think about that, the more Cyprus kind
of feels like the right level to be testing that
at because essentially then yeah, what I want to know
is maybe at the component level, if I if I have,
if I trigger some kind of action, yeah, is it
going to follow through the system make the query on
(31:30):
the back end, But I don't want it to make
a query because I don't want to go to an in,
run out to Google, and then is it going to update?
Is it going to make the proper updates on the
other end, right, depending on what data gets back? So
I just need to mock that data out, So that
makes sense.
Speaker 4 (31:43):
Yeah, I'm I've got a very So I'm I suppose
there's someone out there listening to this podcast and wondering, like,
whoa Okay, JXS sounds super cool. You know, they can't
wait to jump right in and get thoughted. I guess
my question would be, like, what other common pitfalls people
(32:04):
fall into when starting out with NJXS and what advice
would you give them to avoid them?
Speaker 6 (32:11):
Right? So, yeah, that's that's an interesting question. So my experience,
I think, or yeah, my experience and from what I've
seen in the slack community that JXS has, which by
the way, is very active, and yeah, people ask about
for best practices and all that. Yeah, some of us reply,
(32:34):
or even people that are there, so that's that's very cool.
So I think that basically, or what most of it
happens is that you start writing your your JS code
or your state code with a lot of how to
say it, it's it's I don't want to say complicated,
(32:55):
but because it's like you start doing it very specific
to your to your use case, and over time you
start noticing that you have to keep your state as
generic as possible. So like in the in your life cycle,
you would probably start because maybe your app requires in
(33:16):
some place that you display a product let's say a
product detail, right, and so with that in mind, you
probably create some state for just that product and stuff
like that, right, and then you then quickly realize that
you're going to have to keep the product available for
(33:38):
other places, for other pages, and you're most likely going
to have to load a lot of products. Right that
That's kind of what happened to me and what I've
seen in the in the community asking, right. So with
that in mind, you would probably start your designing your
state to keep one product living in your application, right,
(33:59):
and then you realize that you have it's better to
keep it as an array and create selectors that reflect
what each component needs.
Speaker 3 (34:10):
Right.
Speaker 6 (34:11):
So, so basically I would say that that's one of
one of the main things. It's not designing your state
with the needs of your components. So let the selectors
do that for you because they are super flexible and
very easy to change. And try to keep your state
as generic and as raw as possible, so meaning if
(34:35):
you're going to if you have products, or if you
have users, or if you have I don't know, yeah, invoices, whatever,
So try to keep them as rass possible in the state,
and then let the selectors make the specific give the
specificity for each component that you need in your application.
So that's yeah, I would say that that's one of
(34:57):
the main things. The other main thing is is as
synchronous actions. So I think that sometimes because people is
used to use n g X, they usually follow the
pattern of having a load action and the success or
fail action of that load, and that in nj X
(35:19):
that is glued together with the effects, right, So in
NGXS you don't need that. You can just have the
load and what the load finishes. You will get the
result in the same block of code and make something
or it would fail in the same block of code
and you can do something about it. So the patterns
about that, it's also something that frequently I see it
(35:44):
in that people that people ask ask a lot about.
So in my experience, from what we most mostly recommend
is that you should in jexcess, you should go out
from the or not use that pattern of the three
actions for loading something. You would prefer just keeping a
load action and keep everything within that block of code,
(36:08):
which also makes a lot more sense when you need
to start fixing things or you need to change because
everything is going to live in a single.
Speaker 4 (36:15):
Place, right, Yeah, that makes a whole lot of sense.
Keep your states as generic as possible. And use your
selectors to you know, to get a slice of the
data that you're interested in. It's very cool talk. I
don't know about you, but I'm very I'm itching to
hear you came about how he managed to become a
(36:35):
co member of ang XS. You know, how did you
join the team and what was your journey?
Speaker 6 (36:41):
Like, well, that's that's a very very good question. So yeah,
so it all started last year with the pandemic, so
that that was one good thing that the pandemic brought
for me. Actually, yeah, so since I started using ang
excess in my project, I started participating on Slack in
(37:05):
the community a lot. I have a couple of yeah
questions and suggestions and the team was very yeah, so
they received my suggestions very well. There was a point
I think that I came out with the idea of
writing this this plugging. And at that point when the
(37:30):
core the team leader of the of the core team yeah,
asked me if if I wanted to join to join
the team. So we we kind of work together on
this plugging and yeah, I've been participating on on the
on the team meetings and all that since then. But
(37:53):
basically it was I started, uh actively contributing in slack. I. Yeah,
I think that there were a couple of issues that
came out on the on the enge exist that I
collaborate as well to fix those, and then I started suggesting, yeah,
(38:14):
this kind of plug ins or making a couple of changes,
and yeah, they they liked the ideas that I had,
so in the end they proposed being part of the team.
Speaker 4 (38:26):
Wow, that's that's a very interesting Sorry.
Speaker 5 (38:29):
So how many Yeah, so how many days it took
you to finish? I think it's seeing a lot of
good in pandemic.
Speaker 6 (38:40):
Yeah, I think it's It was around I don't know,
two three months. So the thing is that, or at
least in the process for me, was that I came
up with the idea. I wrote like the first version
of it, which was completely different from the one that
it's out there now, and I that was read that
(39:00):
one to the team leader, which is called Mark whitfelt.
He really liked it. He liked the idea and he
suggested changes to make it more ergonomic and easier to use.
And yeah, since then, I yeah, it was a second version.
So I think that the whole process was around two
(39:21):
three months, But it was not like all the time
working on it. It was a lot of time spent
thinking about it, how it should work. And then when
I finally did the first version and that something it
was possible and it was helpful. Then it was trying
to polish it and make it better and easier to use.
Speaker 4 (39:45):
Cool So do you have any number of terms of
usage of the plug in you? Are you aware of
how it's been used out in the wilds so to speak?
Speaker 6 (39:53):
No, to be honest, no, I know that. I know that,
I know that it has been used, So it has
I have been a lot. There have been a lot
of questions coming to the to the gift repository, So
that's a way of knowing that someone is using it.
The are they We also did an angular session with
(40:18):
Beman and so there was I participated there as well,
and there were a couple of questions about the plugging,
so that also at least interesting about about it. But yeah,
if I have to be honest, I wouldn't know how
many how many people are using it. I guess that
(40:39):
I could look at the downloads, but I don't know
if that's that like completely the usage.
Speaker 2 (40:47):
Yeah, I know the projects, not necessarily people.
Speaker 6 (40:50):
Right, So I know that the ant Excess team lead
uses is used it in one of their projects.
Speaker 5 (40:57):
So yeah, yeah, right, yeah, that's so one question I
was like having, like if I use this one in
my project? So I think you may have covered they
I haven't gone through the plug in, so just asking,
like suppose if I make a call to serve and
somehow might state got update date, but like means my
(41:19):
data got updated, but the state is not and and
at that moment somehow the connection failed, how it managed
the state, like is it will fire away? Fireways will
meet it again if you're if you're without any changes, So.
Speaker 6 (41:35):
You're asking what happens when when the connection fails or
you have your out of connection with Firebase.
Speaker 5 (41:44):
That yeah, But scenario is like suppose your database is
updated but while getting a response, your connection failed due
to internet connections, so that it's handled here like kind
of because that is we are not ready to state
and now we can add one more, right.
Speaker 6 (42:05):
Right, So that's that's the beauty. That's the beauty of Firebase.
And the good thing about using this this plugging is
that it doesn't interfere with Firebase already does for you,
which by the way, it's it's a lot, and it
handles it very well. So the way that Firebase works
is that they initially update the in the client site
(42:28):
locally and then it tries to sink with sink with
the server. It is going to retry until it works.
So basically, basically you don't have to worry about that
because Firebase is taking care of that for you. You
can get confirmations when it actually has updated the database,
(42:50):
but most of the times it's going to you're not
going to need that because your fire Base is working
on a is working like in a law side. First,
you're always going to be updated in in the in
your application. So so it's like when you make an
(43:11):
update for example, you will see reflected in your in
your application instantly right and then it's going to update
it in the back end, which which also that model.
It is very very good to for reactivity in your
application because that's something that I haven't mentioned and I
(43:32):
think it's a very important thing. So with anti Access
and Firebase, you can make and you will make your
application reactive from from the front end to the back end.
Because Angie Access it's also a reactive it's a reactive
state management library and every time something changes in the store,
(43:53):
all the components get senked with the new with the
new value. And in Firebase, every time something change just
in the in the database, all changes are pushed to
the connected clients right away. So you don't have when
every time or after you create a connection or a query,
(44:14):
you don't have to worry anymore about pulling data and
like you have like a two way data to fetch data. Right,
it's already connected and data is flowing through the connections
all the time.
Speaker 5 (44:29):
So buy back to all the get calls. Sorry, so
we can say by buy back to all the get calls.
So in normal application, we used to make a get call,
then put updates and again we'll get.
Speaker 6 (44:42):
So right right, exactly, exactly exactly.
Speaker 3 (44:46):
I think. For yeah, yeah, that's very interesting.
Speaker 4 (44:49):
I mean I've had the pleasure of working with fire
Base in the past a couple of years back, and
I'm sure a whole lot of things have changed since then.
But I mean it's as a platform, I think it's
it's great. I mean you can literally pull together simple
something that is typically not so easy to do by hand,
(45:10):
for example, handling authentication. You've got that fire Store database,
real time database storage, hosting and functions and so forth.
And I've had a pleasure to to play around with
all of those for one of my previous customers, and
I absolutely love it. I think all the points that
you've mentioned today, it's it's all valid, and I would
(45:30):
urge people out there to to give it a try.
But for me, I'm always very curious, like when someone
mentioned something that sounds so good like you have today,
I'm always thinking about maintenance, right, how easy is it
to debug apps that are built with the enge access?
Do you have something similar like redux def tools for example.
Speaker 6 (45:53):
Yes, yes you do, and I would say yeah, I
mean for me, of course, you'll always you always have
to learn right to in order to use your to
use your your new library. Uh there, there's going to
be some learning career. But and the access so since then,
(46:15):
since all the acing actions or acink is allowed in
your actions, you can place debuggers within your block of code.
So it's going to stop there, and that that makes
it easier to the bag. And as far as changes
in your store or how they're there, they are the
state is changing after actions are executed. You can hook
(46:38):
you can use the redax dep tools it's the same,
the same plugging, the chrome plugging, and you will see
changes that happen in your store after each action, so
you can be bag the bag that way as well.
Speaker 2 (46:54):
All right, great stuff. Now I'm going to go play
with it. So we've already burned an hour on this
and now we're gonna go burn more, right of course.
But yeah, before we do that, I'm gonna push it
over to picks because, yeah, we're kind of getting to
our time. I want to make sure that, yeah, we
wrap this up before people have to run off and
do other stuff. So yeah, let's go ahead and do picks.
(47:17):
I'm pretty sure everybody here has done it before except
maybe Joaquin. So yeah, let's let's go ahead and have
Richard do it first. Richard, do you have some picks
for us today?
Speaker 3 (47:26):
Yes, I've got two today.
Speaker 4 (47:28):
The first one is if you remember, Chuck, we spoke
a couple of weeks ago about my pending trip to
Crete in Greece. I, yeah.
Speaker 2 (47:38):
I had a punchels.
Speaker 3 (47:41):
Yeah.
Speaker 4 (47:41):
It was a small little town called Kanya as the
locals call it. But it's just picturesque. It's so beautiful
and tranquil. Yeah, and I had a chance to go
and recharge my batteries so to speak. Came back feeling
super refreshed and ready to rock and roll again. So yeah,
if you do get an opportunity to travel, I would
(48:02):
definitely pick that up. Let me know, if you want
to know where all the cool beaches are at, I'll be.
And then the other one is So the funny thing
is the company I work for, all the different teams
have names of birds, and my team's The name of
our team is called Dodo. If you know of this
(48:23):
extint bird called Dodo. But yeah, I just want to
send a shout out to my team. They're they're fantastic.
They're great bunch of boys and girls and we work
great together. So yeah, I just want to say shout
out to them. Awesome super yes picks for us.
Speaker 3 (48:39):
Yeah yeah, yeah.
Speaker 5 (48:40):
So first one will be technical picks and that I
recently came across. You're back in frame work for no Jazz.
It's a nest Jazz. It's not next, but I was
also a little kind of at the begining. So it's
Nest Chess. And the true cool thing is it's like
(49:02):
you can say, seventy to eighty percent similar ads angler
We have services, we have models, we have everything. So
it's a pretty gift for Angler developer to develop the
back end, and every Angle Angler developer should check it
once because again, be full start developer with that. And
(49:25):
the second one will be a Netflix city that I
think everybody knows is Lucifer.
Speaker 3 (49:31):
I'm watching that right now, and that's all it is
for me this week.
Speaker 2 (49:35):
Awesome. Yeah, and if you could put your links to
your picks in the chat, then we'll make sure we
get them in the show notes. So I'll throw in
my picks here real quick. Now. I've picked this on
like every show because it's still bending my brain. I
am so I listened to the book. Now I'm reading
the book. I probably listen to it again here soon.
It's called Who Not How. It is very much more
(49:55):
of a business book, I guess, than a technical book.
But I'm finding it applicable in a whole bunch of
areas of my life. So if you're trying to get
more done in life, then this is the book for you, Okay,
and let me just give you the rundown real quick.
So for me, I'm working a full time job. I'm
trying to run a podcast network. I have five kids.
I trained for a marathon that I did not run
(50:16):
on Saturday because my nephew got me sick. I will
spare you the gory details because it's kind of gross
how some of this stuff manifests. But anyway, so, yeah,
you know, I have all this stuff going on in life,
and I was trying to do everything myself, and to
a certain degree I still am. But I started reading
(50:36):
this book and I realized that I don't have to
do everything myself. So I've started bringing people in to
do more of this stuff. And yeah, some of it
I feel like, oh, it's not going to get done
the way that I want or exactly how I want
or as good as I would do it, But holy crap,
I cannot do it all myself. And the other thing
is is the more I free up myself from doing
(50:59):
the things that I don't have to do, the more
I can spend time working on the things that I
do have to do, and especially the things that allow
me to pay the bills at home and pay the
bills for the people that are working for me here
in the podcast network and stuff like that. If you're
my kids screaming, I'm really sorry. So anyway, you get
(51:19):
the idea. That's kind of how it opens up. So
there are four sections. The first one is freedom of money,
the second one's freedom of time. I might have gotten
those backwards. The third one's freedom of relationships, and the
fourth one is freedom of purpose. And those are the
four sections. So the first one, the first two talk
about freedom of time, freedom and money, right, And so
the idea is is you start bringing up your time,
(51:40):
and then once you have time to focus on the
right things, then you start to free up money, right,
because you start focusing on the things and making more money.
And then you can start focusing on the relationships that
matter both in your business and in life. And then
you can start focusing on actually working on the things
that help build your purpose in life. And so anyway,
(52:01):
it completely blew me away to the point where I
just immediately started working through the book the second time.
Loved it. So I'm going to pick that another book
that I listened to that I also really enjoyed, because
I do listen when I'm out and about, but I
wanted to actually read the physical book. So this book
is called Sorry my brain just went blank on it.
(52:21):
But it was recommended to Me by my friend Manny
and it's one of his favorite books.
Speaker 3 (52:26):
Oh what's it called.
Speaker 2 (52:28):
I can pull it up on audible as a Man
Thinketh by James Allen, And it's funny because it's an
older book. Like the newer books of this genre, they
tend to tell stories and illustrate their points and stuff
like that. But the older ones like Napoleon Hills, Think
and Grow Rich. You've got what's the other one, the
(52:49):
Carnegie Book, Win Friends and influence people. A lot of
those they have less of the story and less of
the narrative and they more just kind of just tell
you their ideas and just flesh them out. And so
this is one of those, right, And so I like
the stories, and so it was a little bit harder
for me to kind of get through. And there's a
lot to unpack there. So it's very tense, but there
(53:11):
is so much there that is just so there's just
so much there that you can just get so much
out of. And so I encourage you to go take
a minute to go listen to it, because I mean,
just just quality stuff. But the flip side is is that, yeah,
just be aware that you might have to go back
through it in order to get all mine, all the
(53:32):
gold out of it. But yeah, terrific book there as well.
So those are my two picks. I'm going to pick
those two books. And then of course devinfluencers dot Com
slash podcast is the podcast I've been doing every day.
There you go, All right, Joaquin, what are your picks?
Speaker 6 (53:48):
Okay, So I would say my biggest newsul voice. Actually
it's just a shout out to my football team I'm
fan of. We're not in the in the best shape
right now, but probably next season will be will be
better for us, and.
Speaker 2 (54:08):
That's a true fan. I love my football team. It's
not the best year for us, but I'm there for
you guys.
Speaker 6 (54:17):
Yeah, and so Angie excess. Of course. The other pic
I wanted to mention is a TV show I recently
watched a mare of Install which was very very pretty
cool for me, very good and yeah, those are awesome.
Speaker 2 (54:33):
And then if people want to get a hold of
you online, you know, say geth ub Twitter that kind
of stuff where they find you.
Speaker 6 (54:39):
So yeah, I'm in Twitter. My account is j o
a q ce I did. I'm going to send a
link there if you want to post it, but it's
basically a couple of letters of my name and my
my last name. Yeah, I'm in Twitter and agree. I'm
Goodaby with the same account, so.
Speaker 2 (55:00):
The awesome all right, Well thanks for coming. This was
awesome and until next time, folks max out
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.