Erik Hanchett is a Front End Engineer at Amazon Web Services. He returns to the show to talk about creating open-source library tools. He begins by explaining the requirements, tools used, and many more in creating the library.  

Hello everybody, welcome back to Views on View, the podcast where we have a view on ViewJS. That's good, I know, thank you. I am Steve Edwards, the host with the Face for Radio and the voice for Miming, but I'm still your host. And today with me back for yet another visit is Mr. Eric Handchet, how you doing, Eric?

 

Hey, hey, how's it going, Steve? It's good to be back. Good to talk

 

Good,

 

about Vue.

 

yes, good to have you back. Good to have you back. Eric and I were just chatting beforehand and noticed that in his videos, he still has a reference to his Vue.js in action book, which is a few years old and mostly on Vue 2. But if you still wanna go buy it, you still can at a link in his YouTube videos.

 

Yeah,

 

But.

 

I have a list of links to just a bunch of different resources and my YouTube videos and one of them happened to be my view.js in action book which is a few years old now, but I'm proud of it. It did really well. It helped a lot of people out.

 

and now you're independently wealthy because of it, right?

 

Yeah, yeah, exactly. That's, you know, I'm this actually not sure for the listeners out there, but I'm on my yacht right now. Okay, now I was just lying. I don't have that. I'm

 

Yes,

 

in my office right now.

 

we all know that writing technical books is a very lucrative pastime.

 

It is. It is. It's a labor of love. Yeah.

 

Yeah.

 

I have been thinking about another version of it, like a revision 2 of the Vue.js inaction book because of all the positivity of writing it the first time, but I just don't know if... I don't know if I have the time. I'll put this out there. If anybody's listening right now and wants another Vue.js inaction version 2 with more Vue 3 stuff in, tweet me at ericch. And who knows, I'm actually might even be up for having someone be who's really good writer that could co author it. Who knows?

 

Yeah, I've worked on a couple books. I worked on a couple Drupal books with a buddy of mine who was writing books. And I was just the technical editor, just double checking stuff. And man, that took a lot of time, a

 

Oh

 

lot

 

yeah.

 

of time.

 

Yeah.

 

So

 

Yeah.

 

it's like, yeah, I don't think. And then when I made the videos for View Mastery, I worked with Adam Jarr and that crew. Even just writing the scripts for the videos took forever. And I didn't even do the screencasting. They had somebody else do it for me. We talked about that in an episode with Adam Jarr. And that took a lot of time. I'm like, okay, I'll do it once in a while, but not a regular thing for sure.

 

Yeah, I'm so impressed by the V Mastery, the V School people, like just the quality content they put out. And it's a lot of work putting in those videos out. My YouTube channel, I'm like literally an hour or two before. I'm like, that's an interesting topic. You know, I'll put this together and I'm like done in a few hours. But those guys, like they got scripts, they got whole editing teams. Yeah, it's pretty impressive. Yeah.

 

Yeah,

 

You were there with

 

in that episode

 

them.

 

with Adam, we went into all the details about who does what and all the people involved. I mean, like the guy that, and I'm already forgetting his name, I have to look it up, but the guy who did all of the scripting and the recording for me, and he was sort of like my director and video guy, he was awesome. So definitely made the videos a lot better than they could have been. And the best thing with, probably the best thing about all the View Mastery videos was that they let me incorporate my dad jokes at the end of each one. So you don't get them on YouTube, you gotta pay for them on View Mastery, but the best part is the dad jokes at the end.

 

Mm-hmm.

 

Well, that's good or bad, depending on your point of view. Anyway, moving on to our topics for the day. For those of you who may not be familiar with Eric, he now works at AWS, Amazon Web Services, and is a developer relations guy, a dev rel, I guess, or I'm not sure what your developer advocate.

 

Yeah, yeah, developer advocate.

 

uh, at AWS, having initially been hired to do some view development. Uh, fortunately for Eric, he survived the layoffs at AWS.

 

Hehehe

 

Been going around. So that's a relief for sure. I've been the victim of third round of layoffs before in my own history, so I know, know how it feels. Uh,

 

It. Mm-hmm.

 

but anyway, we're going to talk about, uh, a new He's created for AWS using Vue.js. So why don't you tell us about that?

 

Yeah, yeah. So I'm not sure if I mentioned this in previous podcast episodes, so I've been doing, as part of my developer advocacy work, I'm new to developer advocacy. I've been doing front end development and back end development for my whole career. But part of being a DA, I've been submitting talks to a lot of different conferences. And a couple of the talks I've done, one is on creating open source libraries and tools. So for the last two years, I've been working on an open source team at AWS that works on the Amplify UI components library. And one of the first things we did when we started was we had a really old version of this library that was written in Stencil. Stencil's JS, so it was using web components, which was fine, but we decided that we wanted to rewrite it in kind of like the native platforms, the native libraries out there, instead of using web components. And so we embarked on this journey for about two years to rewrite the Vue library for Amplify to use in Vue 3. So instead of using an older Vue 2 version, we wanted this Amplify, and it was a UI library, to be written in. in for view three. And so that was my job for the first, a good year and a half, probably closer to two years of maintaining and setting up that library. So I created a whole talk on this, on writing, on creating my first open source library. And I thought it'd be interesting. I could talk about some of the things that I learned in that process and some of the things that worked well and some things that didn't work well. So we can jump into that. How's that sound, Steve?

 

Sounds good to me. You're the expert on it, so I'll let you lead the way.

 

Yeah, so definitely this is a talk I'll be giving again here soon, but I think the point of it is like when you start creating an open source library, you really have to define some of the requirements. So like one of the important things you need to do. So at the beginning of the process, we needed to create what basically is an authenticator and... So we have a back-end Cognito authentication authorization system. It does identity management. And we wanted to create a component that anybody could just drag and drop into their view app to add in this functionality to be able to log in or sign in, sign out, do federated log in, to handle, forgot your password, to handle multi-factor authentication. So we wanted a component kind of does all this together with minimal amount of boilerplate to add to an application. So as I started this project, View 3 was coming into its own. Still definitely was early days in View 3. And so we had to make some decisions, like, do we use, what kind of build system we use. So we had a lot of talk about using View CLI or VEAT. And when I say we, it's mostly me, but the royal

 

