If you are testing an Angular application, then at some point, you will be required to test asynchronous behavior.  Today on the show, guests Stephen Cooper and Mona Peirov share about how you can validate your internal models with async Angular testing and integrate AG Charts into your workflows.

Hey, everybody, and welcome back to another episode of Adventures in Angular. This week, we have two special guests. I guess I should introduce myself. I'm Charles Max Wood from PopNDevs. We have two special guests. We have Stephen Cooper and we have Mana. I didn't catch your last name, Mana, and you're not on my...

 

payoff Mana payoff. Yeah

 

Awesome. And yeah, do you both want to introduce yourselves real quick and let us know who you are and why you're famous? And then we'll. Talk about tech.

 

Yeah, sure. Hello everybody. My name is Manah. I work at AG Grid with Stephen. I'm working on the charting library, which is great. I've been here about a year, so I'm enjoying that. I'll let Stephen introduce himself now. Hi, I'm Stephen Cooper. I've been at AG Grid also a year. I think we started on the same day, didn't we? Yeah, we did. And I've been in and around the Angular, I guess, community, doing some talks and blog posts and sharing what I've learned, I guess, in doing my job and hoping that those kind of things help other people do theirs.

 

Awesome. Well, we invited you on because we ran across your article, Stephen, about asynchronous testing. And

 

Yes.

 

then if we have time, I'd love to dive into some of the charting stuff too, because that's always a fun journey to go on, right? But let's start with the asynchronous testing. Stephen, do you want to kind of give us the 10,000 foot view, like, what

 

Yeah.

 

you're actually testing and how that works?

 

Iawn, 

 

Oh, I thought you would just put like a wait five seconds and then make sure it's right. Right? Ha ha

 

Nid.

 

ha ha ha.

 

Mae'r test y bydd yn dda iawn, yn ogystal â'r hyn, yn ogystal â'r hyn, yn ogystal â'r hyn,

 

Yep.

 

ac hefyd, y byddwch chi'n gwybod, a oes yn 5 ddegwyddiad, a oes yn fwy oedd yna, a oes yn fwy oedd yna? Felly mae yna mwyaf o brydau, yn oed yn ei fwyaf o brydiau.

 

Yeah, I gathered as much. So what is the approach? What do you do then?

 

Ie, felly mae yna ddeallu ymddygiad ymddygiad ffeydd y gallwch ddefnyddio mewn cwt test angloed. Mae'r ffordd y mae'n cydnabod, fel y byddai'n cyrraedd, yw gynnigio ymddygiad ffyrdd i'w gyrraedd. Y peth bach i'w gysylltu yw bod yn Javascript yma ymddiriedig. Yn ymddiriedig, mae'r cwyddiad sy'n cymryd yn gyrraedd, ond os ydych chi'n cael rhywbeth sy'n cymryd,

 

Uh huh.

 

byddai'n cael eu gyrraedd yn ymddiriedig, ac byddai'n gyrraedd yn y cyfnod ymddiriedig. So things aren't running in a straight line anymore things get added to the back of this queue and then once the queue Once the execution I guess TARC has been executed it takes the next one off the queue and executes that But in your test you want to be able to control when that queue is emptied or, or, you know, not have to wait for an asynchronous behavior in

 

Right.

 

real time, but in fake time. So fake async, if you wrap your test body so that you know that's your it section when you're writing your test, you've got your describe and you've got your it in Jasmine. And so you wrap. your it body in a fake async and then that means that code there won't use the standard. you know, browse that asynchronous behaviour, it will run in this fake zone where asynchronous tasks get put into this fake queue. And then you have methods like flush or tick, which then control when events are or tasks are taken off this queue. So for example, if you say flush, it will then execute all the events that are on that queue in order. And if those events put more in the queue, it will try and execute those. queue is completely empty and drained. Whereas tick gives you more control about the timing of these things. So say your code had a set timeout in it of like 500 milliseconds. You could use this tick function and pass it the value 500 and it would move asynchronous time forward 500 milliseconds and then triggering that event. So with these tools you can control when certain ymlaen ymlaen ystafell yma.

 

Right. Makes sense.

 

