November 28, 2024 • 50 mins
Ravi Veliyat helps train people in many web technologies, Angular being one of them. The panel discusses the various ways you can get your components to communicate, from inputs and outputs all the way up to NgRx. Ravi walks through the different options, with great examples that will keep you on the edge of your headphones.
Links
Become a supporter of this podcast: https://www.spreaker.com/podcast/adventures-in-angular--6102018/support.
Links
- You might not need NgRx | Mike Ryan | AngularConnect 2018
- Subjecting State to Good Behavior | Kim Maida
- Alyssa - Oculus Quest Headset
- Eddie - Sentry.io
- Eddie - Notion.so
- Chris - Pokémon™ Sword
- Ravi - veliyat.com
- Ravi - https://www.youtube.com/c/raviVeliyat
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:04):
Hello, everybody, welcome to Adventures in Angular. My name is
Alyssa Nicel and today with us on the panel we
have Eddie Hinkle, Hey everyone, and.
Speaker 2 (00:15):
Chris Ford good day.
Speaker 1 (00:19):
And our marvelous guest is Rabbi dell Yat.
Speaker 3 (00:23):
Say hello, Rabi, Hey, how are you? And thank you
for having me here, by the.
Speaker 2 (00:26):
Way, absolutely thanks for joining us.
Speaker 1 (00:29):
So, Rabbi, tell us a little bit about yourself and
what you do in the Angular community.
Speaker 3 (00:35):
So let me start when I started off my career
back in two thousand and eight. I started off as
a junior PHP developer and then moved on to a
senior position, then a tech.
Speaker 4 (00:46):
Lead and a team lead.
Speaker 3 (00:47):
And you know, meanwhile I also went along with Angular
development as well, then came in no JS and then Reacted,
then Angular two point zero and now I'm looking I
will talk about that, by the way, that's an interesting topic.
But now I'm working with vugs as well, and as
far as back in programming is concerned, I do no
(01:08):
JS and Laura well as well. And I've been training
people since two thousand and eight. You know, whatever I can,
I try to teach people. That's how I learned things,
you know. So from that day till Greate twelve years
into training and the last company that I left, I
was a project manager and I had a team of
like thirty people, thirty odd people ranging from all the
types of developers and qas and the designers aug. So
(01:31):
then I left the company. I didn't want to spend
the rest of life with those thirty people. I wanted
to meet more people, so mainly into training after that,
And they're doing some consulting as well.
Speaker 4 (01:41):
And I've trained people that with procats.
Speaker 3 (01:45):
And and I conduent Aviva, at is alat PCs and
like those that are a few of them, and then
there are a lot of smaller companies who might train
at So I've been lucky that way.
Speaker 2 (01:57):
So you've like basically done it all.
Speaker 1 (02:00):
You've gone from development to teaching to managing. There's like
no and like from front end to back end. So
it's like no side of it you haven't touched.
Speaker 4 (02:10):
Yeah, I don't have any complaints. Yeah I have.
Speaker 3 (02:13):
I have almost touched all the Like I'm like the
jack of all trades and ace of none, so at
least I can make it make it good.
Speaker 5 (02:21):
In training, I was just thinking that I feel like
we finally found the mythical Tenex developer.
Speaker 4 (02:29):
Maybe I don't know.
Speaker 1 (02:32):
So Robbie, what are we talking about today?
Speaker 2 (02:35):
What is our topic?
Speaker 3 (02:36):
So we're talking about component communication and Angular and the
reason that I have chosen this topic is that it
is quite interesting and quite varied as far as the
communication is concerned, as far as Angular components are. So
we'd be talking about components and how you know, components
came in or how components are developed in Angular and
(02:58):
how they're communicating with another through services and even if
no services had there, how can they communicate?
Speaker 4 (03:04):
So that is that's basically what it is.
Speaker 2 (03:06):
Very cool.
Speaker 1 (03:07):
Well, let's dive right in, and I actually wanted to
ask you talk about doing training. Is it full stack
training that you do or Angular specific?
Speaker 4 (03:16):
It is full stack.
Speaker 3 (03:16):
I started off as a React trainer and you know
back in the day, I used to train people in Php.
So from Php to React to Angular and then we
would now know JS and Larval, so pretty.
Speaker 4 (03:29):
Much full stack.
Speaker 2 (03:30):
Cool. That's awesome.
Speaker 4 (03:32):
So shall we start the topic.
Speaker 2 (03:34):
Absolutely, let's dive in, sure.
Speaker 3 (03:36):
So I would like to start it off with a
little bit of a background on Angler for all the listeners.
Anglargs was in the late two thousand and late two
thousand and twenty ten decade, anglo JS came into the picture,
and that particular technology was the one which introduced components
to us. However, they were not used as much because
(03:59):
the whole aim of anglo gs was to fit into
the development that the developers do. You know, back in
the day, the developers did and at that point developers
were not very much at home with components and all.
But still anglo GS had components, and then came in React,
and React was the one that actually ran with components itself,
(04:20):
and it was then that all the developers accepted widely
that components are actually the way that frontment would go.
Speaker 1 (04:27):
I didn't realize that React was that old like that.
So did React happen before Angular two hit?
Speaker 4 (04:33):
Yes?
Speaker 3 (04:34):
Yes, and and that was the reason Angler two happened.
You know, if you think about it, I mean nothing
officially that I have read, But if we think about it,
anglo JS and React they have different types of handling
the document object model. And if anglo JS would have
been the way it would have been or the way
(04:54):
it is right now, then Angler would not have been surviving.
The whole race you know, and that that's what I
think where Google took a decision that let's risk it,
let's bring it totally, like, let's do totally something new
which is component centric and which handles the dorm better,
you know, even better than React if possible. And that's
why that's why probably I think Angler two and two
(05:16):
plus versions are now you know, into the market. Otherwise
it would if React would not have been there, then
I think Anglo js would have been the way people
would have gone for.
Speaker 1 (05:26):
I know, talking with the team, they a lot of
they just had so many issues with the Angular JS
that they didn't see a way around without without the
basically essential rewrite. So I know it was painful, like
you were alluding to, but necessary.
Speaker 4 (05:46):
Definitely.
Speaker 3 (05:47):
The verbosity of JavaScript was mainly the cause, and mainly
the way the variables were handled and all. And you know,
there was no There was something called a constructor pattern
as far as class and object creation is concerned, and
that was basically a function which has a lot of
context to it, which is not how a function should
(06:09):
or should be, And then Typescript solved all the problems
for them. It was actually really courageous of the Angular
team to just remember everything, and you know, they just
had to risk the whole reputation and it actually had
a lot of I cannot say bad reputation, but developers
actually didn't believe in Angular at that point when Angler
two came into the market. But then again, now it
(06:32):
is all again, you know, all all set to normal
by God's grace, because it is Google that we're talking about,
and it is it is actually doing things a lot,
a lot better than so many other frameworks.
Speaker 4 (06:44):
In the same same thing.
Speaker 3 (06:45):
And yes, so coming back to components, so so just
to just for the record, components where they're in Anglo
jas as well. And now Angular two or two plus
is having components as their basic building blocks, and components
are meant to be in individual entities which are decoupled
and decoupled to such an extent that a team in
India can code on one component, a dream in a
(07:07):
US can code on another component and still they won't
face any problems considering the code conflicts, or only if
there is a miscommunication between the teams would they face
any problems. You know, so it's a human error that
would lead to any problem if it is a component.
PAS programming now provided that these are decoupled entities, there
should be some mechanism that the developers should be able
(07:29):
to take and they should be able to pass data
between these entities just to bridge them together or maybe
make them work together with each other. So that's where
the component communication that we are talking about comes into
the picture. And then what I also think is that
even if there is like one sort of a set
one sort of hierarchy that we think about where parent components,
(07:52):
where a parent component has a lot of child components
at all, in that case, also there is a communication
going on between the parent and the child. At that point,
there's no bridge required because they are like connected. So
interconnected component like parent and child easily can communicate between
one another. And then there are like two separate components
altogether who are nowhere related to one another, and then
(08:13):
they can also communicate. So these are like some types
of component communication that we'd like to.
Speaker 4 (08:20):
Throw some light on.
Speaker 3 (08:21):
So first type of communication that we talk about is
a parent and child communication. So if you imagine any
component hierarchy, a component hierarchy is always a composition model.
So when I say parent and child, we should not
misunderstand that by the fact that a parent would always
(08:41):
be inherited by a child. In a component based architecture,
the parent is always composed of a child, which means
the parent is at the top end the child is
at the bottom of the hierarchy. In an inheritance model,
it's a different it's quite the opposite thing. So in
any component based architecture, parent would be at the top,
child child components would be below parent, and then so
(09:04):
on and so forth. So there is an easy way,
you know, if you think about a hierarchy itself, a
parent can easily, you know, pass a prop down to
the child and that's where one of the decorators in
an angler and now angler follows a decorator pattern which
is very powerful. One of the decorators, called input decorator
is what helps the patent to pass down.
Speaker 4 (09:23):
Data to the child.
Speaker 3 (09:24):
So basically the child receives the data as input from
the parent and hence the name of.
Speaker 4 (09:29):
The decorator input.
Speaker 3 (09:30):
So basically a child can take data as much as
it wants as properties through the parent and the parent
can pass it on. So basically that's one set of
a communication. And when the parent changes that data because
it is a property inside a child, the child's UI
would change, so that's also that's also something that angler
(09:51):
has and it is really interesting where any property that
changes inside a component, it would change or re render
the template the HTML of the component. So if a
parent change is a property which has been passed as
a property to a child as an input, the child
would also change. So that is one way of communicating
from parent to child. So there is a parent child
(10:12):
communication going on, and then there is the other way
around the opposite right, the opposite so where the child
component can communicate with the parent, like child component can
send some messages to the parent. So that is something
called event that the child emits, and there's a thing
called event emitter that helps you to emit the events.
So at that point, there is a decorator called output
(10:34):
decorator that helps you to get the output from the
child to the parent.
Speaker 4 (10:38):
So input and output are quite opposite.
Speaker 3 (10:40):
So if you imagine input decorator being used to drill
the data down, output decorator can be used to pass
the data upwards to the parent and output decorator is
pretty tricky, I mean not that tricky, but it's not
as straightforward as the input decorator input is really easy,
but output has some other entities involved because output is
essentially emitting events. It's not like passing the data, but
(11:02):
it is emitting the events, and the parent is listening
to the event. So so those parent and child communications
are some things that people generally do in Angular components.
Then people get carried away and then people keep on
passing the data down to the props, right right from
(11:22):
the top component right to the bottom component. And that's
what Angular, you know, try to avoid. And that's where
Angler has fixed things. You know, if we compare it
to its predecessor, that is, I'm not talking about Anglo Jas,
but I'm talking about React. So if we talk about React,
react it's just a view library and it doesn't have
anything at all other than the view portion. And you
(11:45):
know React actually, if you don't use any any kind
of a state like readucx or something like that, there's
only one option to pass data down to all the components.
Is start from the top and keep on passing data,
drilling the props down to all the children. And that's
what Angler has solved. So say, for example, if you
have a ten level of hierarchy and you have a
(12:07):
component at the top having some data, but that top
level component wants to pass the data to the tenth
component in the hierarchy, you'd not actually drill down the
props by the input decorator. Input decorator is really good
when it comes to two levels. So from one level
to the second one, if you want to pass it out,
you know, input is the best thing. However, if from
(12:30):
first level to the tenth level, if you want to
pass the data, input would not actually help much because
that would make a lot of complexity as far as
or complexity going as far as the coding is conformed,
maintainability is con So you're.
Speaker 1 (12:42):
Saying, that's the red flag for someone to look for
is if they're going beyond one level with the inputs.
Speaker 3 (12:50):
Yes, that's the red flag. Like rule of thumb, never
use input twice. That's basically it is. So when that
sort of a scenario occurse, Angler has already saw of it.
You know, Angular has a mechanism called services, and services
follow a Singleton pattern, and that too intrigues me about
Angular that you know, Anglar has you know, I started
(13:11):
off with Anglo Jas and at that point I was
like that was back in two thousand and ten, twelve
ten or eleven, I guess, And at that point I
was not aware of so many design patterns per se.
And then I came in to React, and then I
came into Anglar two at that point. Actually, you know,
during those those few years, I also learned some design
(13:32):
patterns and I saw them being implemented in Angular two.
Because Anglar implements a decorator pattern Angular improvements, of course, NBC,
it implements you know, the singleton pattern as well, and
services are singletons. So singletons basically mean that whenever your
Angular application get initialized, those objects are created and they
(13:55):
reside in the memory somewhere, but they're not created the
second time, which is not the case with the components.
If you create a component, you can create so many
copies of it, like you don't have to actually create copies,
but Angler creates copies of it for you if required. However,
if it is a service which is a singleton object,
and in that singleton object, Angler would never create a copy.
(14:17):
But wherever it is required, Angler would just pass on
a reference. And because it is a reference. Remember, because
it is a reference, it is the same object that
we are accessing. Hence, if the object has some properties
that change. That particular property would be reflected everywhere that
singleton object is access because it's the same reference that
(14:39):
we're talking about. And that's where the whole component communication
is a success because the top level component can now
communicate with the tenth component. We are a service, we
are a messenger mechanism, and that's basically what one of
the ways that we communicate looks like. And that's what
we're focusing on right now.
Speaker 6 (14:59):
So you know, that's really interesting, and that kind of
leads to a conundrum that me and my team have
run into a lot, which is, if you use inputs
and outputs, a component is super reusable, but when you
start to use services, that reusability in a different context
(15:19):
starts to become really difficult. So I don't know, have
you come across that, and do you have any specific
things you've tried to approach in terms of like how
you use services in a way that still allows components
to be reusable without right.
Speaker 4 (15:34):
Right, I understand the question.
Speaker 3 (15:35):
So yes, that is basically that is the trade off,
and then we'd have to handle that trade off because
service is obviously something if you want to use in
a component as a service, your component becomes dependent on
that service, and that's where the dependency injection comes into
the picture, and your services are injected into the component.
So basically, your component would not be able to function
(15:58):
without a specific se So, so what we generally approach it,
or how I have generally seen people approaching or approaching this,
or maybe you know implemented at some places, is that
we create a generic service, something like ngr X you
may say, or something like reducts you know, but not
(16:19):
exactly that a very miniature version of that basically where
we pass on some payloads along with whatever the messages
that we have. So basically they'll be it's the same
thing as reducs, like it'll be message type or basically
the action type and the payload basically, so it will
be a generic service that all the component would be
(16:41):
dependent on. And then whatever type of message that you
want to pass and you can pass in, the component
that consumes that service would check for the type and
then if the type is available or if the type matches,
then the component would do something. Otherwise it will not.
So that is one way of working around that sort
of a scenario where you can create a genetic service.
(17:02):
The component would anyways be dependent on the service that
is that is for sure.
Speaker 6 (17:06):
Well, yeah, that's that's really interesting. We hadn't thought through
using like a more generic service, so that's that's pretty cool.
We've we've kind of gone a route where we try
to have a like parent component that is tied to
the service and then it embeds like just a display
component inside of it, so that we kind of like
(17:28):
we utilize the service to get it down to a
lower level, which we call like a smart component, and
then we have like a display component embedded inside which
is using the inputs and outputs, which ends up being
a lot of infrastructure, but it helped genericize things. So no,
I like that generic service.
Speaker 7 (17:46):
That's awesome.
Speaker 3 (17:47):
Yeah, and I have seen this sort of a mechanism
that you're mentioning, and if I give you an example
of that, I think we would all everyone, every listener
would be more clear for it. Like if we talk about,
for example, log in form, then the setup that you
were explaining would be a log in page and a
log in form two components, and your page would be
(18:07):
the one that would be consuming the service, where the
log inform would be more or less a display component
with inputs and output.
Speaker 4 (18:12):
So that's sort of a thing.
Speaker 3 (18:14):
And all the business logic, like all the validations and
all would be in the log in page rather than
the log in or maybe it can be in the
log in form. I mean, it doesn't matter. The whole
question is consuming the service. So while what I say
in this particular case is just have a log inform
component and have your generic service and you know, let
the log inform consume the generic service and you know, then.
Speaker 4 (18:34):
Run with it.
Speaker 3 (18:34):
So so that is that is basically, but both the
approaches I find it good because I have been programming
in you know, reducts, and this this the one that
we discussed about a page and a form. That approach
comes in from reducts because sorry, react in reducts, I'm sorry,
where you know, people do this kind of a thing
where there is a page and then there is a.
Speaker 4 (18:55):
Form sort of a thing.
Speaker 3 (18:56):
So so yeah, that approach is also something that I
have used for a long time. But Angular, you know,
has changed things a lot, and that's why this genetic
service seems more applicable to me. And I have not
used that page and form sort of a thing with
Angular at any time, but I would like to, you know,
since you have mentioned that you have tried and tested it,
I would like to do that someday.
Speaker 6 (19:18):
Are there any other types of communication that you've played
around with? Obviously you know you mentioned reducts in the background.
Obviously there's different libraries. What other types of approaches have
you done.
Speaker 3 (19:28):
I've also gone for ng r X, but then for
some reason, I always feel that ng RX is an overkill.
And the reason is ng RX is all reactive state management, right,
so it uses rxts and makes everything reactive. But if
you think about it, Angular services themselves are reactive even
without ur xts. So if you go for a subject
(19:50):
and observable mechanism, services would still work and they would
be reactive and all, which gives you sort of an
NGRX feel, but not with those actions and all those things,
you know, but you can implement that on, you know,
in a custom basis. But then again, if you don't
use observables now or or subject and if you create
services as a singleton object in JavaScript, if you think
(20:11):
about JavaScript now, in JavaScript, objects are always past their references.
So if I create an object, like if you go
for basic JavaScript vanilla JavaScript, if I create an object,
and if I assign one variable to that object, now
that variable becomes a reference to that particular object by default.
So so that is the way JavaScript works, and Angular
(20:32):
services actually use you know, a JavaScript unknowingly that way,
so they are already reactive. So because services are singletons
and they are objects, they are there somewhere in the memory.
And basically, dependency injection is equality of one variable to
the service variable and that equality is always a reference.
So if you change anything inside the service, you would
(20:54):
get that reflected no matter what, unless you're calling an
API or something. So so say, for example, if I
have let's take a basic alert message example and usage
of subject and observable. Right, So in an alert message service,
I would never use subject and observable because that itself
is reactive. It doesn't communicate with any API or anything
like that. But say, for example, if it's if it's
(21:15):
a resource that we are trying to consume let's say
an employee from an API server, at that point, the
subject and observable would be something that we would be
using because at that point there will be no connection
as a so there is decisions if you want to
take you know, if you want to create services where
if you want to just let Javas control with it,
(21:36):
you know, have objects and let JavaScript do the trick
and you know, make it abstract for the developer. Yeah,
a new developer, a fresher would always wonder what is happening,
but you know, experienced JavaScript developers would know that, okay,
objects are always references and hence the alert messages are
passing in all so you might have to make that clear.
But then if you want more control over it, and
(21:56):
you know, if you want to have API calls done,
at that point you use subject and observable as well.
So that is that is also some decisions that we
want we might want to take if you if you
don't want to beat resource and intensive.
Speaker 5 (22:08):
Thanks right, I mean I've been sort of furiously scribbling
down my thoughts as you've been going through this. Thanks
very much for all that, because it's been fascinating. Actually yeah,
I mean, so one of the things I wrote down
is is finding the balance.
Speaker 7 (22:22):
I will just elaborate on that a little bit.
Speaker 5 (22:24):
I remember when I when I first learned about the
you know, having a shared service for passing data between components,
you know, it was it was kind of eye opening
to me because you know, as a as a brand
new Angular developer, I have experienced what you've described as
where you just end up with this huge chain of
input and output, which is is absolutely fine when you're
talking just between a couple of components and you know,
(22:46):
exactly as you say, but then yeah, you can just
end up where you're just you just have this sort
of huge pipe of stuff just go right. It goes
in and then it goes out, and then it goes
in and then it goes out, and it goes in
and it goes out. And then obviously you've got to
handle it going the other way as well, which is
which can be a nightmare. And so yeah, when I
when I first learned the you know, shared service pattern,
it was, it was it was fantastic to me a
(23:06):
little while to figure out what earth was going on.
But yeah, now you know, I'm a big fan of that.
And I recently showed that to a colleague who I
work with who had not seen it before, and you know,
it was the same same result for him.
Speaker 7 (23:18):
He was like, oh, wow, this is great.
Speaker 5 (23:20):
And then recently I was doing a code review for
this colleague and they had this sort of complicate shared
service pattern going on. I was sort of like, wow,
you know, you're literally just passing some data from this
component into the next component. You could just use inputs
and outputs for that. And he's like, nah, after you
showed me this, I can't. I don't like inputs and
outputs anymore. I only like to do it through my subscription.
Speaker 7 (23:44):
Okay, So where where do you find that balance?
Speaker 5 (23:46):
I mean, is it is it cool to to always
just go as a subscription or or should you actually
is there a point where you should go?
Speaker 7 (23:54):
You this is overkilled to use a subscription. In your
thoughts on.
Speaker 3 (23:58):
That, yeah, I would like to explain it by an example. Say,
for example, if we're going for a shopping card UI right,
and in that case, there is a list of products
that we have, and each product has its own thumbnail essentially,
and that thumbnail itself it's a component. Right now, what
(24:19):
we're trying to do is we're trying to basically call
an API for the list of products, and then we're
trying to loop through those list of products, and then
we're trying to render each and every product. So if
we call that list of products a product list component,
and if we call that thumbnail a product item component.
What happens here is that I would not like to
(24:41):
call the API both in the product list and the
product item because when I go for the product list,
I get all the products anyways, and all I need
to then do is the most sensible way is just
to pass it down because then I would not like
to call an API another time, right the second time.
So basically I take the products rendering the product item component.
I just passed that one product down to the product item.
(25:04):
So the balance that we find here is whenever your
web services are like whenever you can save a call
to a web service, and you know it's a two
level hierarchy that you're talking about. At that point, we
can simply go for the input and rest of the
places like where Let's say if we take the same
example like product and the card, right, so card is
a totally different component, and when I add my product
(25:27):
to card, I have to call an API and at
the same time I have to update my card. At
that point, you know, inputs outputs they would like be
bizar like people would be pulling their hairs off if
you go for that sort of an input output communication,
you know, so that is that is where you make
a decision, That is where you strike a balance.
Speaker 7 (25:45):
Yeah, that is.
Speaker 5 (25:46):
That's a great example, thank you. Yeah, yeah, the balance
is super important. And something else I've scribbled down is
I find it sometimes I find it frustrating that sometimes
I want to I want to be able to react
on a change to something that's coming through the input.
Speaker 7 (26:03):
And I feel like, you know.
Speaker 5 (26:04):
If I'm doing it, if I'm changing my values through
a subscription, is easy, right, I just I set up
a subscription, and then I can I can tell my
code to do something when that value has changed.
Speaker 7 (26:17):
But I like, you can't.
Speaker 5 (26:19):
There's not really anything you can do on an input,
is it. I mean other than using on changes, which
I like. Personally, I'd like, don't write any code in
on changes. And I know I've seen, you know, even
in code basis I'm working in at the moment, I
see reams and reams of coding non changes. And maybe
for some people that's cool, but I find that that method,
that life cycle hook, just gets hammered too much. I mean,
(26:40):
am I just am I making a problem that doesn't
exist here in my own head? Or what?
Speaker 3 (26:45):
As far as the input is concerned if we stick
to our principle where we just go for the two
level hierarchy and we are just passing data down just
for the display purposes only. Like Edie was mentioning earlier
that they have a service consumption component and then there
is a display component. So basically there's a smart component
and a dumb component. A dumb component just displace the
data whatever you throw at it, so that point you
(27:06):
don't need control over it, you know, because you need
to just pass the data down and just display it.
Speaker 4 (27:11):
That's it.
Speaker 3 (27:12):
So the problem comes when you need control over that display.
Maybe you want to make a decision on whether to
display something or d else. Major things are done by
the template itself like NGF and all, but still if
you want some programmatic control, at that point what you
mentioned would be applicable where you would need some control
over the values that are changing or maybe make some
(27:33):
decision or maybe log something at least, you know, while
the values change. So at that point inputs would just fail.
But then again the usage of input is what I
would like to again go back to Eddy's example, like
that is the correct usage of input where you just
want to have a dumb component and or I'll call it,
I'll not be rude. I'll call it a presentational component.
Speaker 4 (27:54):
And we.
Speaker 3 (27:56):
Just passed the data out and the component just displace
the data and that's it. So that's that's where the
input comes into the picture.
Speaker 7 (28:03):
So yeah, good.
Speaker 5 (28:03):
So when when you add, when you want to be
able to react on a change, you should be doing
it with a with.
Speaker 7 (28:08):
A with a subject.
Speaker 4 (28:10):
Yes, yes, that's correct.
Speaker 7 (28:12):
Good.
Speaker 6 (28:13):
I have a kind of crazy idea to throw out here,
and I will say this is a hypothetical situation in
case it's a crazy situation, because I would not want
to admit to having written this. But what do you
guys think about having a setter and a getter on
your input? So your input triggers a setter function, which
(28:35):
then allows you to kind of react to the new
values that come in, and then of course you would
store that in a private variable and then have your
getter return that. So it looks like a normal input variable,
but it does magical stuff when the setter is triggered.
Speaker 7 (28:54):
Sounds like madness.
Speaker 3 (28:57):
And that's that's what basically Chris is suggesting, you know,
because at that point when you exactly exactly that is
the scenario way and you want to react to some
changes at that point, you would hypothetically, if it is possible,
you would do that. And I think it might be possible,
like we might want to refer to some hooks that
Angler might have for the component life cycle, and that
(29:18):
might be possible. There might be a possibility. I'm not
quite it's not on top of my head, but it
should be. There should be something like this, you know
what Eddie is describing in the form of life cycle
hooking and Angular.
Speaker 6 (29:30):
Yeah, that was just one thing that came to mind,
So I thought that out there. But definitely, I think
when you have a lot of complicated logic, like you
said Robbie, like you want to switch to services for sure.
Speaker 3 (29:38):
Yeah, so in that case, we use we do use services.
And then comes in nng r X that is the
god of computer component communication. Now this whole idea, like
I always feel frustrated at point at one point in
time where you know, the learners that I teach, they
come in in my Angular class and the first thing
that they ask is are we going to cover X
(30:00):
or not? So in that case, it's like it's like,
I mean, it's not necessary to get nngr X covered,
you know, as far as Angular is concerned, because in
order to cover NGRX, you should have a good experience
working with a very big application that would not work
without this this sort of a reactive state changing mechanism.
(30:22):
And unless that happens, you don't know that you'll not
be able to know the value of what NGRX adds
to your you know, whole application. So what I advise
them is to just go step by step, go with services,
try to implement like I don't even you know, mention
NGRX until at one point they come or until they
come to a point where they think that okay, this
sort of a mechanism like action types and you know
(30:45):
payload and you know dispatching sort of a thing is
necessary or effects are necessary. At that point when when
a learner reaches at that point, I just throw in, Okay,
what you were trying so hard from four to five
days is here NGRX.
Speaker 4 (30:58):
This is the link. You can implement it and you
can go ahead with it.
Speaker 3 (31:00):
So so for most of the cases Angular projects, I
don't think it need AnGRs, it needs ANGIERIC. But ng
RX is again a good way of component communication. But
eventually it's a service that works in the same manner
as any service would, but but then it is more organized.
You know, it's a global variable. We're always advised against
(31:22):
global variables. But then now because we have rebels, we
just come up with an organizational pattern to handle global variables,
and then the whole world uses it, you know, So.
Speaker 4 (31:33):
So that is that is basically what it is.
Speaker 3 (31:35):
So that's what Also, that's also what I love about
reducts and angie r ICs and VUX and you know
more BEX and all those application state management libraries. It's
it's the rebellious nature of those libraries that we are
always right from the college, we were advised against using
global variables, but here we are using global variables managing stuff.
Speaker 4 (31:55):
So that is that is good.
Speaker 5 (31:56):
I think you're right like this, You do see kind
of obsession with ENNGRX. Certainly when it first started to arrive,
it felt like everyone, it's all anyone was sort of
blogging about in the in the angler space and X. Actually,
you know, I've worked on several projects that use it now,
and I could easily say that I think probably only
(32:20):
one of them really needed to have ENJX, you know.
Speaker 1 (32:24):
Because what's good that line, Chris, like, if you're looking
across these projects that you're working with, is it literally
just size of the Cobey's Yeah, I mean.
Speaker 5 (32:34):
Yeah, yeah, I was just working the one that I
think I think would have did benefit from it. It's
just it's an application that was just handling obscene quantities
of data and that data was constantly being shifted around
the application, right, So in that case, it just it
(32:55):
made perfect sense. And in fact, you know, when I
when I came on board that project, they don't been
adding ng RX to it for I think maybe a
couple of months. It was previously just using subscriptions, and
it's just because the app had just grown to such
huge proportions, and say, it was just it was constantly
shuffling data around that was just being accessed by so
(33:18):
many different components sort of at once, who were all
accessing it and changing things and needing to react to
the to the changes. And so in that case, yeah,
it just it made sense to have this sort of
central data store. You know, it's exactly what it is therefore,
to have the central data store where everything could just
tap into that one central location forgetting data.
Speaker 7 (33:38):
And changing it.
Speaker 5 (33:39):
But you know, the project that I worked one directly
before that, one that had engine X in it, and
it was a tiny app that didn't do much and
it was just like just so much work doing all
the ng X stuff when I could easily just have
been piping the stuff around with you know, with my
services and subscriptions. So I think people get a bit
(34:00):
over excited about ng X. And I think there was
I've dug it out. It was in the back of
my mind and I've lost I'm in the wrong browser.
It was a talk by Mike Ryan at Anger to
Connect in twenty eighteen. You might not need ng RX,
And it's like just the fact that the fact that
they need to do a talk telling people maybe that
(34:24):
they don't need it says a lot about how obsessed
people got with it.
Speaker 1 (34:28):
I think, yeah, I think it's hard because people just
get so excited and they're like, it's like whenever you taught,
you taught them, you know, instead of inputs and outputs,
you can use the subject and they're like, well, I'm
going to use this everywhere, and it's the same. It's
the same. Everyone just gets excited and they used it
on all things.
Speaker 3 (34:47):
So yeah, and I would also like to add on
to what Chris just mentioned, there is a rule of
thumb as well in here when that whole flash of genius,
when you want to use angi X in your project,
you know where if that generic service that we were
talking about, Eddie, if if that gets out of hand,
you know, it has so many things that you need
(35:08):
to manage, and at that point you should, you know,
make a decision and move to ng r X. And
that is when there are a lot of components and
you know, your state, as Chris mentioned, is affecting a
lot of things. But right at the onset if you
start with ng r X, because we are always nowadays
like most of the projects are agile, we don't know
(35:28):
at what point a project would go or a project
would end at. So at that point, I mean, even
if you're just using a good service mechanism and good
organized service mechanism which doesn't have any learning curve, that
would also be beneficial for the new newbies or the
team members basically, and you would still be able to
(35:48):
live with ng r X or without en gi ICs.
Speaker 4 (35:50):
I'm sorry.
Speaker 3 (35:51):
So basically it's it's that you know, so there is
always a trade offer, There is always a decision that
you have to take with Angular in every aspect right
from the beginning, because it is really overwhelming. There are
so many things that are there in Angle because it's
a framework, you know, that's the that's the fact of
the matter, and you have to take a decision and
when you stop using or when you stop over using something,
(36:14):
so that is that is there always.
Speaker 6 (36:16):
We talk about how NGRX might not be needed if
a project is too small, and then the assumption is
that like as NGRX gets or as your project gets bigger,
NGRX you know, is more needed on the con or
on the inverse.
Speaker 4 (36:31):
Side of that.
Speaker 6 (36:31):
Like our product at the company I work with, we
actually store so much data that there's no way we
could load all the data into the web browser at once.
Like we actually overwhelm my SQL databases and have to
have this like in memory database called Hannah on some instances.
So like we're talking about hundreds of thousands of you know, entities,
(36:54):
and so because we can't store all of that in
the web browser, we actually have to do all of
our filtering and queerying on the server. Which we didn't
realize this when we started doing DRX and we went
full throat onto NDRX in one segment, but it didn't
occur to us until after that. Because we never have
all the data in the browser, pre filtering it on
(37:16):
the server actually made NGRX almost completely useless to us
and like a lot of overhead because every time we
wanted to change the filters, we had to recreate the
server anyway, and so it was essentially like a temporary
local cache, which was not helpful. So when you get
to the size that your project is so large you
(37:37):
can't load all the data in the browser. That's also
another kind of gotcha with NDRX.
Speaker 4 (37:41):
Yep, So there is a fine line.
Speaker 3 (37:43):
So definitely that's like your in memory database would do
the or would play the role of what NGRX would.
You know, if you're in memory database would not have
been there. So so that is there. And again this
angular or has provided us a lot to work with.
This whole idea of NGI RX comes with the idea
(38:06):
of reducs and React working together and people people just
come from that reactor redex background and they expect something
like reducts to be the savior, but then Angler already
has it in the form of services, where you know
it's a Singleton. You have your data in one place
and you can you know, basically check that data anywhere
(38:29):
that you want to, and at times you don't even
have to use subject an observable pattern. So services are there,
you know, in Angular and we're good that way. So
that is that is there.
Speaker 5 (38:39):
Of course you absolutely the nail and the head with that,
you know. I worked with a young developer a year
or so ago who had come from a strictly React
background but onto a onto an Angular project. Like literally
the first thing he did was just just added and
direx into the project and like request, like what we're doing, Well,
(39:01):
you need it, you know, you need the state management.
Speaker 7 (39:02):
It's like I get it.
Speaker 5 (39:04):
I totally get where it's coming from, you know, because
you you've come just as you said, you know, it's
come from a development environment where state management is a
is a widely used thing. But just you know, Angular
handles so much of that for you. This is this
is part of my my sort of bug bear with
with nj AX, and I now I now have grown
to the point where I don't dislike it because I've
(39:25):
used it enough in places where it's been useful that
it's it's made my life easier. But it's yeah, people's
obsession with just adding it because they think we need
it because it's a thing that exists. But actually, you know,
Angler's state management is is great a lot of the
time until it's not until you get an expression changed
after it was checked there, and it's not great.
Speaker 4 (39:48):
Yeah.
Speaker 3 (39:49):
So so again, I mean this is all nothing, nothing
against anger exist to clarify. Every one of us whould agree.
It's just that as a developer we should have the
capacity of making a this and when to use stuff
and when not to. You should not just be using
things because you can. With great power comes great responsibility.
So that's the responsibility that you have, you know. So
(40:11):
so that is is there's a very classic one, but
that is true.
Speaker 7 (40:15):
Absolutely.
Speaker 5 (40:15):
Bonus points for the Spider Man quote at least ten
bonus points.
Speaker 1 (40:23):
Is that where it originated, because I've heard it in
so many places?
Speaker 3 (40:26):
Yeah, yeah, the first Spider Man, I guess I heard it.
Speaker 7 (40:31):
I dare you even ask that question?
Speaker 2 (40:34):
My bad.
Speaker 1 (40:35):
Apparently Spider Man is more sacred than state management to Chris, So.
Speaker 7 (40:40):
You can't say it because the position of my webcom
I've got a.
Speaker 2 (40:44):
Right spider Man right right next to your minecraft.
Speaker 5 (40:50):
Pick right here, there's one I can't reach. I love
Spider Man anyway.
Speaker 4 (40:57):
Nice, So I made Spider Man now or.
Speaker 7 (41:03):
Ie going for hours?
Speaker 1 (41:04):
If we did that, they're actually coming up on the
top of the hour Rabbi, and I was wondering, is
there any like last closing statements that you'd like to
say before we move on to pics about just really
you know, component communication and what you suggest people do
and resources, et cetera.
Speaker 3 (41:26):
So what I suggest, like not not only component communication,
but more of a general thing whenever you want to Like,
this is for the learners, because I think along with
the developers, there would be people who might want to
learn Angler who might be listening to this particular podcast.
So if you want to learn something, just go to
the official documentation and that's it, all right, So you
(41:49):
don't have to most of the time, you don't have
to hop around seeing long videos just to implement certain things.
You know, official documentations are great as far as Angler
is concerned, it's awesome. That is that is where I
learn most of the things from, and then I go
to the videos if something like some people might have
some different thought process, and that is also important to
(42:10):
grasp no disrespect to anyone, So we might just we
might just want to have the documentation to be preferred first.
Then the rest of about component communication, services, subject and observable,
Like you should know what a subject is, you should
know what a behavior subject is and observable is, and
you know how to implement it. Maybe you know, if
(42:31):
you want to have reactive local storage, you might want
to go for a behavior subject. But if you don't
want to do that, that is also possible. So RXGS
is also not the answer to everything. So with for example,
you know, last example I would give is that if
for example, I have my user and my token in
my local storage, and I have a user service getting
(42:53):
that local storage for me, it is not necessary for
me to use any RXTS concept. Still it would be
reactive because that's how services in Angular work. So so
so basically, the bottom line is Angular has provided us
a lot of things to work with, and it is
it is just not fair to go for other options
(43:13):
unless you already have tried your hand on the existing
ones and you know, if that doesn't work for you,
then go for external resources. Because we don't want to
make our app heavier than it is already you know, so,
so that is that is basically what it is.
Speaker 2 (43:28):
Wonderful, wonderful.
Speaker 1 (43:30):
Well, I honestly I really loved listening to you explain things,
and the examples you had were just incredible. I think
it really lent a great hand to audio only podcasts.
I think, so thank you for the coming on and
teaching us and walking through things. Before we jump over
to pics, I just wanted to say that I can
see why people like seek you out for training because
(43:53):
I could clearly listen to you talk all day.
Speaker 3 (43:55):
So the thing is just a fun fact. The other day,
like every time I review my video, I just sleep
halfway down, you know, I just fell asleep. I just
fall asleep when I just review my own videos that
I record.
Speaker 4 (44:10):
You know.
Speaker 3 (44:11):
So, I don't know about others, but I don't really
enjoy listening to myself that much.
Speaker 5 (44:18):
Great great advertisement there for your I put myself to sleep, guys.
Speaker 1 (44:27):
I make it a rule of thumb never to listen
to myself. So, so, does anybody have picks Eddie or
Chris before we let Rabi.
Speaker 2 (44:38):
Do some pics.
Speaker 7 (44:39):
Yeah, I got one pick.
Speaker 5 (44:40):
The whole of like social media, certainly in my social
media feed is just full of people obsessing over animal
crossing at the moment looking at Eddie, now he's one
of them. Naturally, I've done the only sensible thing. And
I recently acquired a copy of Pokemon Sword for my
(45:01):
switch and I've been really enjoying it. It's really good.
I'm trying to resist the animal crossing bandwagon. But I
feel like that raccoons coming after me.
Speaker 6 (45:10):
He's hunting you down.
Speaker 1 (45:12):
Literally, there's a raccoon chasing you.
Speaker 5 (45:14):
Because you know, I don't think we have raccoons over here,
so I think I'm probably all right. We got our
own stuff. But yes, my pig Pokemon, I enjoy it nice.
Speaker 6 (45:25):
Yeah, I've got two picks. One I don't think I've
said this before. If I have, we'll repeat pick. But
one pick is century like a guard s E n
t r o I. It's a service that allows you
to report basically like jobscript errors and stuff to a
third party server so that you can then see, like
(45:48):
you know, of your software installation, like what errors are
coming back and so for a long time, like we've
had no way like we find bugs with our QA team,
like through our usage, but we have you know, if
a customer doesn't say, hey, I have this bug, like
we have no way to know. And so we've started
implementing that and it's really interesting just to be able
(46:11):
to suddenly have an error pop up on a dashboard
and be like, oh wow, like okay, someone ran into
the air, like and it shows you where in the
code as if you're looking at the JavaScript console and
it shows like what they clicked on just before and stuff.
So we haven't gotten to use a whole whole lot,
but definitely started to dive into it and it's really exciting.
So I am super excited about that. And my second
(46:32):
pick is so I was one of those Evernote people
that like started putting everything in EVERYNOE when it came
out with the web clipper and everything, and it was
like my brain for everything. And then they went through
all their changes and nothing against every note, but I
got less excited about EVERYNOE. The problem is I had
no replacement, and so I've just gone without an external brain,
(46:56):
which is not super helpful. And so this I found Notion,
which I'm probably late to the notion train. Probably everyone
else knows about notion, but Notion essentially like allows you
to kind of replace like Google Docs, and it has
some like kind of basic like task tracking stuff in
(47:16):
it and like stuff. But for me, it seems like
a really big replacement for ever Note, where I can
just kind of put all my thoughts in there. I
can take notes in there. It has a web clipper,
and so if I'm on a website, I can be like, hey,
grab this HTML, throw it into a page and Notion.
So I'm just getting started with it this week, but
I am really excited to have a replacement for ever
(47:39):
Note after my long dark the like.
Speaker 1 (47:43):
To use the client on like the app, or to
use like inside the browser, Like how do you use it?
Speaker 6 (47:50):
Yeah, so I have an app on my Mac and
then and I haven't started. I know there's an app
FM on iPhone, but I haven't done that yet. But yeah,
in the webread like I use a web clipper plug
in for the browser. But then the actual engaging with
the material I use in the Mac app.
Speaker 2 (48:08):
Okay cool.
Speaker 1 (48:09):
I've been addicted to Dropbox paper for a while now,
but sometimes the like offline experience can be painful. So
so yeah, I will definitely check out Notion.
Speaker 2 (48:23):
It's a great pick.
Speaker 6 (48:24):
Yeah, for sure, It's pretty cool, So that's mine awesome.
Speaker 1 (48:28):
I've been playing around with the Oculus quest lately. My
work sent me and the other advocates on my team
one they said, hey, we want you to start programming
in Unity and making online events for people, and I
was like, that's crazy cool. So I've actually never put
on a headset before this, so if you haven't, then
you get an opportunity to. I definitely suggested because I
(48:49):
was one of those naysayers. I was like, it's not
going to be that cool, and it literally blew my mind.
So definitely, if you get a chance to put on
a VR headset, I would recommend trying it out.
Speaker 2 (49:03):
So yeah, that's my pick. But also Ravi is my pick.
Speaker 1 (49:07):
I'm actually so I'm so excited to have met you
and follow you on all the social medias, So can
you please tell us where people can find you and
reach out to you and learn from you.
Speaker 3 (49:18):
So I have my YouTube channel goes by my name itself,
Rubb Valiat, and I have some Angular tutorials going on
right now in that particular channel itself, so you would
have you'd be able to, you know, see the tutorials here.
And then my last name Valiate dot com is my
(49:39):
website or my contact info is provided in there. Anyone
who wants to basically share any thoughts or maybe ask
any questions, they can directly. I get emails from people
asking some doubts or questions or you know, some problems
that they have with their projects and all, and I
try my best to, you know, answer them basically to
the best of my abilities.
Speaker 4 (50:00):
So so that's where. And then you can follow my Twitter.
Speaker 3 (50:03):
Same name, you know, So so there are base if
you just google my name, I think my website might
come up, so that is also there.
Speaker 4 (50:13):
These are the ones that you can follow.
Speaker 1 (50:15):
Yeah, and I want to spell it, so it's our
A V I it's his first name, and then V
E l I y A T for his last name.
Speaker 2 (50:22):
So definitely worth to follow. A very cool cat. So
thank you well.
Speaker 1 (50:28):
Awesome, Thank you gentlemen for the marvelous episode today. Uh
everyone has fun and safe programming for this afternoon and
we'll see you guys for the next one.
Speaker 2 (50:39):
So thank you so much.
Speaker 4 (50:40):
Thank you, Thank you everyone, Thank you for having me here.
Yea great chase everyone, Bye, thank you Bye.
Hello, everybody, welcome to Adventures in Angular. My name is
Alyssa Nicel and today with us on the panel we
have Eddie Hinkle, Hey everyone, and.
Speaker 2 (00:15):
Chris Ford good day.
Speaker 1 (00:19):
And our marvelous guest is Rabbi dell Yat.
Speaker 3 (00:23):
Say hello, Rabi, Hey, how are you? And thank you
for having me here, by the.
Speaker 2 (00:26):
Way, absolutely thanks for joining us.
Speaker 1 (00:29):
So, Rabbi, tell us a little bit about yourself and
what you do in the Angular community.
Speaker 3 (00:35):
So let me start when I started off my career
back in two thousand and eight. I started off as
a junior PHP developer and then moved on to a
senior position, then a tech.
Speaker 4 (00:46):
Lead and a team lead.
Speaker 3 (00:47):
And you know, meanwhile I also went along with Angular
development as well, then came in no JS and then Reacted,
then Angular two point zero and now I'm looking I
will talk about that, by the way, that's an interesting topic.
But now I'm working with vugs as well, and as
far as back in programming is concerned, I do no
(01:08):
JS and Laura well as well. And I've been training
people since two thousand and eight. You know, whatever I can,
I try to teach people. That's how I learned things,
you know. So from that day till Greate twelve years
into training and the last company that I left, I
was a project manager and I had a team of
like thirty people, thirty odd people ranging from all the
types of developers and qas and the designers aug. So
(01:31):
then I left the company. I didn't want to spend
the rest of life with those thirty people. I wanted
to meet more people, so mainly into training after that,
And they're doing some consulting as well.
Speaker 4 (01:41):
And I've trained people that with procats.
Speaker 3 (01:45):
And and I conduent Aviva, at is alat PCs and
like those that are a few of them, and then
there are a lot of smaller companies who might train
at So I've been lucky that way.
Speaker 2 (01:57):
So you've like basically done it all.
Speaker 1 (02:00):
You've gone from development to teaching to managing. There's like
no and like from front end to back end. So
it's like no side of it you haven't touched.
Speaker 4 (02:10):
Yeah, I don't have any complaints. Yeah I have.
Speaker 3 (02:13):
I have almost touched all the Like I'm like the
jack of all trades and ace of none, so at
least I can make it make it good.
Speaker 5 (02:21):
In training, I was just thinking that I feel like
we finally found the mythical Tenex developer.
Speaker 4 (02:29):
Maybe I don't know.
Speaker 1 (02:32):
So Robbie, what are we talking about today?
Speaker 2 (02:35):
What is our topic?
Speaker 3 (02:36):
So we're talking about component communication and Angular and the
reason that I have chosen this topic is that it
is quite interesting and quite varied as far as the
communication is concerned, as far as Angular components are. So
we'd be talking about components and how you know, components
came in or how components are developed in Angular and
(02:58):
how they're communicating with another through services and even if
no services had there, how can they communicate?
Speaker 4 (03:04):
So that is that's basically what it is.
Speaker 2 (03:06):
Very cool.
Speaker 1 (03:07):
Well, let's dive right in, and I actually wanted to
ask you talk about doing training. Is it full stack
training that you do or Angular specific?
Speaker 4 (03:16):
It is full stack.
Speaker 3 (03:16):
I started off as a React trainer and you know
back in the day, I used to train people in Php.
So from Php to React to Angular and then we
would now know JS and Larval, so pretty.
Speaker 4 (03:29):
Much full stack.
Speaker 2 (03:30):
Cool. That's awesome.
Speaker 4 (03:32):
So shall we start the topic.
Speaker 2 (03:34):
Absolutely, let's dive in, sure.
Speaker 3 (03:36):
So I would like to start it off with a
little bit of a background on Angler for all the listeners.
Anglargs was in the late two thousand and late two
thousand and twenty ten decade, anglo JS came into the picture,
and that particular technology was the one which introduced components
to us. However, they were not used as much because
(03:59):
the whole aim of anglo gs was to fit into
the development that the developers do. You know, back in
the day, the developers did and at that point developers
were not very much at home with components and all.
But still anglo GS had components, and then came in React,
and React was the one that actually ran with components itself,
(04:20):
and it was then that all the developers accepted widely
that components are actually the way that frontment would go.
Speaker 1 (04:27):
I didn't realize that React was that old like that.
So did React happen before Angular two hit?
Speaker 4 (04:33):
Yes?
Speaker 3 (04:34):
Yes, and and that was the reason Angler two happened.
You know, if you think about it, I mean nothing
officially that I have read, But if we think about it,
anglo JS and React they have different types of handling
the document object model. And if anglo JS would have
been the way it would have been or the way
(04:54):
it is right now, then Angler would not have been surviving.
The whole race you know, and that that's what I
think where Google took a decision that let's risk it,
let's bring it totally, like, let's do totally something new
which is component centric and which handles the dorm better,
you know, even better than React if possible. And that's
why that's why probably I think Angler two and two
(05:16):
plus versions are now you know, into the market. Otherwise
it would if React would not have been there, then
I think Anglo js would have been the way people
would have gone for.
Speaker 1 (05:26):
I know, talking with the team, they a lot of
they just had so many issues with the Angular JS
that they didn't see a way around without without the
basically essential rewrite. So I know it was painful, like
you were alluding to, but necessary.
Speaker 4 (05:46):
Definitely.
Speaker 3 (05:47):
The verbosity of JavaScript was mainly the cause, and mainly
the way the variables were handled and all. And you know,
there was no There was something called a constructor pattern
as far as class and object creation is concerned, and
that was basically a function which has a lot of
context to it, which is not how a function should
(06:09):
or should be, And then Typescript solved all the problems
for them. It was actually really courageous of the Angular
team to just remember everything, and you know, they just
had to risk the whole reputation and it actually had
a lot of I cannot say bad reputation, but developers
actually didn't believe in Angular at that point when Angler
two came into the market. But then again, now it
(06:32):
is all again, you know, all all set to normal
by God's grace, because it is Google that we're talking about,
and it is it is actually doing things a lot,
a lot better than so many other frameworks.
Speaker 4 (06:44):
In the same same thing.
Speaker 3 (06:45):
And yes, so coming back to components, so so just
to just for the record, components where they're in Anglo
jas as well. And now Angular two or two plus
is having components as their basic building blocks, and components
are meant to be in individual entities which are decoupled
and decoupled to such an extent that a team in
India can code on one component, a dream in a
(07:07):
US can code on another component and still they won't
face any problems considering the code conflicts, or only if
there is a miscommunication between the teams would they face
any problems. You know, so it's a human error that
would lead to any problem if it is a component.
PAS programming now provided that these are decoupled entities, there
should be some mechanism that the developers should be able
(07:29):
to take and they should be able to pass data
between these entities just to bridge them together or maybe
make them work together with each other. So that's where
the component communication that we are talking about comes into
the picture. And then what I also think is that
even if there is like one sort of a set
one sort of hierarchy that we think about where parent components,
(07:52):
where a parent component has a lot of child components
at all, in that case, also there is a communication
going on between the parent and the child. At that point,
there's no bridge required because they are like connected. So
interconnected component like parent and child easily can communicate between
one another. And then there are like two separate components
altogether who are nowhere related to one another, and then
(08:13):
they can also communicate. So these are like some types
of component communication that we'd like to.
Speaker 4 (08:20):
Throw some light on.
Speaker 3 (08:21):
So first type of communication that we talk about is
a parent and child communication. So if you imagine any
component hierarchy, a component hierarchy is always a composition model.
So when I say parent and child, we should not
misunderstand that by the fact that a parent would always
(08:41):
be inherited by a child. In a component based architecture,
the parent is always composed of a child, which means
the parent is at the top end the child is
at the bottom of the hierarchy. In an inheritance model,
it's a different it's quite the opposite thing. So in
any component based architecture, parent would be at the top,
child child components would be below parent, and then so
(09:04):
on and so forth. So there is an easy way,
you know, if you think about a hierarchy itself, a
parent can easily, you know, pass a prop down to
the child and that's where one of the decorators in
an angler and now angler follows a decorator pattern which
is very powerful. One of the decorators, called input decorator
is what helps the patent to pass down.
Speaker 4 (09:23):
Data to the child.
Speaker 3 (09:24):
So basically the child receives the data as input from
the parent and hence the name of.
Speaker 4 (09:29):
The decorator input.
Speaker 3 (09:30):
So basically a child can take data as much as
it wants as properties through the parent and the parent
can pass it on. So basically that's one set of
a communication. And when the parent changes that data because
it is a property inside a child, the child's UI
would change, so that's also that's also something that angler
(09:51):
has and it is really interesting where any property that
changes inside a component, it would change or re render
the template the HTML of the component. So if a
parent change is a property which has been passed as
a property to a child as an input, the child
would also change. So that is one way of communicating
from parent to child. So there is a parent child
(10:12):
communication going on, and then there is the other way
around the opposite right, the opposite so where the child
component can communicate with the parent, like child component can
send some messages to the parent. So that is something
called event that the child emits, and there's a thing
called event emitter that helps you to emit the events.
So at that point, there is a decorator called output
(10:34):
decorator that helps you to get the output from the
child to the parent.
Speaker 4 (10:38):
So input and output are quite opposite.
Speaker 3 (10:40):
So if you imagine input decorator being used to drill
the data down, output decorator can be used to pass
the data upwards to the parent and output decorator is
pretty tricky, I mean not that tricky, but it's not
as straightforward as the input decorator input is really easy,
but output has some other entities involved because output is
essentially emitting events. It's not like passing the data, but
(11:02):
it is emitting the events, and the parent is listening
to the event. So so those parent and child communications
are some things that people generally do in Angular components.
Then people get carried away and then people keep on
passing the data down to the props, right right from
(11:22):
the top component right to the bottom component. And that's
what Angular, you know, try to avoid. And that's where
Angler has fixed things. You know, if we compare it
to its predecessor, that is, I'm not talking about Anglo Jas,
but I'm talking about React. So if we talk about React,
react it's just a view library and it doesn't have
anything at all other than the view portion. And you
(11:45):
know React actually, if you don't use any any kind
of a state like readucx or something like that, there's
only one option to pass data down to all the components.
Is start from the top and keep on passing data,
drilling the props down to all the children. And that's
what Angler has solved. So say, for example, if you
have a ten level of hierarchy and you have a
(12:07):
component at the top having some data, but that top
level component wants to pass the data to the tenth
component in the hierarchy, you'd not actually drill down the
props by the input decorator. Input decorator is really good
when it comes to two levels. So from one level
to the second one, if you want to pass it out,
you know, input is the best thing. However, if from
(12:30):
first level to the tenth level, if you want to
pass the data, input would not actually help much because
that would make a lot of complexity as far as
or complexity going as far as the coding is conformed,
maintainability is con So you're.
Speaker 1 (12:42):
Saying, that's the red flag for someone to look for
is if they're going beyond one level with the inputs.
Speaker 3 (12:50):
Yes, that's the red flag. Like rule of thumb, never
use input twice. That's basically it is. So when that
sort of a scenario occurse, Angler has already saw of it.
You know, Angular has a mechanism called services, and services
follow a Singleton pattern, and that too intrigues me about
Angular that you know, Anglar has you know, I started
(13:11):
off with Anglo Jas and at that point I was
like that was back in two thousand and ten, twelve
ten or eleven, I guess, And at that point I
was not aware of so many design patterns per se.
And then I came in to React, and then I
came into Anglar two at that point. Actually, you know,
during those those few years, I also learned some design
(13:32):
patterns and I saw them being implemented in Angular two.
Because Anglar implements a decorator pattern Angular improvements, of course, NBC,
it implements you know, the singleton pattern as well, and
services are singletons. So singletons basically mean that whenever your
Angular application get initialized, those objects are created and they
(13:55):
reside in the memory somewhere, but they're not created the
second time, which is not the case with the components.
If you create a component, you can create so many
copies of it, like you don't have to actually create copies,
but Angler creates copies of it for you if required. However,
if it is a service which is a singleton object,
and in that singleton object, Angler would never create a copy.
(14:17):
But wherever it is required, Angler would just pass on
a reference. And because it is a reference. Remember, because
it is a reference, it is the same object that
we are accessing. Hence, if the object has some properties
that change. That particular property would be reflected everywhere that
singleton object is access because it's the same reference that
(14:39):
we're talking about. And that's where the whole component communication
is a success because the top level component can now
communicate with the tenth component. We are a service, we
are a messenger mechanism, and that's basically what one of
the ways that we communicate looks like. And that's what
we're focusing on right now.
Speaker 6 (14:59):
So you know, that's really interesting, and that kind of
leads to a conundrum that me and my team have
run into a lot, which is, if you use inputs
and outputs, a component is super reusable, but when you
start to use services, that reusability in a different context
(15:19):
starts to become really difficult. So I don't know, have
you come across that, and do you have any specific
things you've tried to approach in terms of like how
you use services in a way that still allows components
to be reusable without right.
Speaker 4 (15:34):
Right, I understand the question.
Speaker 3 (15:35):
So yes, that is basically that is the trade off,
and then we'd have to handle that trade off because
service is obviously something if you want to use in
a component as a service, your component becomes dependent on
that service, and that's where the dependency injection comes into
the picture, and your services are injected into the component.
So basically, your component would not be able to function
(15:58):
without a specific se So, so what we generally approach it,
or how I have generally seen people approaching or approaching this,
or maybe you know implemented at some places, is that
we create a generic service, something like ngr X you
may say, or something like reducts you know, but not
(16:19):
exactly that a very miniature version of that basically where
we pass on some payloads along with whatever the messages
that we have. So basically they'll be it's the same
thing as reducs, like it'll be message type or basically
the action type and the payload basically, so it will
be a generic service that all the component would be
(16:41):
dependent on. And then whatever type of message that you
want to pass and you can pass in, the component
that consumes that service would check for the type and
then if the type is available or if the type matches,
then the component would do something. Otherwise it will not.
So that is one way of working around that sort
of a scenario where you can create a genetic service.
(17:02):
The component would anyways be dependent on the service that
is that is for sure.
Speaker 6 (17:06):
Well, yeah, that's that's really interesting. We hadn't thought through
using like a more generic service, so that's that's pretty cool.
We've we've kind of gone a route where we try
to have a like parent component that is tied to
the service and then it embeds like just a display
component inside of it, so that we kind of like
(17:28):
we utilize the service to get it down to a
lower level, which we call like a smart component, and
then we have like a display component embedded inside which
is using the inputs and outputs, which ends up being
a lot of infrastructure, but it helped genericize things. So no,
I like that generic service.
Speaker 7 (17:46):
That's awesome.
Speaker 3 (17:47):
Yeah, and I have seen this sort of a mechanism
that you're mentioning, and if I give you an example
of that, I think we would all everyone, every listener
would be more clear for it. Like if we talk about,
for example, log in form, then the setup that you
were explaining would be a log in page and a
log in form two components, and your page would be
(18:07):
the one that would be consuming the service, where the
log inform would be more or less a display component
with inputs and output.
Speaker 4 (18:12):
So that's sort of a thing.
Speaker 3 (18:14):
And all the business logic, like all the validations and
all would be in the log in page rather than
the log in or maybe it can be in the
log in form. I mean, it doesn't matter. The whole
question is consuming the service. So while what I say
in this particular case is just have a log inform
component and have your generic service and you know, let
the log inform consume the generic service and you know, then.
Speaker 4 (18:34):
Run with it.
Speaker 3 (18:34):
So so that is that is basically, but both the
approaches I find it good because I have been programming
in you know, reducts, and this this the one that
we discussed about a page and a form. That approach
comes in from reducts because sorry, react in reducts, I'm sorry,
where you know, people do this kind of a thing
where there is a page and then there is a.
Speaker 4 (18:55):
Form sort of a thing.
Speaker 3 (18:56):
So so yeah, that approach is also something that I
have used for a long time. But Angular, you know,
has changed things a lot, and that's why this genetic
service seems more applicable to me. And I have not
used that page and form sort of a thing with
Angular at any time, but I would like to, you know,
since you have mentioned that you have tried and tested it,
I would like to do that someday.
Speaker 6 (19:18):
Are there any other types of communication that you've played
around with? Obviously you know you mentioned reducts in the background.
Obviously there's different libraries. What other types of approaches have
you done.
Speaker 3 (19:28):
I've also gone for ng r X, but then for
some reason, I always feel that ng RX is an overkill.
And the reason is ng RX is all reactive state management, right,
so it uses rxts and makes everything reactive. But if
you think about it, Angular services themselves are reactive even
without ur xts. So if you go for a subject
(19:50):
and observable mechanism, services would still work and they would
be reactive and all, which gives you sort of an
NGRX feel, but not with those actions and all those things,
you know, but you can implement that on, you know,
in a custom basis. But then again, if you don't
use observables now or or subject and if you create
services as a singleton object in JavaScript, if you think
(20:11):
about JavaScript now, in JavaScript, objects are always past their references.
So if I create an object, like if you go
for basic JavaScript vanilla JavaScript, if I create an object,
and if I assign one variable to that object, now
that variable becomes a reference to that particular object by default.
So so that is the way JavaScript works, and Angular
(20:32):
services actually use you know, a JavaScript unknowingly that way,
so they are already reactive. So because services are singletons
and they are objects, they are there somewhere in the memory.
And basically, dependency injection is equality of one variable to
the service variable and that equality is always a reference.
So if you change anything inside the service, you would
(20:54):
get that reflected no matter what, unless you're calling an
API or something. So so say, for example, if I
have let's take a basic alert message example and usage
of subject and observable. Right, So in an alert message service,
I would never use subject and observable because that itself
is reactive. It doesn't communicate with any API or anything
like that. But say, for example, if it's if it's
(21:15):
a resource that we are trying to consume let's say
an employee from an API server, at that point, the
subject and observable would be something that we would be
using because at that point there will be no connection
as a so there is decisions if you want to
take you know, if you want to create services where
if you want to just let Javas control with it,
(21:36):
you know, have objects and let JavaScript do the trick
and you know, make it abstract for the developer. Yeah,
a new developer, a fresher would always wonder what is happening,
but you know, experienced JavaScript developers would know that, okay,
objects are always references and hence the alert messages are
passing in all so you might have to make that clear.
But then if you want more control over it, and
(21:56):
you know, if you want to have API calls done,
at that point you use subject and observable as well.
So that is that is also some decisions that we
want we might want to take if you if you
don't want to beat resource and intensive.
Speaker 5 (22:08):
Thanks right, I mean I've been sort of furiously scribbling
down my thoughts as you've been going through this. Thanks
very much for all that, because it's been fascinating. Actually yeah,
I mean, so one of the things I wrote down
is is finding the balance.
Speaker 7 (22:22):
I will just elaborate on that a little bit.
Speaker 5 (22:24):
I remember when I when I first learned about the
you know, having a shared service for passing data between components,
you know, it was it was kind of eye opening
to me because you know, as a as a brand
new Angular developer, I have experienced what you've described as
where you just end up with this huge chain of
input and output, which is is absolutely fine when you're
talking just between a couple of components and you know,
(22:46):
exactly as you say, but then yeah, you can just
end up where you're just you just have this sort
of huge pipe of stuff just go right. It goes
in and then it goes out, and then it goes
in and then it goes out, and it goes in
and it goes out. And then obviously you've got to
handle it going the other way as well, which is
which can be a nightmare. And so yeah, when I
when I first learned the you know, shared service pattern,
it was, it was it was fantastic to me a
(23:06):
little while to figure out what earth was going on.
But yeah, now you know, I'm a big fan of that.
And I recently showed that to a colleague who I
work with who had not seen it before, and you know,
it was the same same result for him.
Speaker 7 (23:18):
He was like, oh, wow, this is great.
Speaker 5 (23:20):
And then recently I was doing a code review for
this colleague and they had this sort of complicate shared
service pattern going on. I was sort of like, wow,
you know, you're literally just passing some data from this
component into the next component. You could just use inputs
and outputs for that. And he's like, nah, after you
showed me this, I can't. I don't like inputs and
outputs anymore. I only like to do it through my subscription.
Speaker 7 (23:44):
Okay, So where where do you find that balance?
Speaker 5 (23:46):
I mean, is it is it cool to to always
just go as a subscription or or should you actually
is there a point where you should go?
Speaker 7 (23:54):
You this is overkilled to use a subscription. In your
thoughts on.
Speaker 3 (23:58):
That, yeah, I would like to explain it by an example. Say,
for example, if we're going for a shopping card UI right,
and in that case, there is a list of products
that we have, and each product has its own thumbnail essentially,
and that thumbnail itself it's a component. Right now, what
(24:19):
we're trying to do is we're trying to basically call
an API for the list of products, and then we're
trying to loop through those list of products, and then
we're trying to render each and every product. So if
we call that list of products a product list component,
and if we call that thumbnail a product item component.
What happens here is that I would not like to
(24:41):
call the API both in the product list and the
product item because when I go for the product list,
I get all the products anyways, and all I need
to then do is the most sensible way is just
to pass it down because then I would not like
to call an API another time, right the second time.
So basically I take the products rendering the product item component.
I just passed that one product down to the product item.
(25:04):
So the balance that we find here is whenever your
web services are like whenever you can save a call
to a web service, and you know it's a two
level hierarchy that you're talking about. At that point, we
can simply go for the input and rest of the
places like where Let's say if we take the same
example like product and the card, right, so card is
a totally different component, and when I add my product
(25:27):
to card, I have to call an API and at
the same time I have to update my card. At
that point, you know, inputs outputs they would like be
bizar like people would be pulling their hairs off if
you go for that sort of an input output communication,
you know, so that is that is where you make
a decision, That is where you strike a balance.
Speaker 7 (25:45):
Yeah, that is.
Speaker 5 (25:46):
That's a great example, thank you. Yeah, yeah, the balance
is super important. And something else I've scribbled down is
I find it sometimes I find it frustrating that sometimes
I want to I want to be able to react
on a change to something that's coming through the input.
Speaker 7 (26:03):
And I feel like, you know.
Speaker 5 (26:04):
If I'm doing it, if I'm changing my values through
a subscription, is easy, right, I just I set up
a subscription, and then I can I can tell my
code to do something when that value has changed.
Speaker 7 (26:17):
But I like, you can't.
Speaker 5 (26:19):
There's not really anything you can do on an input,
is it. I mean other than using on changes, which
I like. Personally, I'd like, don't write any code in
on changes. And I know I've seen, you know, even
in code basis I'm working in at the moment, I
see reams and reams of coding non changes. And maybe
for some people that's cool, but I find that that method,
that life cycle hook, just gets hammered too much. I mean,
(26:40):
am I just am I making a problem that doesn't
exist here in my own head? Or what?
Speaker 3 (26:45):
As far as the input is concerned if we stick
to our principle where we just go for the two
level hierarchy and we are just passing data down just
for the display purposes only. Like Edie was mentioning earlier
that they have a service consumption component and then there
is a display component. So basically there's a smart component
and a dumb component. A dumb component just displace the
data whatever you throw at it, so that point you
(27:06):
don't need control over it, you know, because you need
to just pass the data down and just display it.
Speaker 4 (27:11):
That's it.
Speaker 3 (27:12):
So the problem comes when you need control over that display.
Maybe you want to make a decision on whether to
display something or d else. Major things are done by
the template itself like NGF and all, but still if
you want some programmatic control, at that point what you
mentioned would be applicable where you would need some control
over the values that are changing or maybe make some
(27:33):
decision or maybe log something at least, you know, while
the values change. So at that point inputs would just fail.
But then again the usage of input is what I
would like to again go back to Eddy's example, like
that is the correct usage of input where you just
want to have a dumb component and or I'll call it,
I'll not be rude. I'll call it a presentational component.
Speaker 4 (27:54):
And we.
Speaker 3 (27:56):
Just passed the data out and the component just displace
the data and that's it. So that's that's where the
input comes into the picture.
Speaker 7 (28:03):
So yeah, good.
Speaker 5 (28:03):
So when when you add, when you want to be
able to react on a change, you should be doing
it with a with.
Speaker 7 (28:08):
A with a subject.
Speaker 4 (28:10):
Yes, yes, that's correct.
Speaker 7 (28:12):
Good.
Speaker 6 (28:13):
I have a kind of crazy idea to throw out here,
and I will say this is a hypothetical situation in
case it's a crazy situation, because I would not want
to admit to having written this. But what do you
guys think about having a setter and a getter on
your input? So your input triggers a setter function, which
(28:35):
then allows you to kind of react to the new
values that come in, and then of course you would
store that in a private variable and then have your
getter return that. So it looks like a normal input variable,
but it does magical stuff when the setter is triggered.
Speaker 7 (28:54):
Sounds like madness.
Speaker 3 (28:57):
And that's that's what basically Chris is suggesting, you know,
because at that point when you exactly exactly that is
the scenario way and you want to react to some
changes at that point, you would hypothetically, if it is possible,
you would do that. And I think it might be possible,
like we might want to refer to some hooks that
Angler might have for the component life cycle, and that
(29:18):
might be possible. There might be a possibility. I'm not
quite it's not on top of my head, but it
should be. There should be something like this, you know
what Eddie is describing in the form of life cycle
hooking and Angular.
Speaker 6 (29:30):
Yeah, that was just one thing that came to mind,
So I thought that out there. But definitely, I think
when you have a lot of complicated logic, like you
said Robbie, like you want to switch to services for sure.
Speaker 3 (29:38):
Yeah, so in that case, we use we do use services.
And then comes in nng r X that is the
god of computer component communication. Now this whole idea, like
I always feel frustrated at point at one point in
time where you know, the learners that I teach, they
come in in my Angular class and the first thing
that they ask is are we going to cover X
(30:00):
or not? So in that case, it's like it's like,
I mean, it's not necessary to get nngr X covered,
you know, as far as Angular is concerned, because in
order to cover NGRX, you should have a good experience
working with a very big application that would not work
without this this sort of a reactive state changing mechanism.
(30:22):
And unless that happens, you don't know that you'll not
be able to know the value of what NGRX adds
to your you know, whole application. So what I advise
them is to just go step by step, go with services,
try to implement like I don't even you know, mention
NGRX until at one point they come or until they
come to a point where they think that okay, this
sort of a mechanism like action types and you know
(30:45):
payload and you know dispatching sort of a thing is
necessary or effects are necessary. At that point when when
a learner reaches at that point, I just throw in, Okay,
what you were trying so hard from four to five
days is here NGRX.
Speaker 4 (30:58):
This is the link. You can implement it and you
can go ahead with it.
Speaker 3 (31:00):
So so for most of the cases Angular projects, I
don't think it need AnGRs, it needs ANGIERIC. But ng
RX is again a good way of component communication. But
eventually it's a service that works in the same manner
as any service would, but but then it is more organized.
You know, it's a global variable. We're always advised against
(31:22):
global variables. But then now because we have rebels, we
just come up with an organizational pattern to handle global variables,
and then the whole world uses it, you know, So.
Speaker 4 (31:33):
So that is that is basically what it is.
Speaker 3 (31:35):
So that's what Also, that's also what I love about
reducts and angie r ICs and VUX and you know
more BEX and all those application state management libraries. It's
it's the rebellious nature of those libraries that we are
always right from the college, we were advised against using
global variables, but here we are using global variables managing stuff.
Speaker 4 (31:55):
So that is that is good.
Speaker 5 (31:56):
I think you're right like this, You do see kind
of obsession with ENNGRX. Certainly when it first started to arrive,
it felt like everyone, it's all anyone was sort of
blogging about in the in the angler space and X. Actually,
you know, I've worked on several projects that use it now,
and I could easily say that I think probably only
(32:20):
one of them really needed to have ENJX, you know.
Speaker 1 (32:24):
Because what's good that line, Chris, like, if you're looking
across these projects that you're working with, is it literally
just size of the Cobey's Yeah, I mean.
Speaker 5 (32:34):
Yeah, yeah, I was just working the one that I
think I think would have did benefit from it. It's
just it's an application that was just handling obscene quantities
of data and that data was constantly being shifted around
the application, right, So in that case, it just it
(32:55):
made perfect sense. And in fact, you know, when I
when I came on board that project, they don't been
adding ng RX to it for I think maybe a
couple of months. It was previously just using subscriptions, and
it's just because the app had just grown to such
huge proportions, and say, it was just it was constantly
shuffling data around that was just being accessed by so
(33:18):
many different components sort of at once, who were all
accessing it and changing things and needing to react to
the to the changes. And so in that case, yeah,
it just it made sense to have this sort of
central data store. You know, it's exactly what it is therefore,
to have the central data store where everything could just
tap into that one central location forgetting data.
Speaker 7 (33:38):
And changing it.
Speaker 5 (33:39):
But you know, the project that I worked one directly
before that, one that had engine X in it, and
it was a tiny app that didn't do much and
it was just like just so much work doing all
the ng X stuff when I could easily just have
been piping the stuff around with you know, with my
services and subscriptions. So I think people get a bit
(34:00):
over excited about ng X. And I think there was
I've dug it out. It was in the back of
my mind and I've lost I'm in the wrong browser.
It was a talk by Mike Ryan at Anger to
Connect in twenty eighteen. You might not need ng RX,
And it's like just the fact that the fact that
they need to do a talk telling people maybe that
(34:24):
they don't need it says a lot about how obsessed
people got with it.
Speaker 1 (34:28):
I think, yeah, I think it's hard because people just
get so excited and they're like, it's like whenever you taught,
you taught them, you know, instead of inputs and outputs,
you can use the subject and they're like, well, I'm
going to use this everywhere, and it's the same. It's
the same. Everyone just gets excited and they used it
on all things.
Speaker 3 (34:47):
So yeah, and I would also like to add on
to what Chris just mentioned, there is a rule of
thumb as well in here when that whole flash of genius,
when you want to use angi X in your project,
you know where if that generic service that we were
talking about, Eddie, if if that gets out of hand,
you know, it has so many things that you need
(35:08):
to manage, and at that point you should, you know,
make a decision and move to ng r X. And
that is when there are a lot of components and
you know, your state, as Chris mentioned, is affecting a
lot of things. But right at the onset if you
start with ng r X, because we are always nowadays
like most of the projects are agile, we don't know
(35:28):
at what point a project would go or a project
would end at. So at that point, I mean, even
if you're just using a good service mechanism and good
organized service mechanism which doesn't have any learning curve, that
would also be beneficial for the new newbies or the
team members basically, and you would still be able to
(35:48):
live with ng r X or without en gi ICs.
Speaker 4 (35:50):
I'm sorry.
Speaker 3 (35:51):
So basically it's it's that you know, so there is
always a trade offer, There is always a decision that
you have to take with Angular in every aspect right
from the beginning, because it is really overwhelming. There are
so many things that are there in Angle because it's
a framework, you know, that's the that's the fact of
the matter, and you have to take a decision and
when you stop using or when you stop over using something,
(36:14):
so that is that is there always.
Speaker 6 (36:16):
We talk about how NGRX might not be needed if
a project is too small, and then the assumption is
that like as NGRX gets or as your project gets bigger,
NGRX you know, is more needed on the con or
on the inverse.
Speaker 4 (36:31):
Side of that.
Speaker 6 (36:31):
Like our product at the company I work with, we
actually store so much data that there's no way we
could load all the data into the web browser at once.
Like we actually overwhelm my SQL databases and have to
have this like in memory database called Hannah on some instances.
So like we're talking about hundreds of thousands of you know, entities,
(36:54):
and so because we can't store all of that in
the web browser, we actually have to do all of
our filtering and queerying on the server. Which we didn't
realize this when we started doing DRX and we went
full throat onto NDRX in one segment, but it didn't
occur to us until after that. Because we never have
all the data in the browser, pre filtering it on
(37:16):
the server actually made NGRX almost completely useless to us
and like a lot of overhead because every time we
wanted to change the filters, we had to recreate the
server anyway, and so it was essentially like a temporary
local cache, which was not helpful. So when you get
to the size that your project is so large you
(37:37):
can't load all the data in the browser. That's also
another kind of gotcha with NDRX.
Speaker 4 (37:41):
Yep, So there is a fine line.
Speaker 3 (37:43):
So definitely that's like your in memory database would do
the or would play the role of what NGRX would.
You know, if you're in memory database would not have
been there. So so that is there. And again this
angular or has provided us a lot to work with.
This whole idea of NGI RX comes with the idea
(38:06):
of reducs and React working together and people people just
come from that reactor redex background and they expect something
like reducts to be the savior, but then Angler already
has it in the form of services, where you know
it's a Singleton. You have your data in one place
and you can you know, basically check that data anywhere
(38:29):
that you want to, and at times you don't even
have to use subject an observable pattern. So services are there,
you know, in Angular and we're good that way. So
that is that is there.
Speaker 5 (38:39):
Of course you absolutely the nail and the head with that,
you know. I worked with a young developer a year
or so ago who had come from a strictly React
background but onto a onto an Angular project. Like literally
the first thing he did was just just added and
direx into the project and like request, like what we're doing, Well,
(39:01):
you need it, you know, you need the state management.
Speaker 7 (39:02):
It's like I get it.
Speaker 5 (39:04):
I totally get where it's coming from, you know, because
you you've come just as you said, you know, it's
come from a development environment where state management is a
is a widely used thing. But just you know, Angular
handles so much of that for you. This is this
is part of my my sort of bug bear with
with nj AX, and I now I now have grown
to the point where I don't dislike it because I've
(39:25):
used it enough in places where it's been useful that
it's it's made my life easier. But it's yeah, people's
obsession with just adding it because they think we need
it because it's a thing that exists. But actually, you know,
Angler's state management is is great a lot of the
time until it's not until you get an expression changed
after it was checked there, and it's not great.
Speaker 4 (39:48):
Yeah.
Speaker 3 (39:49):
So so again, I mean this is all nothing, nothing
against anger exist to clarify. Every one of us whould agree.
It's just that as a developer we should have the
capacity of making a this and when to use stuff
and when not to. You should not just be using
things because you can. With great power comes great responsibility.
So that's the responsibility that you have, you know. So
(40:11):
so that is is there's a very classic one, but
that is true.
Speaker 7 (40:15):
Absolutely.
Speaker 5 (40:15):
Bonus points for the Spider Man quote at least ten
bonus points.
Speaker 1 (40:23):
Is that where it originated, because I've heard it in
so many places?
Speaker 3 (40:26):
Yeah, yeah, the first Spider Man, I guess I heard it.
Speaker 7 (40:31):
I dare you even ask that question?
Speaker 2 (40:34):
My bad.
Speaker 1 (40:35):
Apparently Spider Man is more sacred than state management to Chris, So.
Speaker 7 (40:40):
You can't say it because the position of my webcom
I've got a.
Speaker 2 (40:44):
Right spider Man right right next to your minecraft.
Speaker 5 (40:50):
Pick right here, there's one I can't reach. I love
Spider Man anyway.
Speaker 4 (40:57):
Nice, So I made Spider Man now or.
Speaker 7 (41:03):
Ie going for hours?
Speaker 1 (41:04):
If we did that, they're actually coming up on the
top of the hour Rabbi, and I was wondering, is
there any like last closing statements that you'd like to
say before we move on to pics about just really
you know, component communication and what you suggest people do
and resources, et cetera.
Speaker 3 (41:26):
So what I suggest, like not not only component communication,
but more of a general thing whenever you want to Like,
this is for the learners, because I think along with
the developers, there would be people who might want to
learn Angler who might be listening to this particular podcast.
So if you want to learn something, just go to
the official documentation and that's it, all right, So you
(41:49):
don't have to most of the time, you don't have
to hop around seeing long videos just to implement certain things.
You know, official documentations are great as far as Angler
is concerned, it's awesome. That is that is where I
learn most of the things from, and then I go
to the videos if something like some people might have
some different thought process, and that is also important to
(42:10):
grasp no disrespect to anyone, So we might just we
might just want to have the documentation to be preferred first.
Then the rest of about component communication, services, subject and observable,
Like you should know what a subject is, you should
know what a behavior subject is and observable is, and
you know how to implement it. Maybe you know, if
(42:31):
you want to have reactive local storage, you might want
to go for a behavior subject. But if you don't
want to do that, that is also possible. So RXGS
is also not the answer to everything. So with for example,
you know, last example I would give is that if
for example, I have my user and my token in
my local storage, and I have a user service getting
(42:53):
that local storage for me, it is not necessary for
me to use any RXTS concept. Still it would be
reactive because that's how services in Angular work. So so
so basically, the bottom line is Angular has provided us
a lot of things to work with, and it is
it is just not fair to go for other options
(43:13):
unless you already have tried your hand on the existing
ones and you know, if that doesn't work for you,
then go for external resources. Because we don't want to
make our app heavier than it is already you know, so,
so that is that is basically what it is.
Speaker 2 (43:28):
Wonderful, wonderful.
Speaker 1 (43:30):
Well, I honestly I really loved listening to you explain things,
and the examples you had were just incredible. I think
it really lent a great hand to audio only podcasts.
I think, so thank you for the coming on and
teaching us and walking through things. Before we jump over
to pics, I just wanted to say that I can
see why people like seek you out for training because
(43:53):
I could clearly listen to you talk all day.
Speaker 3 (43:55):
So the thing is just a fun fact. The other day,
like every time I review my video, I just sleep
halfway down, you know, I just fell asleep. I just
fall asleep when I just review my own videos that
I record.
Speaker 4 (44:10):
You know.
Speaker 3 (44:11):
So, I don't know about others, but I don't really
enjoy listening to myself that much.
Speaker 5 (44:18):
Great great advertisement there for your I put myself to sleep, guys.
Speaker 1 (44:27):
I make it a rule of thumb never to listen
to myself. So, so, does anybody have picks Eddie or
Chris before we let Rabi.
Speaker 2 (44:38):
Do some pics.
Speaker 7 (44:39):
Yeah, I got one pick.
Speaker 5 (44:40):
The whole of like social media, certainly in my social
media feed is just full of people obsessing over animal
crossing at the moment looking at Eddie, now he's one
of them. Naturally, I've done the only sensible thing. And
I recently acquired a copy of Pokemon Sword for my
(45:01):
switch and I've been really enjoying it. It's really good.
I'm trying to resist the animal crossing bandwagon. But I
feel like that raccoons coming after me.
Speaker 6 (45:10):
He's hunting you down.
Speaker 1 (45:12):
Literally, there's a raccoon chasing you.
Speaker 5 (45:14):
Because you know, I don't think we have raccoons over here,
so I think I'm probably all right. We got our
own stuff. But yes, my pig Pokemon, I enjoy it nice.
Speaker 6 (45:25):
Yeah, I've got two picks. One I don't think I've
said this before. If I have, we'll repeat pick. But
one pick is century like a guard s E n
t r o I. It's a service that allows you
to report basically like jobscript errors and stuff to a
third party server so that you can then see, like
(45:48):
you know, of your software installation, like what errors are
coming back and so for a long time, like we've
had no way like we find bugs with our QA team,
like through our usage, but we have you know, if
a customer doesn't say, hey, I have this bug, like
we have no way to know. And so we've started
implementing that and it's really interesting just to be able
(46:11):
to suddenly have an error pop up on a dashboard
and be like, oh wow, like okay, someone ran into
the air, like and it shows you where in the
code as if you're looking at the JavaScript console and
it shows like what they clicked on just before and stuff.
So we haven't gotten to use a whole whole lot,
but definitely started to dive into it and it's really exciting.
So I am super excited about that. And my second
(46:32):
pick is so I was one of those Evernote people
that like started putting everything in EVERYNOE when it came
out with the web clipper and everything, and it was
like my brain for everything. And then they went through
all their changes and nothing against every note, but I
got less excited about EVERYNOE. The problem is I had
no replacement, and so I've just gone without an external brain,
(46:56):
which is not super helpful. And so this I found Notion,
which I'm probably late to the notion train. Probably everyone
else knows about notion, but Notion essentially like allows you
to kind of replace like Google Docs, and it has
some like kind of basic like task tracking stuff in
(47:16):
it and like stuff. But for me, it seems like
a really big replacement for ever Note, where I can
just kind of put all my thoughts in there. I
can take notes in there. It has a web clipper,
and so if I'm on a website, I can be like, hey,
grab this HTML, throw it into a page and Notion.
So I'm just getting started with it this week, but
I am really excited to have a replacement for ever
(47:39):
Note after my long dark the like.
Speaker 1 (47:43):
To use the client on like the app, or to
use like inside the browser, Like how do you use it?
Speaker 6 (47:50):
Yeah, so I have an app on my Mac and
then and I haven't started. I know there's an app
FM on iPhone, but I haven't done that yet. But yeah,
in the webread like I use a web clipper plug
in for the browser. But then the actual engaging with
the material I use in the Mac app.
Speaker 2 (48:08):
Okay cool.
Speaker 1 (48:09):
I've been addicted to Dropbox paper for a while now,
but sometimes the like offline experience can be painful. So
so yeah, I will definitely check out Notion.
Speaker 2 (48:23):
It's a great pick.
Speaker 6 (48:24):
Yeah, for sure, It's pretty cool, So that's mine awesome.
Speaker 1 (48:28):
I've been playing around with the Oculus quest lately. My
work sent me and the other advocates on my team
one they said, hey, we want you to start programming
in Unity and making online events for people, and I
was like, that's crazy cool. So I've actually never put
on a headset before this, so if you haven't, then
you get an opportunity to. I definitely suggested because I
(48:49):
was one of those naysayers. I was like, it's not
going to be that cool, and it literally blew my mind.
So definitely, if you get a chance to put on
a VR headset, I would recommend trying it out.
Speaker 2 (49:03):
So yeah, that's my pick. But also Ravi is my pick.
Speaker 1 (49:07):
I'm actually so I'm so excited to have met you
and follow you on all the social medias, So can
you please tell us where people can find you and
reach out to you and learn from you.
Speaker 3 (49:18):
So I have my YouTube channel goes by my name itself,
Rubb Valiat, and I have some Angular tutorials going on
right now in that particular channel itself, so you would
have you'd be able to, you know, see the tutorials here.
And then my last name Valiate dot com is my
(49:39):
website or my contact info is provided in there. Anyone
who wants to basically share any thoughts or maybe ask
any questions, they can directly. I get emails from people
asking some doubts or questions or you know, some problems
that they have with their projects and all, and I
try my best to, you know, answer them basically to
the best of my abilities.
Speaker 4 (50:00):
So so that's where. And then you can follow my Twitter.
Speaker 3 (50:03):
Same name, you know, So so there are base if
you just google my name, I think my website might
come up, so that is also there.
Speaker 4 (50:13):
These are the ones that you can follow.
Speaker 1 (50:15):
Yeah, and I want to spell it, so it's our
A V I it's his first name, and then V
E l I y A T for his last name.
Speaker 2 (50:22):
So definitely worth to follow. A very cool cat. So
thank you well.
Speaker 1 (50:28):
Awesome, Thank you gentlemen for the marvelous episode today. Uh
everyone has fun and safe programming for this afternoon and
we'll see you guys for the next one.
Speaker 2 (50:39):
So thank you so much.
Speaker 4 (50:40):
Thank you, Thank you everyone, Thank you for having me here.
Yea great chase everyone, Bye, thank you Bye.
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.