Hahaha.

 

we. Then should we use JavaScript or TypeScript? I think pretty obvious today. that TypeScript's the way to go through most new projects. Not always, but most of the time, I believe. But back then, we had some questions, because View2 was famously known for not being very good at TypeScript back in the day. There was really good TypeScript libraries you can add, and View3 was coming out, and View3 had much better TypeScript support. And then the Composition API or Options API, this was first when everybody was really nervous about the Composition API. Do you remember those days, Steve?

 

Well, what I remember is the, and I've talked about this before and here's when the initial announcement came out About the whole restructure the blowback was just like fierce I think you got a lot of blowback from one of your videos if I remember correctly and I think The concern was backwards compatibility with view two, if I remember correctly, you know, when forcing everybody to completely redo all their code if they went to view three and they came back and said, okay, whoa, we're not gonna destroy backwards compatibility with the options API. But that's my recollection of when view three first came out.

 

Yeah, exactly. And we went through that. I mean, there was a whole lot of bloat. People were nervous about this. And rightfully so. And so we had to make that decision too, as we were creating this new libraries. What paradigm, what things do we do? This is an open source library. We want to make sure that as things continue on, developers are able to jump into the code base and use it in the proper ways. Then Pinyia, we were thinking about state management systems. Like, Pina is obviously pretty popular, but we're thinking about XState. And there's some things that I want to talk about that. And then we looked at Vutify and Vutify 3, and I know we've had John Leeder on the show, and he actually used JSX for his open source library. So we considered that too. It was like, maybe we're gonna even use templates. Maybe we should just use JSX because JSX, we have a lot of React developers. So we kind of had a... think of a lot of these decisions at the beginning and what was the best for us. And then we thought of those decisions. I'll tell you guys what we decided on. But we also had a set of requirements with our open source library, like accessibility. I think it's like table stakes for all, I think most libraries out there. How accessible are you? Are you WCAG compliant? And that was something we strove for being 2.1. AAWCAG compliant. We had

 

WCAG

 

a,

 

is...

 

it's WCAG stands for, it's the web accessibility, basically it's a test of web accessibility. I think it's web content accessibility guidelines. So the w3.org lists out a set of guidelines for accessibility and 2.1 is, one of those guidelines. And you can find it at w3.org. And it's a very dense document, but it gives you a lot of information. And then there's tools that you can use to test against that accessibility standard. I think we used one. I can't remember what we used. There's a handful of different tools. But anyways. Then. Bundle size was a really important consideration. So we looked at one thing I hate as a developer is when I bring in a package into my project, and then all of a sudden it doubles the size of it when it builds. What's the problem here? So we had to make sure the consideration of how do we keep that low. Then we think about how you build packages in modern days. Like, Back then, people were still using node built-ins in their packages. And now it's pretty common that everybody uses ESM. So make sure that we have web components. We use V for our builder and bundler. And it uses rollup in the back end, the background to do it all. So we made sure we had that consideration. Plus, as we were creating this Vue 3 open source UI component, we were also simultaneously creating and a React version. And so we wanted to make sure we were using our best practices and we were using code between all three. So we decided to use a monorepo was one way to handle that. And also, we used XState. So this is kind of interesting. So XState's like a state management tools that use finite state machines. So you know exactly. If you ever use state. state machines like in your computer science programs. This might be familiar with you. Probably many people listening right now isn't. But it's a particular way of handling data where if there's one unique way that that data flows through your application. And we really latched onto that, especially since it had great package support. And we could create one state machine that we could share between our React, Vue, and Angular, and later our other implementation. So any of our JavaScript libraries, state machine and then share it between all three. And that way we had kind of similar state and outcomes for all three. And it made it easier that we had basically every single, between the different libraries were all very similar when we were done. Have you ever used XState?

 

actually I'm here looking real quick but I talked to somebody about Xstate on either JavaScript, Java or here and I remember we had a really great pretty in-depth talk about it. So my understanding from it,

 

Probably David Kay piano.

 

no it was a guy I don't know if it was Maya Chavin or who was it we talked to. I'll have to find it and put it in the notes but it was a good thing good talk and what I remember about state machines versus Vuex state management is that state machines had more to do strictly with, how do you say, the condition or the state of your app as compared to storing data in it, right? So for a

 

Mm-hmm.

 

single page app, you would use Vuex or Pinyo, whatever the case may be, to maybe grab data from your front end and put it in state so that it could be accessible by multiple components in a reactive way, where state machine was more like, okay, I'm in this state, now I'm those things are in your app. So it's more narrowly focused and defined than a Vuexr tool that's

 

Yeah,

 

defined

 

that's a good

 

as

 

way

 

state

 

to put it.

 

management.

 

Yeah, no, that's a really good way to put it. So yeah, you're going from one state to another state. So if you log in, like if you're at the login page, that's one state. And then you click the Login button, you're in another state. And then when you're authenticated, you're in another state. And then you can have data that's shared between those that you can share as well. But no, that's a perfect way to do it. And so we wanted to make sure our authenticator had each state. a certain state for each one of them that we could share that between all different implementations. So it's definitely a different way to think about it. And then we looked at like view3 best practices, like composition API with script setup. We ended up using single file components with templates. We did not use the JSX like I mentioned earlier.

 

Good for you.

 

We used TypeScript. I know, I'm on a view podcast and I'm talking about JSX.

 

Well, I'm, yeah, my experiences with it haven't always been positive. Maybe that's just because I'm not familiar with it, but it makes me nervous when I think about having to write in that.

 