Felly, mae'r model mental, rwy'n credu, yw, unwaith y byddwch yn cymryd, yw, gallwch chi ddod yn ymwneud, a'r hyn yw sut y byddai'r testau yn gweithio. Ond mae yna rhai cymdeithasau addedol yn y clywed â'r cyngor cyngor cyngor gweithio, sy'n gwneud ei fod yn dda i'n dda i'w gweithio'r pethau hynny. I guess this, the article that I wrote is coming from it. It's like breaking down step by step at what point different parts of the change detection cycle run and how you integrate those with flush to empty the async queue. So yeah, so there's some gotchas as well, which took me a while to work out. If you're setting up your component inside a before each statement, which is outside of your fake async test.

 

Mm-hmm.

 

then that means any kind of events and asynchronous behavior with that component can get set up outside of your fake async zone. And so then you're left wondering, why

 

Mmm.

 

can't I control when these events are being fired? And that's because your component has been constructed outside of the fake zone. So that was the first thing that I noticed just moving that initial fixture.detect changes out of the before each statement into the test itself. 

 

Gotcha.

 

Yeah, and then you've got fixers detect changes. When that's called, it applies values to your component inputs. And then you're... If your component is then responding to those inputs with asynchronous behavior, you then let that happen and you flush it. But then you'll notice that your template isn't actually updated with those values. So then that's where you need to do another fixture dot detect changes to get Angular to run the change detection. And then you'll see the changes in your template. So in this article, I stepped through these different steps and have like three ways of validating the code. internal model which gets updated synchronously so you can in

 

Now,

 

your

 

when

 

test

 

you say

 

you can

 

internal

 

assert.

 

model, that's essentially

 

So that's

 

your data structure and memory, right?

 

and you do fixture.detectChanges and that binds the input value to the component. And immediately after that you can assert that the number of rows has changed. But at that same point in time, say there's an asynchronous callback into your component, which updates the number of rows that are visible, that hasn't changed yet. And if you're displaying the number of filtered rows on your component in the template, that still hasn't updated yet. So you've got this. difference in when these changes happen. So then you'd flush the changes, and then at that point, your internal model, and also then the component, which has been updated asynchronously, those two values match, but still the value that is displayed in your template is on the old one. And then it's not until you do fix your dot to take changes again, that the template finally gets updated. So it's

 

Now

 

these...

 

it sounds super complicated.

 

So yes, I've added an example of how you would test this and given it step by step instructions in this blog post. But then once you understand that, there are shortcuts you can start taking. So there's a fixture.auto-detect-changes, which means that as soon as... You know, you set the input value that automatically gets updated. So you're not having to call fix.detectChanges. At specific points. At specific points throughout your test. So that shortens the test. But I think it's good to understand at what point Angular is doing things to, you know, passing values into templates when a component might actually run and update a 

 

Right. So I mean, one of the things that I'm just thinking through is, yeah, it helps you to kind of understand the lifecycle of your Angular app. And the way that people interact with it and then the way that, yeah, things are managed through the framework. But I'm a little curious, does this work on things that are not Angular? So let's say I pull in something else or I, I'm gonna hurt people's feelings, but let's say I'm using jQuery or something, right? And, you know, I'm not gonna be telling the framework to detect changes there necessarily because I may be working with other inputs or other details there. But does this same asynchronous I don't know what to call it, but yeah,

 

Yeah,

 

the queuing

 

so I guess

 

system

 

the fake

 

that it takes

 

async.

 

over. Does that work for other things or is it just Angular?

 

Mae'n rhaid i'n gweithio ar ddau oherwydd mae'n gweithio o'r zôn JS. Felly mae'r logiau ffeydd fesul yn ymwneud â'r pethau o lefel nesaf,

 

Okay.

 

fel set tîm, a'r holl ffordd.

 

bright and hijacks

 

Felly roeddwn i'n mynd i'w gwybod yn gweithio.

 

those.

 

But then I guess the thing is like our AG Grid code, it's got an Angular wrapper, but internally it's all, I guess, vanilla, well, TypeScript and JavaScript. So in one sense, testing AG Grid, the code that actually does the asynchronous part is not written in Angular, it's just TypeScript. So in one sense, that does work.

 

