Vue Architecture Q&A

[00:00:00]
>> So one of the questions that was asked is regarding using RX JS with review. And so I know that Natalia Tahina, who's on the core team, I think, has done a decent amount of work with RX JS and so there's nothing As like, to my knowledge, there's nothing wrong with using RFCs in view and it can be super useful for tracking.

[00:00:21]
Like, especially when we're having the, sort of the queue that RSGS allows you to easily track it, break like event loops and those sorts of things. And I've seen people use it with a success, but I know personally in my own projects, I haven't had a need for it, just yet, but.

[00:00:37]
I would say, if there's anyone to reach out to if you have specific RxJS questions, I think Natalya would be a great person to start with, cuz I think she's done a decent amount of work with that. So the question is, when it comes to dealing with How do we deal with the authentication piece when it comes to routes?

[00:00:55]
And so for this, I'm going to go ahead and again this this resource I can't tell you is incredibly valuable for you to bookmark. So I'm gonna refer back to Chris's view enterprise boilerplate, because he has an example in here for just that. We're inside of our router.

[00:01:13]
If you look at believe this router dot j s, here we go. In here you'll see that he's actually before the route is actually resolved. He's actually going to check the Buick store to verify whether or not the user has been logged in or not. And then based on that, it will go ahead and then route them accordingly.

[00:01:37]
And so to, to answer your question, basically, yeah, it's basically a bit like the, before each concept where you're gonna go ahead and prior to loading the view. You're gonna go ahead and check and make sure that these things exists, whether it's a token or whatnot. And so you'll see here that he has this meta property on his routes.

[00:01:56]
And so different routes, for example, require off true. And so if it has this off true, then it actually goes ahead and like runs its checks. And so as far as a design pattern goes, I'd recommend if you're architecting your Routes from scratch and you're looking for a good pattern to model after for how to model authentication with routes.

[00:02:16]
Be sure to check out the enterprise boilerplate for Chris's model for how he does this. And so also as a little bit of context, the view enterprise boilerplate is basically a compendium of best practices. That Chris has basically come up with over the years as he consulted on apps of various sizes.

[00:02:37]
And what he's basically done is open source this and a lot of his ideas to basically share with the community. And so you basically are like, if you had a consultant, you have to hire to learn these best practices, like. Chris basically just put this all in a repo and made it open source.

[00:02:52]
So it's an incredibly valuable resource that you should definitely bookmark. And as time goes on, as I mentioned, we will be creating a v3 version of this But again, the the core concepts in here are incredibly valuable and definitely keep an eye on it. So the question here is regarding how do we like what is a way to go about documenting components right in terms of props and those sorta things.

[00:03:17]
And so there are two main contenders in this space that are worth keeping an eye on. So first of which is the view style guide. This This is modeled after the react one. And basically it allows you to create a living style guide to document your components. And so, check out this tool for sure for seeing how the.

[00:03:41]
How you might document components using style guide this, but the other one that is of course worth mentioning, which some of you may be thinking of is storybook. And so storybook does have a view extension. And so I think this one is a little bit easier to demo but you can see here that let me do story book demo.

[00:04:08]
[SOUND] Let's see. Examples storybooks, okay. Official storybook UI. Great. So for those who haven't used storybook before, what it does it allows you and to be honest, your documentation towards you kinda want a similar impact is allow you to explore your different components and then basically look through and see what exactly like how everything's built.

[00:04:31]
Knobs, controls, so you can see here in this case if this word like the view equivalent for example may be what props that are being passed in and these sort of things and then you can actually see it being rendered on the screen. So this is actually a little bit similar to the Cypress demo that I did earlier where I think having that visual feedback to see how something works and play with it on top of simply reading it can be a huge boost when it comes to that developer experience.

[00:04:59]
And as you can see here that the documentation here page even has like a preview of it. It has what is expected to be passed and then different in this case they call them stories. So different call it scenarios that the component might be put under. So it's a storybook view style guide.

[00:05:14]
This are the best place to get started for that. But I would say on the topic of documentation, if you're looking for a way to create internal documentation, or even documentation for your site over time. The tool I would recommend, if you haven't heard of it yet, is view press.

[00:05:33]
And so what this basically is, is it's a static site generator built with a view that can then exist inside of your code repo. And so the reason why I think this is incredibly powerful is because what you end up getting is the ability to pair documentation with code updates.

[00:05:50]
And that's a really big thing when you think of like, again, we were talking about like implementing like conventions that are easy to follow. It's a lot easier for a developer to pare like, they updated the parameter name for this API. So just go ahead and submit that as part of the pull request, rather than issuing a pull request for the update, and then go into a separate repo.

[00:06:09]
And that's assuming it's even in our repo To then go ahead and update that as well. So if your press was basically designed as like a static site generator that can exist side by side with code bases and so this is definitely a tool worth checking out if you haven't before.