The only time I ever did it was when I was, I created a couple of videos on my YouTube channel, um, on Eric.video, which I was just playing around with JSX. And it's definitely different than it. There was some nuances and differences between it and using like a React app using JSX. So I, and it takes time to get used to differences of doing things and using, still using your, your nice directives like VF and V4 and. Now you have to do maps and ternary operators. So as we were going through this process, we decided to turn on TypeScript. We turned that on. We turned strict mode on. We actually had at one point we had any. You couldn't do any anywhere, for those who know that any is a way to opt out of TypeScript. But we ended up having it on. So there is definitely, to this day, there's still some things that aren't typed. And then we used some linting, ES3, Vue 3 Essentials, Vue Slots, things like that.

 

I found my episode, it was Mya Chyvin, that we talked to, view 147 from, yeah, it's been almost, oh, almost exactly two years ago. Talked about

 

Nice.

 

Xstate.

 

So as we went through this process, it was pretty fun just jumping in and writing view code all day. We did a lot of testing. We set up Cypress end-to-end testing throughout the application, which we went back and forth. I think if we had to do it again, we would have focused more on view testing, unit testing, with Jest or using the Vtest. Well, because we found that one of the advantages end-to-end testing is it's like you're basically as if you're the user and you're clicking around and it's very like black box testing at that point. And it's very thorough and it's one of the best ways you can test. But one of the disadvantages of it, it gets a little slow. And so it's a little bit slower overall than our test suite after adding in dozens and dozens of tests. It was taking quite a bit of time to run through all of them. And then I think the sweet spot is to have test coverage. I used to not be in favor of test coverage tools and having like an 80% unit test coverage because you're in some organizations, people can manipulate that or write, you're writing tests for the sake of tests, just to pass them test coverage tool. But I found that having a great team of other front-end developers having a very high operational excellence bar, that you end up writing pretty good tests that get code reviewed by very smart people. And you can't get away with writing, obviously, bad tests. And so as we've seen with other different lists, our React code base and everything, I think having a combination of more unit tests and then have a separate amount of integration tests, I think, would have been better. We've really over-focused, I think, on end-to-end tests. That's changed a little bit recently. But at the beginning, it was definitely more end-to-end test-focused.

 

Yeah, we do, you know, in our, my day to day, we do a combination since it's Laravel and Vue, we do a combination of PHP unit, uh, and then, uh, dusk, which is end to end. It's you know, it's basically like Cypress, uh, testing and we tend to focus probably more on the end to end testing just because, you know, we catch, we catch a lot of stuff with those, with those tests for sure. And it takes a while. I think. Anytime we had to fix some things in our circle CI configs, but we're looking about, I think it's around 15 minutes to run our test suite. I'm not sure where that compares to other people, but there's a ton of tests. Um,

 

That's good.

 

but, but yeah, it takes a while to run, to run those tests. So side note real quick. Have you seen playwright?

 

I have heard of it, yeah.

 

So I interviewed Debbie O'Brien about that here a couple months ago, two, three months ago. She's like the big dev rel for Playwright. And it looks really slick. I haven't had a chance to try it yet. It's basically a Cypress competitor, I think. And I know I've talked to a guy from Cypress probably three, four years ago on JavaScript Jabber about Cypress and how it works. They're both really pretty slick front-end testing libraries for sure. So there's multiple options out there for doing the front end testing.

 

Yeah, yeah, I took a last year at Vue Conf US, I took Jessica Saks Cypress course,

 

Uh-huh. Mm-hmm.

 

her workshop, and it was great. I learned she deep dived into it. I think she's at Ionic now. She works in Stencil. It's JS, speaking of Stencil.

 

That sounds familiar. What's her name again? I'm sorry.

 

Uh, Jessica Sachs.

 

Okay.

 

S-A-C-H-S. But she ran a workshop last year at ViewConf, and I think she's running another one this year too. So anybody who's listening is going to ViewConf, you might want to check that out. Testing is very interesting. We could do a whole podcast on testing. I have

 

Sure.

 

some opinions that they've been changing recently based

 

Mm-hmm.

 

on it. One nice thing is, I don't think many open source projects do this, we created a full Canary Suite. So we run through all our packages every 15 minutes. We test them out like on Invit, View CLI, even our React and Angular. Same, we build them with the latest version that we've published. And then we also run some end-to-end tests against them to make sure that nothing broke. And then we have a canary that does that. And we're all using GitHub Actions to do it. We also use CypressCucumber, which is a way to do behavior-driven development. It's almost like you write your tests. in human readable language, like scenario, sign in with unknown credentials. When I type this, do this. And I type this. Then I see this. And this, you can translate it to your Cypress definitions that you have. So yeah, we did a lot of work on testing on this library. I kind of fast forward a little bit to what went well. I mean, kind of looking back on this, we The parity between the Vue, React, and Angular versions of our authenticator was really well done. They were exactly the same. The end-to-end testing ended up catching a lot of issues during our development lifecycle. Even though we were mostly doing end-to-end tests and few unit tests, that still caught the majority of the issues. And we got a really lot of positive customer feedback with what we did. But some things I think, like looking back on creating an open source library, I would have done better for this project is we probably should have had higher ESLint levels just to catch more issues. I think as you go on with projects, just being very diligent to look at your ESLinting and can you kind of put it to the highest level. And Vue has a Vue 3 recommended, but they have higher levels. And you can add in your own ESLint rules. And I think we could have done a better job there. The library only supports Vue 3. This was really before there was like, there's Vue Demi, and a few others that allow you to create open source Vue libraries that work with Vue 3 and Vue 2. But at the time those didn't really exist, so we went all in on Vue 3. I think most of the community has transitioned to Vue 3, or at least Vue 2.7 at this point, which is fine, but you can still use our older library with Vue 2. Just with View 3, you have to, View 3 is, we created a new one just for View 3. And then there are lots of slots within slots. So we kind of took the approach of allowing you to override a lot of different places. And it kind of made the code complicated with these nested slots. And looking back, I think that could have been done better. And then it was harder to get like, as a big company like AWS and even our team. It was still hard with an open source project to be able to get external contributors. How do you put out towards the world that, hey, this is an open source library. How do you get people coming in? How do they know that they can change things? How do they get the testing? Especially, it's really hard to do end-to-end testing as a contributor. So unit testing, obviously, would work much better. So there were some things like that we could have done better. But at the end of the day, we Compared to our older library, this one was getting like double the amount of weekly downloads and NPM, and it's been continuing to grow. So that's a little bit about kind of the journey that I've been taking the last year and a half.

 