Yeah, that makes sense. So then the other question I have is, am I just basically testing my evented code and my components then? So anything that gets triggered, because some of this is gonna be, excuse me, some of this is gonna be life or life cycle stuff that happens as I detect an event and handle an event. But some of this stuff I could see is just, no, I guess most of the reactivity you're actually pretty explicit about. So you're effectively then just saying, okay, yeah, run all the changes, run all of the event hooks and everything else and make sure that everything comes out the way that it's supposed to.

 

Yes, I think that's the thing. In your application, you want to test your own code. So I guess this is where if you're... If your application is then doing things based on it while saying, I've got this many filtered rows, you want

 

Mm-hmm.

 

to test that, you know, that integration works. The fact that the grid is, is filtering, you know, that's not quite so much your responsibility.

 

Right,

 

You know, you

 

AG

 

should

 

Grid

 

be able

 

should

 

to

 

be

 

trust

 

testing

 

that

 

that, yeah.

 

HECRID. Yeah. Um, but if you're, if you've hooked into these output events to then update your component, then you want to make sure that you have correctly implemented those, those hooks. 

 

Mm-hmm. Yeah, that makes sense.

 

Ond roedd yna unrhyw prosiect arall.

 

Yeah.

 

Felly, yna bynnag, feicacin yn gallu gael eu hysbysebu

 

Okay.

 

So I think if you look at the flush function and the way that works is that if you end up having a some code which, for example, has a set timeout in it, which then triggers another set timeout,

 

Mm-hmm.

 

you can't test that code with vacay sync because every time it takes that event or that task off the event queue and executes it, it adds another task back to the queue.

 

Right.

 

And flush is trying to clear that. And

 

Oh,

 

so

 

so you're going to get

 

you'll

 

an infinite loop.

 

get an infinite loop. And so Angular does detect this, and it will give you an error saying, I tried to run 20 times, I think, as the default. But then it's, you're not completely stuck at that point. There are other options. And one of these things is using the inbuilt async await syntax, because

 

Okay.

 

that doesn't suffer. That doesn't suffer from the same problem, because... you can write your test in a way where you'll set up your component with fixture.detectChanges and at this point your code is running in the standard browser environment. But there's you can do a wait fixture.whenStable. So Angular has provided us these, I guess I think it's like a promise. where you can await it and Angular will then resolve that promise when it knows that the component is in a stable state and then you can carry on with your test. So using that approach, you're not having to worry about flushing the queue yourself. You just have to know when is the right time to wait for the component to be stable and then make your assertion and then call fixture.detectChanges either then apply inputs or update the template. So you know that approach can actually result in a simpler test because you're not having to explicitly think about where the asynchronous behavior is. You just wait for the component to be stable and then make your assertions.

 

That makes sense. I'm curious, Mana, do you wind up playing some of these same games with your charts, or is that a completely different deal?

 

We have tests and charts but I don't think it's this complicated I guess.

 

Okay.

 

Yeah, we don't really have too much asynchronous code in the charting library, it's quite small. Yeah, it's very early stages.

 

Okay, I was just curious

 

I do...

 

if you do async stuff and have to test it.

 

Rwy'n ennill cael ei wneud yn Anglia pan oeddwn i'n gweithio yn Anglia. Ac roeddwn i'n ennill amdano'r pwyntiau y byddwch chi'n ei adnabod hefyd, y gwaith asynch ffyrdd a'r asynch arall. Ac yn y perthynas, roeddwn i'n ennill, gwneud ymlaen a'r eraill, gweld, a allwn i'n ei wneud beth i'n ei gael?

 

All right.

 

Mae yna ddwy ffuncwysau y gallwch ei ddefnyddio. Fflasflas tiktik. Ie, ffictio.dys-tec changos ar ôl unrhyw ffaith.

 

Yeah.

 

Ond mae'n dda i'n meddwl, mae'n rhaid i'n gweithio fel y bydd yn gweithio, oherwydd y cysylltiad ymlaen.

 

Yep. Very cool. So, you know, before we move on to another topic, I just wanted to make sure that we've covered this. So are there any other tricks of the trade that you have that you've put into practice? And Stephen?

 