[00:06:25]
Basically write everything in markdown and on top of that you can even import view components inside of your Markdown. So you can have like three dynamic aspects of it, which is really cool. And so the other tool I definitely must mention though, for those who are using knucks is next content.

[00:06:43]
And so they have their own dachstein for example, so in this case, it's like similar to view press but they have like sort of like their own development branch. And so I know that the two teams are actively learning from each other and it's great to have them here.

[00:06:56]
So yeah, they can see they have this beautiful dark theme. And like pioneer this sort of code block thing that you press shamelessly copied because it was an awesome idea. So credit to the next team for making this a standard. And so yeah, as you can see, like the other right bar, automatic generation of headings like, so, yeah.

[00:07:18]
So going forward, as you're looking at docs, so to clarify, so these are good for like writing out your documentation. But to clarify the first question, the reason why StoryBookand like view style guide, this are better tools for component documentation is because that's when you're documenting within the components themselves and they're basically automatically being generated.

[00:07:39]
Whereas at this level, this is more about sort of like the writing and there's more yeah, basically there's more writing and content that's dealt with this and a little bit less automation. So another thing you couldn't automate some of those pieces into this, but as far as like out of the box goes, like storybook and style guide, just do a better job of out of the box.

[00:07:57]
And then if you press next content our next docs team are good for like out of the box like doc sites. So another question that's being asked is regarding the view x state modules, right? So we talked about to sort of remind everyone, we had the shopping cart module in our view a storm we had like a to-do list for example.

[00:08:13]
And the question is regarding communication between the store modules and whether or not this is a good practice long-term and whether or not there are any patterns that really help to avoid tight coupling when working with complex store architecture. And so when it comes to something like communicating data between stores, I would say that over time, if you're noticing that you're doing this a lot, this is probably either an indication like this is where the data driven refactoring kind of comes in a bit.

[00:08:42]
Because it's like at this point, you're doing so much communication between the two modules that it's almost worth considering, is there actually a module that should be centralizing all of this together in one place, instead of them talking back and forth? And so, as far as like patents, so there's nothing inherently, so what I'm saying here is, as far as the first part of the question, there's nothing inherently wrong with communicating it back and forth.

[00:09:06]
It just over time, you might just start to notice different patterns and trends that allow you to create like call it a third store third module that then sort of houses those things in one place so that it's easier to maintain. Granted like this actually kind of relates to the second part of the question where you're saying that this end up like any patterns avoid tight coupling, so certainly if we refactor this communication piece into one you get a tight coupling.

[00:09:31]
But I would say that tight coupling is not inherently a bad thing when it comes to designing architecture patterns. Because as long as you're being explicit and in again, using data driven refactoring, you have the data to prove that it's worth keeping that coupling, there's nothing wrong, like I wouldn't say you need to avoid this by any means.

[00:09:50]
The only time the tightly coupling I would say that, that sort to become a negative thing is when it becomes very difficult to split something up. And so that's why I say that like early on when you don't know how exactly the flow of data is going to happen or you're still getting that that sense of how the architecture is working as a whole.

[00:10:11]
Keep things as atomic and isolated as humanly possible, because that will then enable you to make the right choices to put them together and then start bundling them as you're like. Yes, this makes a lot of sense to put together. And so when it comes to state management, I would say it's the bottom up approach is to start with small pieces and then assemble them into a bigger one.

[00:10:34]
On the other hand, and just this is related so just you have the mental model when it comes to components, I tend to recommend the opposite way. Which is like just build the thing, make it work, right? And then once you have it working, then split it off and don't get me wrong like with experience you'll probably built like break things off in advance.

[00:10:53]
What I'm saying with component architecture is you don't need to sit there and think like how small should I go for this component like I would say, just build it, make it work. And then you can kind of have those discussions the other way because components have that reverse effect where when you see everything in tandem and you see how they connect, it's easier to refactor out the shared pieces.

[00:11:13]
Whereas with shared state where you have a lot of things, relying on it. That's the opposite thing where if you have too many things tightly coupled to it, then you're going to end up with the effect of like, we shouldn't have coupled that at the beginning. So, hopefully that helps answer your question.

[00:11:28]
If not, please feel free to add more context and I'm happy to give more sort of embellish the answer. So another question here we have is are there any examples of app or sites that have implemented the view enterprise boilerplate for a complete app? And I can say with absolute certainty, there are a ton that have actually done this.

[00:11:55]
So what probably should ask Chris is to see which companies are willing to go public with that information. But generally speaking, I'm I know a ton of developers who have basically taken Chris's his enterprise boilerplate and have forked it and then gone ahead then create their own version of it.

[00:12:15]
And so that's, I think the key thing to this question is that it's not so much that like there are apps that call it, like there's no signature in an app that would immediately say, that's Chris's view enterprise boiler plate. Over time, as he's shared his knowledge, people have taken the pieces that made the most sense to them.