So just for a little more detail, so this library is, I think we mentioned this, but I'll just clarify. It's designed for use with AWS, right? It's not something you can use to log in to some external system, it's used with basically Cognito, your authentication platform and accessing AWS resources.

 

Yeah, so it's a component library, but to use it, it's really geared towards Cognito. And you can use it with our other AWS tools. So there's a whole bunch of different AWS Amplify tools, like the UI component library. But there's also a JavaScript library that works on any platform. And that one, and then there's a CLI, and there's a thing called Studio. So with Studio or CLI, you can provision your whole back end. including this Cognito authentication user pool. And then you can use the UI component library to easily log into those systems.

 

Yes, I know authentication is such a nightmare, I think, for anybody.

 

Yeah.

 

That having something like that that you can drop in and works for you is a very big time saver for sure.

 

Yeah, so that's one of the talks I'm working on. Hopefully it'll be out. Hopefully I'll get a couple of talks, those that talk in. There's a bunch of Vue conferences coming up soon. So I'm looking forward to them. VueConf is coming up. VueLive London is coming up. I think there's a couple more too.

 

Where's ViewComp this year? I forgot.

 

It's in New Orleans.

 

That's right, it was somewhere down south.

 

Yeah, I'm excited for it. I've been to every... No, that's not true. My first VueConf I've been to was 2020, right before the pandemic hit, which was weird because it was in March, right before the pandemic, and I noticed a bunch of people leaving early from the conference. I think people were getting nervous already at that point because that's when the lockdowns and shutdowns started happening. But they didn't cancel. To Vue's credit, they... They didn't cancel it, I guess, because it still wasn't at that level at that point. And then I did the online, uh, I did, I think it got canceled in 2020. Maybe it was virtual in 2021 and virtual in 2022. And now it's back to being in person this year, which is great. And I, if I remember correctly, someone tweet me at Eric CH if I'm wrong, but I think the first viewconf was also in New Orleans. So this is kind of like going back to the roots of the first viewconf. And that

 

Yeah,

 

was

 

I was

 

in

 

supposed to go

 

2017.

 

to 20, see 2019 in Orlando,

 

Hmm

 

Port Laros, it was in Florida. And I was all set to go and I was signed up for a, one of Evan Yu's workshops on

 

Wow.

 

like core view stuff. And my company was sending me, well, I ended up leaving the company about a month or two before the conference, so I didn't get to go. It's like, dang, I should have

 

Ah!

 

waited a couple months and then left, you know? But I

 

I want

 

left.

 

to go to the view conf in Amsterdam. That's the one that I guess is even bigger than the one in the US, I've been told.

 

Oh really?

 

Yeah, it already happened in February of this year, so I guess for next year.

 

Right.

 

But yeah, it's a big three-day conference like the one in the US.

 

Is it always in Amsterdam? Is it always as compared to like a view Europe that rotates locations?

 

Um, I think it is? I'm not entirely sure actually.

 

Yeah, I'd love to get to there's so many people I know from the view community from doing The podcasts and and other things that I've never met in person. So yeah, I definitely need to get out at some point and Press the flesh so to speak and meet people in person

 

Yeah.

 

I was all set to go this next year, I think, and then as with many places, budget cuts hit and they're like, yeah, sorry, you're not going. At least we're not going to pay for you to go. Let's put it that way.

 

Yeah, that has been everywhere. It's been the same thing. While you were talking, I was just looking at the different view conferences all over the world. But yeah, unfortunately, I've seen the same thing. A lot of companies are cutting back on travel. So luckily as a DA, I'm not as affected, but

 

Mm-hmm.

 

I am affected some.

 

That's part of your job, right?

 

Yeah.

 

Heh.

 

Yeah, as long as I'm participating, talking, being a part of it, that's fine. If I wasn't being a part of it, then I wouldn't go.

 

Right, cool. Alrighty, so let's move on to a couple topics that Eric has covered in some of his videos and has to do with some items that are in the current 3.3 release that has yet to actually be released, still in beta three as of two days ago, as of this recording. Some changes to define model and define props.

 

Yeah, so I've been on a quest recently, especially with all the View 3.3 stuff dropping recently, to figure out what's in it and try it out. And I was telling Steve before we started this broadcast that probably should have someone in the Quorum team or Evan Yu himself to help explain some of these things. But I will try to do my best. But from what I've been playing around with it, I've been excited about these features. So one of them is a. View props. Well, let's start with, yeah, let's view props and you can kind of play around with some of these things right now. Well, let me rephrase this. So if you go to like the GitHub and look at view the view core, there's some betas out right now. And there was alphas before that that have some of these features in it. If you if you use the view playground, the view single file component playground, you can kind of play

 

Cool.

 

around with them today. I'm not entirely sure if you're using Vue CLI, or excuse me, VEET, or the create Vue tools out there if you can kind of play around with these today. And also, since they're in beta and alpha, it's probably not production ready. Some things might change, but I think they're almost locked in. But what I've been doing to try to test it out in my channel is I've been using Vue Macro. So some of these things are actually just macros changes. So if you view macros is a library that has a bunch of official and experimental type macros that you can add into your view applications. And you can kind of macro is one of those ones, like if you're in your script setup, you just add in. There's some built-in ones like emits, define emits, and define props, and a few others. And you. This view macros kind of adds these into your application today that might not be in the view core yet. So one of which is going to be in view 3.3. And this is define props. And it allows you to destructure props, which is a really nice thing you can do. So if you've ever used props today, you have to be really careful. about destructuring because you can lose reactivity. But with this new type of defined props, you don't have to worry about that. There's also another change they added is allow you when you're creating your application, you're adding types to your props that now you can import them in from an external file. So before, if you try that, it gives you an error. But now you can import in your type. and then just directly inside your define props, inside your angle brackets, you can put them in, which is really cool. And then another thing I've been playing around with is define models. And it's hard to describe, but if you ever add a V model to a component, you can pass in values. from a parent component into a child component that you had the vModel on, and it's two-way data bound. So if the child component changes it, it updates in the parent and vice versa. And typically, when you pass values in as props into components in Vue, they're read-only. So if you try to change that prop value, it ends up giving you an error message that this prop is read-only and this is not the proper way to do things. So. Today, even before you can use vModel, but you had to do this kind of weird syntax where you had to like, you had this update colon model and you had to omit the update back and it was a little more complicated. So this vModel, or this new defineModel allows you, it's called defineModel, it's a macro, allows you to like just make the change in the child component and as if It's just like a normal variable. And you can make the change without having to do this kind of emit dance. So it's a little bit less boilerplate, and it made a lot more sense to me.

 