So I think the main thing to take away is that there is it's not all completely magical and random and you know just throwing in another flush will fix things and I think the main thing to try and understand is the mental model of when things happen so when you call fixer.detectchanges is that applying values to component inputs

 

Mm-hmm.

 

or has the component code model been updated, but my test isn't working because the template and the rendered output hasn't been updated yet. So I think it's when you understand this pattern of what's being updated when you call fixture.detectChanges, it really then helps you, I guess, visualize the test execution, and then gives you, I guess, more, something more to reason aboutwas able to read before I jumped into asynchronous testing. Because it's not simple, but I think the main part is understanding that what's going on in the component life cycle and in the change detection hooks. I think once you've got that understanding, a lot of these tests become fairly straightforward to write. It's just switching the mental model from synchronous testing.

 

That makes sense. I'm also curious, because I talk to people and a lot of times if the testing is hard or tricky, or if it takes a long time as the other one, they basically just deem it as not worth it, right? But to me, the value of the test is the sanity check, right? I don't have to go back and double check if something works because I can just run my tests and it'll tell me. And then, occasionally it'll actually catch that. Right, hey, you broke this.

 

Yeah.

 

Do you find that this actually saves you a bunch of time and effort in those kinds of instances where it either catches something that you've done or saves you the effort of thinking about, okay, now did I mess anything up with this thing that I just added?

 

Yeah, and I think the main benefit that comes from it is the shorter feedback cycle.

 

Mm-hmm.

 

Because you can run these tests really quite quickly and you can immediately see, oh, this change over here, which I didn't think would impact this component, has actually broken something. And while you're in that... I guess, code location and in that mindset, you can go and make that change and fix it straight away. Whereas, say it goes down the line, you know, you didn't notice this because you just thought it was unrelated and then it gets to, you know, the quality assurance or a tester is looking at this and saying, well, this is broken. By that point, you know, that might be a different day, a different week, and you have to then get back into the mindset and take all that code back into your mind. immediate velocity of getting the feature out, it should mean that the feedback cycle of well this is broken, you know, and coming back should be quicker. So your overall throughput should go up even if you're slightly slower when you're making the feature. Yeah. Saves time in the long run, doesn't it? Yeah. Yeah.

 

Yeah, not that

 

Even

 

I've

 

if

 

ever

 

it

 

written

 

does take

 

a bug,

 

time to

 

but...

 

set up these tests.

 

You know, I've experienced some of the same things that you're talking about. So yeah, that, that makes sense to me. It makes total sense.

 

Ond mae'n oed yn dda iawn i ddweud, mae'n edrych fel y byddai'n gweithio.

 

Peace.

 

Dydw i'n mynd i fy nesaf.

 

Yeah,

 

Yn llawer o bryd mae'n edrych fel y byddai'n gweithio, ond ydych chi'n ymwneud y test a bydd beth yn dda.

 

well. Yeah,

 

Rydw i wedi newid un peth a byddai'n gweithio arall.

 

because.

 

Mae'n ddifor.

 

Well, in the happy path for whatever it was that you were working on, yeah, that worked fine, right? And that's what you ran through. You didn't try the other stuff that depends on some of the same things that are the things changed. What's funny to me is that I actually worked with some folks that would change code and commit it. And then, you know, I'd merge and I'd, you know, run the app and it'd be broken. And so I'd go

 

What?

 

in and I'd say, hey, you broke this. It's a problem. And it turned out that they just wrote the code and committed it. They didn't even try it. And so

 

That's very confident.

 

yeah, right? So yeah, so I mean, it makes sense. You get that feedback loop. And yeah, a faster feedback loop means that most people will be willing to at least see what it says, right?

 

Okay.

 

And that makes sense.

 

Yeah, and I

 

So.

 

think that there's tools out there as well to help us write Angular tests.

 

Mm-hmm.

 

I know, like, Shai has got some great packages, like his ObserverSpy is a great package, which I've used. And Spectator as well is another tool. So there's lots of tools out there, as well as, you know, Cypress, if you're doing your end-to-end testing, which help you. I guess write your tests and simplify things for you. So. I think sometimes we might think that testing is really quite complicated and difficult but I think some very smart people have already made tools to help you write your tests so you're focusing on the actual test logic as opposed to the interest of how Angular testing works. So I would encourage people to use those tools as well.

 