[00:12:35]
And basically like bundled it themselves. And so, I mean, I know that basically any client he's had has basically used, his boiler plate as the base thing that they started off of and so given that his full-time role as a view consultant, we can imagine there are many many successful companies who have done so.

[00:12:52]
And so yeah, in the future, what I'll try to do for this question is, I'll see if any of these companies are like willing to go call it on the record so that on the GitHub repo going forward, if you're looking for call it reasons to use it, then you can go ahead and sort of use that as like, ways to say that, hey, all these other companies also use the enterprise boilerplate.

[00:13:16]
But otherwise, as a whole, I really would recommend thinking of the enterprise boilerplate just more of a collection of opinionated practices that you can use to just beef up your own knowledge because, as we mentioned, like the enterprise boilerplate on its own doesn't represent like the perfect app.

[00:13:31]
What it does is represent a lot of different ideas that is worse than the time to tease apart and understand, like why the decisions were made, or that certain techniques do exist for handling things a certain way. If you approach the enterprise boilerplate that way, I think you'll find it to be super valuable for, you know, building your own apps.

[00:13:50]
Okay, so the question here is regarding when we're building applications with TypeScript, whether or not to use class components and to use them with decorators on top of that. And so I'll be the first to say that like my exposure to the TypeScript realm with view is still limited as far as like exploring sort of like the depths of what types of is capable of.

[00:14:15]
And so what I would say though, about generally speaking, when using things like decorators in like the class components is that we saw this happen in other ecosystems where, because decorators doesn't have full native support, from what I understand so far, and that it's still like in an experimental phase, this in some ways you can, how do I say this?

[00:14:39]
So when it comes to decorators and API's that are still in the experimental phase, this can be a little bit tricky to use on an enterprise scale. Because this means that is in the future The class component API needs to deprecate it. You've kind of invested in, in an ecosystem that now you need to change everything.

[00:14:59]
And so for me, when I'm thinking of enterprise grade level apps, I tend to veer away from the sort of non spec features for this very reason, because I wanna make sure that if someone's gonna spend the time to learn the thing, that one is gonna stick around and two that later on if we enforce this convention, it won't be really difficult because I think part of it is with things like decorators.

[00:15:21]
There's not necessarily a clear path to what the alternative might be. Whereas for example, the reason why I recommend for people going from like JavaScript to TypeScript to start with, like Just start with JS Doc's comment is because those are very easy to wipe out. They won't impact your code.

[00:15:35]
But something like decorators, especially if you're counting on them working a certain way to enhance your individual class components. That can be a little bit tricky if something changes architecturally with that technique. There's a question regarding where defining data inside view components. Especially when you're designing it inside of the data, function that has a data store object.

[00:15:56]
Traditionally all of these things are made reactive. And so, one of the questions here is like, what happens when we wanna actually, define things that are actually static? Because currently everything is made reactive basically immediately. In those cases, what I actually recommend is using in this case cause I'm assuming you're, well, let's look with the view three piece.

[00:16:19]
In view three composition API is actually perfect for this because you can basically share this piece with everyone and then import it and then have it create, and then it will never change, right? No one will accidentally update This static piece from the composition API because you've already said I don't want it to be reactive.

[00:16:39]
It's just a variable that contains the string or a string that's generated at runtime, what not and then after that, it doesn't change anymore. So I think that's the approach I would take with view three. And with view to certainly if you're not adding the composition API plugin into your app, then certainly you can go Yeah, it's a little bit trickier without that, and this is one of those things.

[00:17:03]
So, theoretically then.yeah thinking hard about this, removing reactivity from a property, would be fairly tricky. The only thing I can maybe think of, I got an answer.If you have something that's static, let's say you needed to stick around the page, but you don't wanna be part of the reactive store.

[00:17:29]
One of the things I've seen people do, especially when, especially these static things are usually generated at runtime or bill time. Sorry, at bill time. So on the server side, you can basically think of it like you can expose global concepts. For example, this is one way that I've seen, I've actually done this on production.

[00:17:49]
Where we have the backend expose something. Again, we're assuming here that this is something that can be public, it's okay that someone can see it. Then once they put that as part of the HTML, inside of your mounted hook, right, you can imagine on your component Go ahead and like, just like traditional Java script, go ahead and fetch out, fetch that element and pull that and basically pull that variable in.

[00:18:10]
Or in the event you have more control over what's rendered on the server, have index, whatever that index, that HTML file is, make sure that exposes like the static variable in the global state and that's a way of escaping sort of views of activity. But from what I've heard so far regarding the composition API plugin, it has been fairly stable for people in production.

[00:18:32]
So if you're using it for something as simple as sharing static properties between components, I don't see any reason why you shouldn't just go ahead and use the plugin and do that directly. But in the event that for whatever reason, your team wants to avoid having that additional payload.

[00:18:46]
That is one way you can sort of skirt the system as far as having reactivity tract. So lemme know if that doesn't answer your question, but that's how I would approach having static data shared across components instead of you.