That's called component V model in the docs. I'll put

 

Yeah,

 

a link

 

V

 

to

 

model.

 

the show notes. And I'm actually using that in my app that I've been working on. It took me a little while to figure it out and get everything named properly. But once I got it working, it's great. Because in my particular use case, with inertia, the way it works is in your controller, you say, OK, render this page. Here's the page you're rendering. Here's the props to pass to it. But if in your and. these are components that are in the pages directory. But if you have an included component within your main component that's being rendered and you wanna change data in there, you have to pass it back to the parent in order to communicate with the controller, if that makes sense. So in my particular case, I've got like a, you know, it's a page component and then I have an embedded table component with some sorting and filtering and searching capabilities in it. So... I had to wire it using this in such a way that when you typed in the field in the child, it admitted to the parent and then communicated with the controller and did its thing. So, once you've, it's a little confusing at first, the current method where you have to name things just right and certain things have to be matched up, but once you figure it out then it makes sense. So it sounds like with your description then this will become a little cleaner and easier to use.

 

Yep. Yep. Yeah. And you can use it multiple. You can use this to find models and have it multiple different values you're passing in, have it that kind of two-way data-binded way. I think most people use vModel just like on an input. It's kind of like the common use cases where

 

Uh huh. Exactly.

 

you're just trying to take a value from an input and have it available in your script. But this one gets a little bit more complicated when you're passing values from a parent to child component. And vmodel, I know somebody's listening right now, and like, isn't that just syntactic sugar for

 

Yes,

 

binding

 

it is.

 

the value and then using a von? Yes, you're right. So for those who don't know yet, you can do this without vmodel itself. You can bind values to inputs and then look for input triggers and then set the value itself. And you can do the same thing with a component. But this makes it a lot easier. And then define models will make it even easier. So you don't have to handle the emits the same way you had to before. And it's almost like you're adding it like a ref, because you can do.value in your child component. So these are all kind of neat new things that are coming out in View 3.3. One I didn't have time to play around with, which I really want to play around with, is generics. There are some limitations in TypeScript with props and if you're using generics, which I haven't deep dived into, but Vue 3.3 is supposed to add that functionality too. And I think that's where a lot of people who are really TypeScript heavy, more advanced applications are looking forward to, is TypeScript generics.

 

Right, yeah, like I was telling you beforehand, I'm gonna have to dip my toes in the TypeScript pool here soon, I know it. I'm getting sucked into the vortex, I know it. Although, side note, and this is interesting, and I can't remember if you and I talked about this or if I did this on JavaScript Jabber, have you seen that svelte, Rich Harris talked about this, is getting rid of TypeScript?

 

No.

 

So yeah, I can find the link somewhere. I saw it on Hacker News. And I was talking with somebody in a... in a Discord channel about this. And the proper context isn't that you can't use TypeScript in Sevelt, it's just that they're not going to use it in the core. But it will still support it if when you're writing your Sevelt components, you still want to use TypeScript. So it's perfectly fine. But he talks a little bit about it and why they did it. And existing tools are enough without the overhead of TypeScript. So I thought that was interesting.

 

Nice. Yeah, I wonder what the rationale is not using in core. I think it really helps with just catching bugs. I mean, now you have types. So now it's like you have a typed language, and you can catch things easier. I remember back in the day, I don't know, years ago, I was working on an app, and we used TypeScript on it. And TypeScript wasn't as popular as it was today. But someone was like, we could just use TypeScript, and we don't have to do testing at all, like a very thin layer of protection in our app. But maybe this is all we need to do. So I think in this app we created, we didn't have any tests. But we did have TypeScript. So we had something to catch obvious issues

 

Oh, I

 

as long

 

see.

 

as we typed everything.

 

Uh-huh. Where was it? Oh here it is. Okay. Yeah, I found the article. So all right, last topic. Oh, before I forget, I'm jumping all over the place here. We were talking about macros. What is a macro? To me, you know, when I think of macros, this goes way back to uh days gone by before when I was working in something like Excel, a spreadsheet. And so a macro was a way to automate running a multi-step process. So you could I'm going to open this tab and click here in this cell and type this in and run these calculations, whatever it was. And it would record it. And then you could assign it to a button in your bar and say, run this macro. And it would do all that for you. So is that similar to what macros are here that you're talking about in view, or is they completely different?

 

Yeah, so I'm looking up the definition as you're talking, but the view guide that talks about macros are globally available, and you don't need to import them. So that's one of the ideas, is that you don't have to import macros into your component. And then they have bits of maybe similar to what you're talking about, some functionality inside them. So the macros that are already built into view, I believe, are there's three of them? Um I have to look them up. I think define props, define emits are two of them. Define expose. So those are three macros that are built into Vue. And so if you're using a composition API using script setup, then you would do like const prop equals define props, and then you can put in like an array of, or an object with key values of every single prop,

 

Uh huh.

 

but you don't have to go import and define props.

 

Right. As compared to a composable, which is something that you would write, but you would have to import it in the places where you specifically want to use it.

 

Yes, yeah, so if you had some functionality and you wanted to reuse it in multiple places, then you can put it in its own file, usually with the use at the beginning of it, like use handler or use mouse. And then you would import that into your app, and then you would have that functionality. So some people don't like these because it kind of looks like magic.

 