I agree.

 

Because you might not need to test at the component level. You know, if the... You might want to actually just test that, you know, what is your user going to interact with? So, if you are limited in times of time and maybe you're... I guess how much you can put into testing. If you get the test at the right level, then it's also going to be much more robust. So for example, if you are just testing for your charts and you can test the final snapshot and make that, make sure those are, I guess, pixel perfect. You can be much more confident in doing lower level refaxes and not then having to update lots and lots of little small tests. But you've got confidence that the end project that the user is actually going to interact with that is still working. So I think that's an important thing to do. Make sure you are testing at the right level.

 

Yeah,

 

Yeah.

 

my experience with that, especially with some of the visual checks is you usually have, like you said, a snapshot and it'll take the snapshot and you validate that snapshot. And then what you're validating from there in the automation is, it's the same, right? It looks the same. So if I put the same data in, it looks the same as it did before. And so, yeah, then I can compare the images and make sure that they're close enough, right? perfect renderings, they're off by just a little bit, but anymore it can detect, hey, this is basically the same as the other one, and then it can work from there.

 

You can adjust the threshold, can't you? And it's to do with detecting the regressions, I guess. If you're making a change and it seems like that's working in that area, but then you want to make sure that what was there before is rendering exactly the same.

 

Yeah,

 

So that's

 

I

 

when

 

mean,

 

they

 

I've

 

become

 

never

 

really.

 

written a regression, but, but you know, if, if that's what you've done.

 

Me neither, I don't know, I'm just... The average. That's what I heard. Ha ha ha.

 

That's yeah, yeah, it's just, it's just, just a rumor out there. Good deal. So I've always wondered, you know, what, what it takes to write a visualization graphic or, you know, graphing library. I mean, I tend to just pick one up off this, you know, off the shelf here or there, you know, and it's, it's almost always the one that somebody else put in. It's like, okay, I'll figure out how to use this.

 

haha

 

What's it like building one? I'm, I'm, I'm really curious.

 

It's so different to what I thought it was going to be like. Because before joining Age of Grid, obviously I'd never

 

Uh.

 

built charts from scratch. There's always a library out there that you can use.

 

Right?

 

I do find that almost every day working on it, it's like I'm doing some sort of tech interview because it will be some complicated algorithm. get my A level math book out because there's going to be some next level matrices or something ridiculous. That means resolving. So it's never a boring day, put it that way. Yeah.

 

Okay, I want to get this just out there. I'm going to play this back for my 16 year old about 80 times. So you actually use math in your programming. Is that what you're saying?

 

I actually use math. I never thought I'd say that. Yeah, real math, like multiplication and stuff and addition. No,

 

Okay.

 

there's...

 

I'm just making sure, cause he tells me he's never gonna use it again in his life. And I just, you

 

Roeddwn i wedi gael amdano am ddifrydau llwybr arall, fel cartesian, pola a phwynt o ddwylo.

 

know.

 

Fe ddodais i'r ddwylo oedd y pethau sy'n bwysig ac mae pobl yn defnyddio. Felly roeddwn i'n mynd i ddysgu am radians a phwynt o ddwylo a dydw i ddim yn gwybod arall.

 

Right?

 

Trigonometri, etc.

 

Hehehehe

 

So yeah, it's a good job. I did some math in school.

 

Makes sense. So then

 

You know.

 

as far as, so I mean, I can understand like pulling the numbers in, maybe doing some math on the numbers,

 

Yeah.

 

but how do you translate that into something that I can visually see? Like what's involved in that process?

 

So we're using the HTML Canvas element and

 

Mm-hmm.

 

the Canvas API. And for our particular charting library, the way it's being designed currently is that we have an options interface, so all the configurable parts of a chart, all those options can be provided, and they go through our factory. In our factory, we basically merge those options with some defaults and then we map those options, inject them into the chart implementation or model that we have, and then that is the output of that is what gets rendered onto a scene graph that we have, which It's just a way for us to describe and lay out what the chart is actually going to look like. It has different components. So like, let's say a chart has axes, it has a legend, a title, the actual series and those nodes. So they all kind of get organized and structured in the scene graph. And at the root of the scene graph is where we have our 

 

So you said that you're still building the charting library. How

 

Yeah.

 

many people are working on it? And when do you think it'll be out?

 

Felly, yna y ddwy o ni yn gweithio arno, ond mae'n gweithio, mae'n gweithio, mae'n gweithio i ddefnyddio i ddwylo. Mae'n ymwneud ym Mhob, a gallai unrhyw un gallai ei ddylau a'i ddefnyddio. Beth yw'n ei ddweud? Mae'n dweud ag charts.

 

Oh, wow.

 

Did I not say what it's called? Oh my gosh, yeah. It's called AG charts. So we have AG grid and we have AG charts. AG charts, yes. It's amazing. We don't have all the different chart types, obviously, yet because we're still adding things

 

Ha ha ha.

 

Rwy'n credu bod hynny'n anhygoel. Rwyf yn edrych ar hyn o bryd, a dwi'n cael ychydig mwyaf oherwydd dwi'n credu, wow, dyma'n dda, dwi ddim yn credu, dwi ddim yn credu ein bod ni'n gwneud hynny. Oherwydd, rydym yn gwneud hynny.

 

I know,

 

Felly...

 

right? You're so talented.

 

Performance is a major thing for visualizations because people are looking and they're a bit impatient. They want to see things quickly and they want things to update quickly, especially with things like animations or videos and things that you can basically see on the screen. So they need it to be fast. profiling, we found in our current profiling runs that there is a limitation with the Canvas rendering performance. So just analyzing that further, we actually found that maybe around 75% of our execution time gets spent in the actual Canvas render calls, compared to the 25%

 

interesting.

 

that we spend doing the processing

 

Wow, stuff you don't think about.

 

Yeah, slightly.

 

Yep. Yeah. I'm just getting into some of the charting and stuff with the podcasts. So I've moved everything over to a custom system, but that means that I have to build all the things, including a graph of, you know, our traffic. So

 

Mm-hmm.

 

that's been interesting to kind of pull together and make work. And yeah, I'm not using

 

Yeah.

 

AG chart. I'm using something else, but it's, it's been interesting to just kind of see, okay, you know, what can I do with this and where are the limitations and yeah.

 

 

Mae'r gweithdoriaeth wedi bod yn ddim. Mae'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i'n dda i' a'i gweithio ar y tref a'i gysylltu â'i gweithiau ei hunain neu'r grwp. Gallwn ddod yn ôl i'r gweithiau ymchwil, felly mae hynny'n dda iawn i'w ddod yn dda i'r amser rydyn ni'n gweithio. Ac un peth rydyn ni'n ei wneud yw addio'r canfus off-screen. Felly, ar y gweithiau, byddwn yn creu canfus off-screen. i wneud y sôn ymgyrch, er bod y llai hwnnw nid wedi'i gweithio yn y rhann dda, rydym ni'n gweithio'r ymgyrch ymlaen,

 

Oh, that

 

a bydd yn dda iawn i'w gweithio.

 

makes sense.

 

Felly, mae'n bwysig i wneud y mgyrch, ond mae'n, yn ogystal â'r gweithio'n dda, yn dda iawn. A'r un peth ddiddorol i mi roedd y cyfle hwn yn dda. Mae'n dda i gyd yn dda, ond mae'n dda i gyd yn dda. Mae'n dda i gyd yn dda, ond mae'n dda i gyd yn dda, ond mae'n dda i gyd yn dda, ond mae'n dda i gyd yn dda, ond mae'n dda i gyd yn dda, ond mae'n dda i gyd yn dda, ond mae'n dda i gyd yn dda, ond mae'n dda i gyd yn dda, ond mae'n dda i gyd yn dda, ond mae'n dda i gyd yn dda, ond mae'n dda i gyd yn dda, Mae'n credu'r alludio bod yw'r datblydd yma y byddwch wedi'i hwyso, a'i gweithio, ond e'n dda, mae'n dda arall y llai sy'n cael ei ddod yn y lle cyfnodol. Mae'n dda pethau fel hynny, pethau fel hynny, sydd wedi'i gweithio'n iawn i'r gweithio. Mae'n dda yn dda yn dda yn dda yn dda yn dda yn dda yn dda yn dda yn dda yn dda yn dda yn dda yn dda yn dda yn dda yn dda yn dda yn dda yn dda yn dda yn dda yn dda yn dda yn dda yn dda yn dda yn dda yn dda yn dda yn dda yn d

 