Voodoo.

 

Yeah. and they're called compiler macros.

 

Right.

 

And

 

I guess.

 

then they do not need to be imported, and they're compiled away when ScriptSet was processed, too.

 

Oh, interesting. Okay. Cause I, you know, anytime you, you have something that's globally available, you know, the concern obviously is, are you importing it and having it in there in places where it's not being used? Is it causing, you know, overhead problems because it's everywhere?

 

That's

 

But...

 

true. Yeah, I think since it's compiled away, it's not going to have those issues. It's part of the compiler looks for that name. I have noticed in VS Code, you definitely need to make sure you have volar installed, and you have to make sure at least volar. Otherwise, you'll get a bunch of, if you open a.vue file and won't recognize it, it'll think that these macros need to be imported in. I have had issues in the past where VS Code has something wrong with it, and all of a sudden it keeps telling me, doesn't recognize defined props, doesn't recognize this. So you have to be careful with that. But as long as you have the right extensions installed in the latest version of VS Code, or whatever WebStorm or whatever IDE you use, then it should be fine. I like them. There was a whole talk about Reactivity Transform was gonna add even more to these compiler macros. And there was a lot of talk out there about like, people really did not like them. It was adding like way too much magic. It was allow you to like unwrap refs using dollar signs and it wasn't really obvious of what the dollar sign meant and people disliked that. And that's actually not gonna be in view 3.3. Evan has already talked about how he does not want it on there. I know I should say, keep me honest, Steve, if I'm going into an advanced topic or a topic that needs to be explained more, we can break that down further.

 

Oh yeah, I'm all about the definitions,

 

Yeah.

 

for sure. I remember one time I listed, always brings me back, I listened to a podcast and they were talking about, oh gosh, what was it, reactivity, the observables type of thing, and there was a particular

 

and

 

observable library and for the life of me, I can't remember what it was.

 

RxJazz.

 

Yeah, I think yes, it was RxJS and it was John Papa on his... his episode and so they dived in and started talking about RxJS and all this stuff and I got to the end I said, what's observables and what is Rx supposed

 

Yeah.

 

to do? And all this. I didn't get it and I tweeted him and said, hey John, next time you got to describe this. Oh yeah, okay, good point. So yeah, I always like to make sure that we define the things that we're talking about so people don't confuse.

 

Yeah, there is some viewisms out there that I think even when I'm working out my work and I talk to React developers or Angular developers, they're like, what? You're emitting data? Don't you just pass everything down as functions? Or like, well, no, we have this paradigm that we use and we have these refs. What? You don't have a use state? Yeah, it's definitely worth explaining some of these topics, especially for people who may not be knowledgeable at them.

 

Yeah, you gotta be aware of the GeekSpeak and the acronym Speak.

 

Hahaha.

 

So speaking of GeekSpeak and acronym Speak, let's talk Ref versus Reactive. These are, for those who may not be familiar with them, they are ways to define, what is it, Reactive data, in View 3 with the Composition API, where before, in View 2, you would define, in your script, you would define your data. function, it's actually a function not an object, and that would return whatever pieces of data you wanted to define in your component that you wanted to be reactive, whether it was a string, an object, an array, a number, whatever. And so now we wrap them with ref and reactive to use JS proxies. And that's about all I know from them except how to use them. So Let's talk rep vs. reactive. There are differences between the two and I know I've seen Numa's blog post written about them just to explain them. So with that we'll let Eric explain them all.

 

Uh, I don't have,

 

No pressure.

 

so I've, I've been researching reference reactive. I've been using them, but it's kind of arbitrary. Like when I use one versus the other, I've used to always use refs. And then I started getting more reactives and I've been thinking about like, when should I use when, and I'm working on a conference like talk on this or, or a blog post or maybe in a video at some point, and I've been researching and there's definitely a lot of different opinions on it, but I guess to define some terms, like anytime you do add in like reactive. reactive data. So like let's say something that needs to change in the template and it needs to be kind of updated. So as you're updating the script, it needs to be updated in the template, then you'd make something reactive. And ref usually it takes in as a like a primitive or an object. So you can have like a string or boolean in there. While reactive object, reactive is the keyword and then that would be more for just objects. And ref has a couple of different similarities, differences too. With refs, you use dot value everywhere. So if you define something, you can do something dot value, and you can get to it. While reactive, you don't need to. You can just reference it directly. Ref, you can also kind of do a complete reassignment with dot value. You can equal something. quite the same. You don't have that type of reassignment there. As for using one versus the other, I've gone in this habit of using refs quite more often than reactive because since it can support objects, it seems to be a little bit easier for me. One pattern that I've been using is I'll put in a lot of my logic into a composable and I kind of stole this. from Vue use and other popular composable libraries is I'll put all my reactive variables in there, and then I'll export them out as an object with each ref as a different value inside there. So then you can destructure the values out as I import it in, because I'll import them in and then destructure the object with each ref, and it'll keep its reactivity. So that's one technique. If you use reactive by itself and then you try to destructure, you lose reactivity. So that's a reason that you've got to be kind of careful with that, too. So that's my opinion. I'm still kind of doing some more research and seeing what other people think. There was something called, we kind of touched on it before, with the reactivity transform, where it was like a compiler macro that allowed you to like un, like not be, you could basically use a dollar sign and not have to use the. dot value everywhere when you're using refs. But I think that's kind of gone out of favor and they're not going to you could still use it if you use like a third-party library like that view macros library. But otherwise, I think we're not going to see that. And then if you look at the implementation of some of these things, like for ref, let me see here. Yeah, if you look at the implementation for ref in the view 3, it actually uses a reactive, a two reactive,

 

That's right. I remember that.

 

which

 

I looked at that.

 

is kind of interesting. So it feels like ref, I think, would be... Depending on your situation, I've been using just rough more often. Do you have an opinion on this?

 