Mm-hmm. Yep.

 

Ac mae'n oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn oed yn

 

Mm-hmm.

 

The grid is written in TypeScript, but we have Angular, React, Vue, and Support. It's the same for our AGCharts. So there's the core charting library, but then we also provide you with an Angular component. I think it's AGChart Angular. I think it's a component thing. Yeah, it sounds like that. So you can interact with it just like it's an Angular component, and you've got an Angular charting library. Yeah, exactly. And Angular can do its thing. We can do our thing. We'll render the chart for you in your Angular app. Most people will be using it in a framework I guess. It won't be

 

Well,

 

like in

 

maybe.

 

a vanilla.

 

That's really cool. So anything else that you all want to bring up and let people know about before we do our picks and wrap up?

 

Anything from you, Steven? 

 

Yep. Cool. All right, well, let's go ahead and do pics. Steven, do you want to start us off with pics?

 

Yeah, so I think my pick for today was I was actually, I managed to have lunch in the Google offices here in London.

 

Oh nice.

 

Yeah, yeah. So I've seen how. how the other side work.

 

hahahaha

 

We got very fancy offices. I've met with a friend who I went to university with and he invited me in as his guest and took me for their lunch. I didn't... He joked that. That sounds really nice. He joked that Google, when somebody joins Google, there's a 10 pound thing where they put on 10 pounds.

 

Ha ha ha

 

Oh, okay. It's all the free food. Free food, free coffee. That's the problem with refood. So yeah, so he showed me around and it was like, yeah, this is very nice. But yeah, then I guess... Yeah, I remember Alan saying they had a fridge and every drink you can think of, you could just take whatever you want at any point. I thought, wow. Yeah, so it was nice to see how Google, well, offices are at least. So yeah,

 

Interesting.

 

that's one pick. That's

 

cool.

 

so awesome.

 

I'm gonna throw out some picks and then we'll let Manna go. So I usually pick a game as one of my picks, a board game or a card game. The game I'm gonna pick today is called Antidote, and effectively what you do is you pull, they have like eight cards with an X on them and they're basically poisons. And so you pull one off to the side, and that's the one you're trying to find the antidote for. And then you deal out the rest of the poisons along with syringes. So everybody has two cards, and those cards could be syringes or poisons. And then you deal out the rest of the cards, which are all the antidotes for all the different poisons. And then effectively what you do is each person takes a turn and you can say, pass the card to the left. pass card to the right or you could say everybody discard a card and eventually enough people will have you discard cards to where you're down to one card and then if your card is the correct antidote then you survive and if it's the highest number because there are five cards of each color or each antidote if you have the highest number then you win of the antidotes out there so It's a fun game, takes

 

That's

 

about

 

cool.

 

a half hour to play. I usually throw out the board game geek weight. This one's 1.62. So it's not terribly complicated. I mean, I explained the whole game to you in two minutes. So it's fun. It's a lot of fun. It's, you can play between two and seven people. It's more fun with more people in it. Because, you know, you're, you're keeping track of more things and trying to figure out more stuff. There's more variability in the game. So anyway, I'm gonna pick Anodote. And then I'm also just gonna let folks know that we basically have all the infrastructure together for our online conferences. And we're gonna be opening up the CFP for those. The first one's the Rails one. I don't know how many people listen to this are gonna be super interested in that. That's in September. The JavaScript one is in October. And then the Angular one is in November. So if you want to speak at an Angular online conference, you don't have to travel, you sleep in your own bed. That's always a big deal for me. It's like, oh, I'm going to get a good night's sleep tonight at the conference.

 

Hmm.

 