I have to go back and look at my code. I know I've wrestled with this a few times, looking at the view docs on a reactivity basic, or fundamentals, excuse me. The one difference is that reactive can only work for object type, objects, arrays, collections,

 

Right.

 

whereas ref can handle scalar types, so a string, some sort of non-object value, single value. So I remember somewhere, and I think we were talking about this, Eric, there was one can handle mutating deeper objects, items, and one doesn't. And I don't remember which is which. Don't shoot me if I'm wrong. Somebody can fact check me on this if they want. But I remember that's one thing I read about. And I think my tendency is to use ref. like you said, just because it handles more use cases in terms of the data types. And there, I haven't really seen any issues where you'd wanna use reactive versus ref, shall we say. The one thing that is trickier in accessing the data, depending on whether you're doing it within your template versus another function or something else in your script. is how to access the actual values. You know, sometimes you have to use values, sometimes you don't. And then I like to, you know, look at things in the debugger, in the dev tools, in the browser. And now when you spit out, you know, something that's wrapped in a proxy, and so you gotta drill down to figure what your data is, and haven't quite gotten down how to spit that out to the console in a little cleaner way, but. I think you have to stringify it or do something. But yeah, that's the only downsides I've seen to that. It's definitely a different paradigm from Vue 2. Vue 2 is a lot simpler in how it handled that, making reactive data. So this, and just from a coding standpoint, it seems that the benefits are more behind the scenes than they are in how you're actually writing your components. If anything, it's made it harder.

 

Well, I'm glad it just works. Like I don't, I've been doing a lot of React lately and having to worry about use effects and having using use state and making sure that I'm not re-rendering too many times and making sure I have my dependency array correct. And I'm just glad I'm like using view and I'm like, I just put this ref here, it works and I'm happy with it. I do, I did ran into one scenario where I was using it. pretty complicated nested object and I was using ref. And I just didn't love the way I was reassigning the values. But for the most part, I've had very little issues at all just using ref everywhere in my code base. But yeah, it's great. And I think there's a whole discussion about ref. I think Evan Yu even had a Twitter post about this. how signals has become like this word signals and has become this really popular idea maybe a couple months ago. I haven't heard too much about people talking about it, but where React is getting signals and the signals is kind of native to this other platform. And it's a better way of handling reactive state. And it has this kind of almost observability pattern to it. It's almost like an observable. And it's kind of been around for a long time. languages or frameworks and libraries. But Evan knew, well, this basically ref is essentially the same thing as a signal. We already have this built into view. And you can even recreate exactly how it's used in this other framework by doing it this way. So it's really nice that we already have this built in and we don't have to worry about state the way React does.

 

you actually have a video up here with Evan I'm looking at. I try to create a signals interview with Evan use help.

 

Yes, yes. Yeah, I did kind of deep dive into signals and took some inspiration from what he posted online. And I created something called Create Signal, uses shallow ref to do it, which is analogous to what signals are in these other languages. And then I did it again using Solid. So I showed how Solid uses Create Signal. and how it's really similar to View's ref. So yeah, if anybody's interested in that, yeah, check out my channel program with Eric or eric.video.

 

Excellent. Alright, so we're getting low on time, so first we'll thank Eric for sharing his wisdom with us yet again, and experience, and his videos. Like he said, Program with Eric, E-R-I-K by the way, on YouTube or erik.video. It's where you can find all his goods, and I'll drop some links to those videos in the show notes for this particular episode.

 

Sounds good.

 

Alright, so let's move on to picks. Picks are part of the show where we got to talk about whatever we want, within reason of course. Not by delaying any FCC rules or anything. But I got a couple picks today before I get to what is widely considered the high point of any episode of mine, which is the dad jokes of the week.

 

Okay.

 

First of all, did some flying this last week and went to Chicago. And on the way, I watched a video and, excuse me, a movie for a movie. And the one I watched was 1917, which is really a cool movie. It takes place during World War I. And the premise is that it talks about the communications where one unit had to be The British Army, I believe, had to be, let it know that they shouldn't do an attack because it was a trap by the Germans and they didn't want everybody to get slaughtered and so they sent two guys. Think it's about a day's journey to get to this unit. But what was cool about the movie is that the way they filmed it and that instead of, you know, it's a typical movie where you jump around in different camera angles and you're changing who's being viewed. The camera follows these two guys, or at least two for as long as both are in the movie. Spoiler alert. are, it just follows them all time. It never takes your eyes off both the characters, the main character. It was really unique at the time. And if I remember right, it won a number of awards. Okay.

 

Wait, what happens if they left? Did they ever like leave each other?

 

Well, it's been a few years so I guess I can can

 

Now don't spoil it, but-

 

oh Say both of them didn't make it to the end. Let's put it that way

 

I know,

 

and

 

but if you're like, if the camera's on both of them at the same time, don't they ever like, when I ask you the bathroom and the other one's like sitting on the...

 

Oh come on, this is the movies. They don't talk about that kind of stuff. You gotta remember in the movies, people don't get cold or hot. They don't, you know, they don't go to the bathroom. Anyway. So...

 

I'll have to check it out. I've heard good things, yeah.

 

Yeah, it's a good movie. But the problem is, like most... Like most movies that I watch on the plane, a lot of times I'll start too late. And so the plane will land before I'm done.

 

Ah!

 

And so then when I go to find it, I can't. I got to pay for it and rent for it and it's too cheap. Like I've never seen the end of The Lincoln Lawyer, you know, with

 

Ha

 

Matthew

 

ha ha.

 

McConaughey, because I saw it on a plane that I can't find it anywhere, like Netflix or Amazon or anything. So I might have to just quit being cheap in spring to pay for this one just so I can watch it. And then a geekier note, so an interesting article on Hacker News Today about, oh my gosh, I just didn't lose it. I think I killed it. It's about import maps being available in all browsers now, which is more of a, you know, when you're importing modules like ES6 type of functionality in Vite versus, you know, your front end code. But it seemed to be sort of a big deal. And the guy did a pretty good description of what they are and how you'd use them. Here we go. JavaScript import maps are now supported across browser on web.dev by Thomas Steiner. So. I'll drop a link to that in the show notes. And then for the dad jokes of the week, I gotta get my sound effects

 

Wait,

 

here.

 

do I get to go with my own

 

Yeah,

 

picker?

 

okay. Well, we wouldn't dream of leaving yet, but we saved the best for last. So that's why,

 

No, please, I'd like to hear the dad joke.

 

so, oh, for sure. We wouldn't dream of not letting the guests have their jokes. So I was in the library not too long ago and I asked the librarian, if they had any books on different noise levels. And she said, sure, what volume would you like? Simple question, what is a pirate's, you know, there's pirate jokes are everywhere But what's a pirate's least favorite letter? And not letter

 

R?

 

in the alphabet a letter that they get in the mail The letter is dear sir We're hereby summon you to court for a hearing related to the illegal downloading and proliferation of the following copyrighted media All right,

 

Ah.

 

that kind of pirate, right and then I Was working on a crossword puzzle the other day and I was having trouble once. So I asked my wife, I said, hey, can you help me? The clue for this one item is overworked postman. And she said, sure, how many letters? I said, I'm guessing too many. Alright,

 

Pretty good.

 

yes, so those are the dad jokes of the week. Alright, Eric, your turn. Picks, what do you got for

 

Yes,

 

us?

 

I have one. I've been, have you seen, I think I'll ask you Steve, have you seen Blue Sky?

 

Let me look at my window. No, it's cloudy right

 

Oh,

 

now.

 

oh, okay, yeah.

 

Oh, I have, now that I think, I have been seeing that all the rage about that. I think I've saw, you had to have an invite or something like that sort of Google style ways of doing it. And I've applied for one, but I haven't been given one. And it sounds like it's a social media, some sort of thing. Yeah, what is it?

 

Yeah, so Twitter, love it or hate it. It's pretty much the defacto community, probably one of the biggest social media communities for developers out there. And definitely not perfect, has its pros and cons. But... The recently, you know, Mastodon was another kind of Twitter kind of clone that came out open source that came out a few months ago, especially when Elon took over Twitter. A lot of people decided to check that out. But Jack Dorsey, the creator, one of the co-founders of Twitter actually was not the first to actually did not create Twitter. He was a co-founder of it. He actually came on later, but everybody basically has co-founder status. created Blue Sky Social, which is like a, they call it a decentralized social network protocol. And it's spun out by Twitter Inc. in 2019. It's hired its first employees in 2021. And it's essentially a very, very much clone, almost, of Twitter. It's in private beta now, so everybody who wants to get into it. Everybody's getting FOMO. Everybody's getting the fear of missing out on it because they're only handing out a certain amount of invites a week and only power users who are using Blue Sky a lot. I guess they're not called tweets. I forgot they're called skeets or something. I think they have a different name. And it's all private, are getting invites and they're sending those out. So everybody on Twitter, especially with. with all the drama that's happened on there in the last six months, I've wanted to get into Blue Sky and I've luckily, I have gotten one. And I tried, I've been trying out for the last week and it's pretty neat. I haven't seen too many differences between Twitter and Blue Sky so far. One kind of, I guess, unique thing is your Twitter profile. You know, mine's erikch, Ericch, but you can have it be your domain name. So if your domain is like, I don't know, like programwitheric.com, I can have my name on blue sky be programwitheric.com. So some people have started doing that. A lot of big tech people in our industry have already on there. I've seen a lot of really amazing developers on there. So it has a very techie feel to it, techie vibe right now. And that's... That's pretty interesting too. So I'm a kind of wait and see attitude. I'm going to use it at the same time, but I'm not giving up on Twitter. I'm not sure if it'll, what'll happen. I think they're going to continue like sending out invites and hopefully eventually it'll be like public. But right now it's that. And right now it's only on your phone. I think you can get the desktop app. I think there's a link to it, but it's not quite ready yet.

 

So it's not like a web app like you can go to twitter.com.

 

No, I think everybody is using it on their mobile phones right now. at least as

 

Speaking

 

of this

 

of

 

recording.

 

invites, do you have one you can pass my way?

 

I have not been granted any. So like

 

Oh, okay.

 

when you log into Blue Sky and you create your account for the first time on your profile page, it'll tell you how many invites you have and everybody starts with zero. And then I hear, I think this is the way it works. I think the more you use the service, they'll give you more invites. I've only put out a few tweets. on blue sky, I'm just gonna call them tweets. So I haven't gone that far. One thing I don't love about jumping into another social, into social media or another, these services is now I have to like start over again. So like, now I have to like, I'm back to zero followers and I have to kind of work on it, which is kind of bad. But I do like how like geeky the community is. It's very developer friendly, developer focused right now. It's starting to branch out, like they're starting to get like some celebrities and. like AOC joined last week and so it'll be interesting. We'll see how it goes. If people will start using it or if it'll catch on some momentum.

 

Yeah, we'll see. Is it now, is it centralized, but decentralized? Like the whole thing with Mastodon, right, is you could start your own servers and it's sort of different groups as compared to one big giant central network, sort of like Twitter is. I think you mentioned it was decentralized. How does that work with Blue Sky? Or what makes it unique other than just being a different app?

 

I don't know how the decentralization works. I know it has an API and has this social protocol. I'm wondering if the architecture is decentralized somehow. I don't think it's to the point. Mastodon, you can literally create your own Mastodon server, and then it would connect to other Mastodon servers. I think this is pretty private to Blue Sky, but maybe the architecture is decentralized. Maybe it's cheaper to run. I don't know.

 

Interesting, interesting. Yeah, I've been curious to check it out. I applied for an invite, so who knows if I'll ever get one. If anybody out there listening and wants to send one my way, wonder95 at Twitter. Happy to take one just to check it out for sure. All righty. So with that, we will wrap it up. We've been talking for a while, as always happens. It's pretty rare that I start talking and run too short. That's for sure.

 

Yep.

 

So with that, we will say goodbye. Thank you to Eric for coming on and enlightening us. And good times. So we will talk to you all next time on Views on View.