We're going to have some networking sessions every day. We're going to have workshops the last day of the conference. Then you can go check it out. Just go to topendevs.com slash conferences, and you can see when those are. And you can go and you can buy your ticket. And yeah, we usually have our regular hosts and then I email all of our guests, past guests, and see if they wanna come. And then, you know, we invite people from the core team and things like that. So it should be really, really good. I don't have a big announcement for a big name speaker like I do for some of the other conferences yet, but stay tuned. I'll let y'all know if I get somebody that y'all wanna hear from. But yeah, it's gonna be super fun. So definitely do that. I'm also looking at pulling together some meetups. I've talked to a lot of people who are sort of stuck in a place where it's like, well, we used to do meetups here, but we don't anymore because COVID and then nobody kind of picked up the torch. So I'm gonna do online meetups. I'm probably gonna do two per month per, you know, framework or topic that we cover at Top End Devs. And that way the folks in Europe, you don't have to be up in the middle of the night. folks in the US or the Pacific, you can pick the other one, not be up in the middle of the night is kind of the deal. And so keep an eye out for that. That's kind of the next piece that I'm pulling together. I thought I was gonna try and get them to start in August, but I'm having a little bit of trouble getting all the scheduling to line up. So it'll probably be in September. People seem to have less going on in September. So we'll probably have a couple in August, but most of them will be September. going forward, and I'll try and get one together every month so that you all can keep up on what's going on in Angular. So yeah, this was kind of self-promotional, but I'm hoping that this helps folks out. The meetups, at least for now, are going to be free. The conferences, obviously, you're going to have to buy a ticket. You don't have to get a hotel room. You don't have to pay for a flight. You just buy the ticket. So anyway, those are my picks. Mana, do you have some picks for us?

 

now. I feel like the game you described sounds

 

Hmm.

 

a bit like that game

 

Yeah.

 

sushi.

 

So she go

 

Have you heard of that game? Sushi? Yeah, I don't know if I'm saying it right. I only played it once but it was kind of like similar to that where you pass the cards

 

Yeah,

 

around and

 

that

 

you have

 

one's

 

to pick

 

pretty

 

and

 

simple

 

stuff.

 

too. It's a fun one.

 

Anyway,

 

Effectively what

 

before

 

it is,

 

I-

 

is you have different sushi dishes or things like that, you know, teas, stuff like that. Then yeah, you take your card,

 

Yeah.

 

place it face down, and then everyone flips it over, you pass your hand to the right or the left.

 

Mae'n fwy fwy. Mae'n fwy fwy. Mae'n fwy fwy. Mae'n fwy fwy.

 

Sounds like

 

Mae'n fwy fwy.

 

a fun place to be.

 

But anyway, for my pick, I am gonna talk about how... It's a story I mentioned to Stephen earlier on in the weekend, he's like, why didn't you talk about it? I was like, okay. So basically I've lived in my current house for like maybe three years, and my neighbor, she's like a massive fan of gardening. She's just planting all sorts of exotic things. And she always says, oh, I'll plant it really close to the fence so that... it might come over onto your side. So I'm like, okay, cool. And she's been planting passion fruit, but it's never actually given any fruit. The actual flower looks like something out of a movie or like in outer spaces. It's just, I can't believe that that's a flower. So check it out online if you can. It's so beautiful. So weird. But this year, somehow. Passion fruit grew out, so the actual fruit. And I just can't believe it, like we live in England and there's passion fruit growing in my garden. So, it's definitely the highlight

 

Nice.

 

of my entire life. I'm sorry.

 

All right,

 

Yeah.

 

good deal. Well, if people wanna reach out to either of you and connect on anything we've talked about, how do they find you?

 

I'm on Twitter as Scoopadev. S-C-O-O-P-E-R-Dev. Yn. I'm on Twitter too. That's just my name. I'm not that creative with it. Just monoperov. Also, I'm on LinkedIn, obviously. I think I'm probably more active on LinkedIn, so if anyone wants to message me,

 

All right, cool.

 

they can message me on there.

 

We'll go ahead and wrap it up here. Thanks for coming, this was fun. All right, folks, until

 

Thanks

 

next

 

for

 

time,

 

having

 

Max

 

us. It's been

 

out.

 

great.