Welcome to the deep dive. Today, we're tackling modern web development by zeroing in on Maya Chavin's Learning View.
Right. It's a great resource.
We've sifted through a lot here preface chapters one, three, thirteen, basically the whole thing pretty much, and our goal is to pull out the essential insights, help you grasp why VJs is, you know, such a major player.
Today, Yeah, and get a solid handle on its core principles exactly.
So, if you're looking to quickly understand a leading front end framework, especially View, well, this is your shortcut.
Think of it as a focused tour through the heart of VIEWJS, using Shavin's book as our guide.
We'll cover everything from setting things up.
To advanced rendering, testing, the whole life cycle.
Really, it's about understanding the well, the elegance and power view brings precisely. Okay, let's unpack this. Then Shavin kicks things off by highlighting why learning a framework like view is just so vital.
Now.
It's not just hype, No, it directly impacts you know, product quality, development, cost, coding standards.
Even just making development easier, right.
Totally for anyone in web deev front end full stack knowing a framework like View it's becoming kind of crucial.
That's a really key point. And views rapid growth, especially back around what twenty eighteen, that really shows its strengths.
It's known for being approachable but also adaptable.
Exactly, it's a user friendly, but you can build serious stuff with it. We're talking scalable, interactive web apps that actually perform well.
And Chavin mentions the documentation Apparently it's exceptionally good.
Oh yeah, that's a huge plus. Well written, easy to follow, makes a big difference when you're.
Learning what's the ecosystem. Tools like view router for navigation, Pazina for state management, they help streamline setup.
Definitely, having those solid official tools ready to go simplifies things a lot.
Okay, now this is interesting, Chavine says, if you've used older tech like Angular JS or like even jQuery, use API's might feel kind of familiar.
That makes sense. There's a lineage there in some way.
And the template syntax is designed to be easier for handling data and dom events.
Yeah, lowers that barrier to entry. View manages to blend that ease of getting started with some really robust capabilities underneath.
So clear epis straightforward. Templates get you going quickly.
But the underlying design lets you build complex things, and that strong ecosystem, like we said, makes a huge difference.
Okay, so you're sold on View, Where do you actually start? Let's talk setup. Shavin says, NOJS first, right.
Got to have NOE installing It gives you the node command itself and also.
MPM, NPM the node package manager. You can check your version node V.
In the terminal node V easy check.
And NPM is how you grab packages like View itself exactly.
It manages all those external libraries your project depends on. You check its version with NPMV.
And keep it updated with NPM. Install NPM at latest G.
That mash G is for global right mm hmm makes it available everywhere on your system. Think of NPM like, well, it stops you having to manually find and download every single piece of code you need. It handles the dependencies.
Avoids dependency hell as they say.
Pretty much, Yeah, keeps things organized.
Chavin also mentions yarn though another package manager.
Yeah, it's an alternative to NPM. The book uses yarn for examples, actually.
So you'd check with yarns get a packages with yarn ad and install everything for a project with just yarn.
Right, it shows the flexibility you know mpm's default yarn is Another popular choice point is you need a package manager?
Gotcha? Okay? Note installed package manager ready? What about actually like building the view project?
So the community is largely shifted now away from the old view CLI which used Webpack, towards Vite exactly. Vite is the default now it's fast.
And how do you start a new project with it?
Super simple? Command NPM and itview at latest.
NPM in it view at latest.
Okah, that runs create view, which is the official tool. It asks you a few questions, sets up the basic project structure for you.
Why the shift to vite. What makes it faster?
Well? It leverages native es modules in the browser during development, so instead of budling everything.
Up front like webpac often does.
Right, vites are of code pieces as the browser requests them. Much faster startup, much quicker updates when you change code. Big win for developers.
Makes sense. Okay, project set up done? Now? Performance? You mentioned view as performance Chavine talks about the virtual dom.
Ah, yes, the virtual dom. This is key.
So the browser makes this thing called the dom from HTML right a tree structure.
Yep, and changing that real dom directly, especially often to slow It forces the browser to.
Repaint, which is expensive computationally.
Speaking, exactly, especially on complex pages with lots of updates. Older frameworks sometimes struggled there.
So View's solution is this virtual dom, which is what exactly a JavaScript object basically.
Yes, it's a lightweight JavaScript representation like a blueprint of the actual dom v nodes virtual nodes.
Okay, So when data changes in your view app, View.
Updates this virtual dom first, which is super fast, just changing JavaScript objects in memory.
And then it figures out the best way to update.
The real dom precisely. It calculates the minimum necessary changes and applies them in batches, like editing a draft before finalizing the master copy.
So it does a bit more work upfront in JavaScript.
To avoid the much costly er direct dom manipulation.
That's the trade off, and that's why view feel smooth, especially with frequent updates.
That's a huge part of it. Fewer expensive repaints mean a more responseive UI.
Okay, cool, So how does a U app actually start? Chavin mentions a root instance.
Yeah, every view app has a root component instance it's the foundation.
And other components are nested inside it.
And the whole app gets mounted attached to a specific HTML element, often a div with eight app you use app do mount hashtag app.
And configuring these components. The main way is the options API.
That's one of the core ways. Yes, it's basically a JavaScript object with different properties or options that define the component's behavior.
Let's break down some key options.
First, data right, Data is a function. Importantly, it returns an object.
And that object holds the components reactive data exactly.
Reactive means when these properties change, View knows and it automatically updates the parts of the UI.
That use them, and you use them in the template with double curly braces.
Yep, property name. That's one way data binding data flows from the component to the template.
Shaven recommends the viewdev Tools extension here.
Oh absolutely essential. Lets you inspect even edit that reactive data live in your browser. Great for debugging and understanding what's happening.
Okay. Then there's v model that's for two way binding.
Correct. It creates a direct link between say, an input field and a data property.
So user types in the input data updates you change the data incode input updates.
Exactly, super common for forms, and it has modifiers like dot trim to remove white.
Space, lazy to update on on blur not every keystroke.
And dot number to try and cast the input to a number. Handy shortcuts.
What about just binding data to HTML attributes.
One way that's v bind or the shorthand just to colon.
So like ming dot src imager.
Decisely binds the image of data property to the src attribute. You can bind almost any attribute.
And Shavin says you can bind a whole object.
Yeah, like die dot index, dot index, dot index. If the object keys match attribute names, view applies them neat and.
You can use the colon for dot class in dot style too. For dynamic styling.
Definitely, you can bind dot class to an object where keys are class names and values are booleans, or to an array of class names. Same idea for dot style binding to an object of CSS properties. Very flexible.
Okay, what about lists rendering rays of things.
That's the V for directive. You put it on the element you want to.
Repeat like leaf V for iteman items exactly.
It loops over the items array or object properties and live for each one and.
The crucial thing here is the dot key attribute.
Absolutely trucal live for item and items key item, dot ID, you need to give each item a unique key.
Why is that so important?
It helps view track each element efficiently. When the list changes items added, removed, reordered, View uses the key to figure out the minimal updates needed. Without keys, it might have to rerender much more, which hurts performance.
Gotcha keys are essential for list performance now handling user actions like clicks.
That's v on or the shorthand at say so, at click, do something.
Attaches an event. Listener calls a method in your component do something in this case yep.
Or you can put simple inline JavaScript expressions right there like at click count plus plus meg. But for anything, complex methods are.
Better, and ven O's modifiers too, like stop and dot prevent.
Right at click. Dot stop prevents the event bubbling up the dom. At click, dot prevent stops the browser's default action, like preventing form submission.
There are others too, self not wants.
Dot capture Yeah, dot self means the event must originate on this specific element, not bubble up from a child. Johns makes the listener fire only one time. Dot capture uses the capture phase of event handling, which is less common but sometimes.
Useful, and specific key modifiers like at keydown dot enter super handy.
Instead of checking event dot key coode, you just use a key doown dot enter or at keyp dot shift. Much cleaner.
You can chain them like at keydown dot ctrl dot enter.
You can, though shaven notes using key coodes like part one three for enter might be more reliable for complex chaining than keynames sometimes, and there's dot exact for requiring only the specified modifiers. Okay.
Last directive in this group conditional rendering showing hiding elements right.
V IF, VLSIF and VLS e if takes an expression.
If it's truth y, the element is rendered exactly.
If it's false, the element isn't just hidden, it's completely removed from the dom.
And VLS must follow via.
Or vlsif it renders if the preceding VF or vlsf was false allows you to change conditions.
So VF actually at removes elements, unlike just using CSS display right.
None correct, it's true conditional rendering, not just toggling visibility. Right.
Okay, Moving on, let's talk component life cycle. Components have stages.
Right, They do from creation to destruction and view gives you hooks functions you can define to run code at specific points in that.
Cycle, like what what are some key hooks?
Well, early on you have before creating, created, then before mountain mounted, just before and after it's added.
To the down mounted sounds useful, like for fetching data.
Exactly common use case. Then when data changes and the component updates, you get before.
Update and updated, and when it's removed.
For unmounted unmounted Yeah, good for cleanup, like clearing timers or removing manual event listeners you might have added.
You mentioned the composition API earlier, Shavin talks about a setup hook related to that.
Yes, setup is the entry point for the composition API. It actually runs before four before create and create it.
And the script setup syntax kind of hides that complexity, right.
Script setup handles the setup part implicitly, making it more concise. The setup function gets props and a contact object. What's in the context useful stuff access to attributes passed to the component slots which let you pass markup into the component, and the emit function for sending events up to the parent.
And you can use set up with render functions too. For really low level control you can.
Yeah, if you need very dynamic rendering logic where templates get awkward, setup can return render function using the h function to create v nodes programmatically.
Okay, now, derived data. What if one piece of data depends on another.
That's what computed properties are for. You use the computed option and these are cased. Yes, that's the key benefit. A computed property only recalculates its value if one of the reactive properties depends on changes. Otherwise, it just returns the cached value. Very efficient for complex calculations.
But what if you need to do something else when data changes, like not just calculative value, but run some code, an API call.
That's where watchers come in the watch.
Option, so you watch a specific data property and.
Provide a callback function that runs whenever that property changes.
It's for side effects, and you have options like deep for watching inside objects yep, deep.
True watches nested properties, and immediate true makes the watcher run once right away when the component is created, not just unchanges makes sense.
Okay. Communication between components. How does a parent talk to a.
Child primarily through props? Props are like custom attributes.
You passed down using v bind or the cull in shorthand like child component message parent.
Data exactly, and the child component has to declare the props it expects using the props option.
Or define crops in script setup.
Right, you can specify types for props, make them required, give them default values. It's a clear contract.
How does the child talk back to the parent.
By emitting custom events? The child calls this emit event name optional pay load in the options API.
Or uses the emit function from setup or define up in script setup, and.
The parent listens for that event using v on or at on the child component tag like child component at event name, handle event.
Okay, props down events up. What if components are nested really deep? Passing drops through many levels sounds tedious?
It can be. That's where provide an inject come in a great inject Yeah, a parent or ancestor component can provide some data or functionality.
And any descendant component, no matter how deep, can inject.
It exactly bypasses all the intermediate components. Great for global things like user authentication, status or theme settings.
Cool. And one more thing here, teleport what's that?
Telecord is neat It lets you render a part of your component's template somewhere else of the dom entirely.
Like outside the component's normal place.
Right. Think modals or pop up notifications. You might want them rendered directly under the body tag to avoid CSSZ index issues or clipping from parent elements.
So you use teleport to hashtag modal, target or something.
Actly. You specify the target selector using the two problems.
All right, let's circle back to the composition API. Chavin covers it extensively. It's an alternative way to organize component logic.
Yes using functions. The core ideas are ref and reactive.
For a primitive values like strings or numbers.
Generally yes, or when you need to potentially reassign the whole thing. It wraps the value in an object and you access it using dot value, So my.
Ref dot value to get or set the value.
Correct and reactive is for objects or rays. It makes the object itself reactive.
So you just modify properties directly on the reactive object.
Yep, my reactive object dot property, new value, view tracks.
It and computed properties and watchers exist in the composition API two.
They do you import and use computed and watch or watch effect functions.
The real power seems to be incomposables. What are those?
Composables are reusable pieces of logic built with composition API functions. Think of them as custom hooks like in React, but for View.
So you extract stateful logic.
Into a function exactly like you could create a use mouse position composable that tracks the mouse coordinates using ref internally.
And then reuse that use mouse position logic in any component that needs it precisely.
It makes your code much more organized, reusable, and testable. A use fetch composable for API calls is another classic.
Example that sounds powerful. Okay, shifting gears to more advanced rendering render functions.
Right, we touched on this. Using the H function directly to create vnodes gives you full programmatic control over the output. Good for highly dynamic.
Stuff, and JSX is an alternative syntax for that.
Yeah, it's like writing HTML inside your JavaScript. Some people, especially from a React background, prefer it over templates.
View supports it dynamic components.
What's the use case using component dot is component name variable. You can switch which component gets rendered in a particular spot just by changing the value of component name variable. Think tabs or different views based on user.
Selection and plugins adding global stuff.
YEP plugins let you add global components, methods, or integrate libraries like view router or Plena into your whole application via app dot use Mike Luggins.
Speaking of view Router, that's for single page apps right handling navigation exactly.
It's the official router. It maps URL paths to your view components.
So about shows the about component, Users shows the user's component.
Pretty much. You define those mappings.
You use router view as the placeholder where the match component appears.
Correct Router views where the content changes based on.
The URL, and Router link for a navigation instead of regular autags.
Yes, routerlink to about creates the link and handles the navigation without a full page reload. Keeps it feeling like an app.
Does it handle dynamic parts in the URL like users one two three, Oh.
Yeah, dynamic routes, users, dot ID, nested routes like having subviews within a user profile, route guards for controlling access. It's very cabable.
Okay. State management for data shared across many components. You mentioned Pinia, Yes.
Pinia is the official recommended state management library, now replaced fux.
It uses stores right.
You define stores to hold specific pieces of your application state.
What's inside a store typically.
State, the actual data usually return from a function, getters like computed properties for the store, and actions methods for changing the state.
And it's built with the composition API in mind.
Very much. So you define stores with define store and access them in components using a composable like function.
Conventionally use my store and something called store terrefs ah.
Yeah. If you want to destructure state properties or getters from a store in your component, storage threats keeps them reactive, Otherwise you might lose reactivity if you just pull them out directly.
Got it. Styling components, how do you avoid CSS conflicts between components?
The easiest way is style scoped. Just add the scope attribute to your style tech.
And view automatically makes those styles only apply to that component.
Yep. Under the hood, it adds unique data attributes data v something to your component's elements and scopes the CSS selectors to match. Prevents styles leaking out or in what.
About CSS modules style module.
That's another scoping mechanism. It generates unique class names for your styles like BUTTONBC one, two, three, and make them available in your template via a special style object, so you'd write dot class styled dot. My button class offers very strong isolation.
Cool now making things look nice when they appear or disappear.
Transitions Yeah, view has built in support with the transition component.
You wrap the element you want to animate, like one controlled by viv exactly.
Wrap the element or component in transition name fade.
And view adds CSS classes during the enter leave phases.
It does like fade in or from fade interactive, fade inner two and corresponding leave classes. You define the actual animation using CSS rules for these classes.
Can you customize the class names?
You can using props on transition and there are javascripts hooks at before, enter, at enter, et cetera. If you need more complex JS driven animations.
What about animating lists items added or removed from a V four For.
That, you use transition group. It's similar, but designed specifically for animating list elements, including move transitions when items are reordered. Remember the dot key attribute is vital here too.
Right keys again. Okay. Testing, got to make sure things work. Unit testing first, testing small pieces in isolation.
Yeah, testing individual components or composables, shaven highlights, vtist vitist integrates well with v exactly. It's fast and modern. You can figure it, invite dot config dot ts.
And you write tests using describe it expect standard.
Stuff, pretty standard testing syntax. Yes. A key thing in unit tests is mocking dependencies like API calls. Vitis has tools like via dots beyond for that.
How do you test composables, especially if they use life cycle hooks?
Often you need a little helper setup maybe creating a temporary component instance to mount the composable within its life cycle, using something like.
With setup and the view test utels library helps with interacting with components in tests.
Definitely, shall them ount or mount to render the component, find the select elements triggered to simulate clicks or input dot text that attributes to's the output to match snapshot.
For snapshot testing, Vitist has a UI too and code Coverage.
YEP, a graphical interface for running tests and tools like at vitis coverage is dan bull to see how much of your code is covered by tests. Good to aim for decent coverage.
Okay, that's unit tests. What about testing the whole app flow like a real user.
That's end to end or E two E testing. The book introduces playwright for this.
Playwright automates browsers.
Right, you write scripts that tell Playwright and go to this page, find this button, click it. Fill in this form, check if this text.
Appeared, simulating the user journey exactly.
You locate elements using selectors, CSS, text data tested attributes are good practice, and make consertions about the application state.
Does Playwright help with debugging?
Yeah? It has great debugging tools and produces nice hetmail reports showing test results, screenshots, even videos.
Sometimes automating all this building, testing, deploying.
That's CICD continuous integration, continuous deployment. Yes. Chavin covers using GitHub actions.
Getub actions, runs workflows defined in YAML files.
In your rebuff correct workflows have jobs, jobs, have steps, steps, run actions or scripts. You set it up so when you push code or open a poll request, it automatically builds, runs tests, and.
Maybe deploys if everything passes. That's the goal, CDEs, Where do you deploy chavin mentions? Netlphi.
Netlaphi is a popular choice for hosting modern web apps. It integrates really well with kit providers like GitHub.
So Netlify can watch your repository and automatically deploy on commits to Maine YEP.
It handles the build process, deploys to a global CDN, gives you custom domains, hgtps build previews for poll requests. Lots of features.
Okay, fine, A big topic. Server side rendering SSR and Static side generation SSG. Why bother with these instead of just client side rendering CSR.
Well, standard CSR where the browser downloads JavaScript and then builds the page can sometimes be slow on initial load users see a blank page for a bit, and it could be trickier for SEO crawlers.
So SSR helps with that.
How With SSR, the server runs your view code, renders the page to HTML, and sends that fully formed HTML to the browser.
First, so the user sees content much faster and SEO bots get HTML exactly.
The browser then hydrates the static HTML, making it interactive by attaching the JavaScript event listeners.
In state and SSG. Static Site Generation.
SSG takes it further. It pre renders every page of your site into static HTML files at build.
Time, so you just serve plane HTML files.
Basically, Yes, it's the fastest possible option and great for SEO ideal for sites where content doesn't change super frequently, like blogs or dogs.
Implementing SSR SSG in view sounds complex.
Though it can setting it up manually. That's why frameworks like nets dot as exist.
Nextjs builds on top of view to simplify SSR and SSG.
Massively simplifies it. Next handles routing based on your file structure in a page's directory, provides layouts built in data fetching methods for server side. It makes building SSR ssgview apps much more straightforward.
Wow, Okay, that was a lot. Let's try to recap this deep dive.
Yeah, definitely. So fundamentally, viewjs is this progressive, really versatile framework for modern web development.
It balances ease of use for getting started.
With really advanced features for building complex, production grade apps.
We went through setup, the performance boost from the virtual dome.
State management with Peona, routing with view router, testing strategies with vetist and Playwright, deployment workflows.
And the whole ecosystem around it vite nextjs. It's a comprehensive toolkit, it really is. And those aha moments, I think the efficiency of the VDOM is one.
Definitely, and just the clarity you get from the options API or the flexibility of the composition, API.
Composables for reuse.
This seems huge, absolutely, and just the overall streamline developer experience the ecosystem provides.
Hopefully this has given you a solid foundation and maybe spark some curiosity.
Yeah, you might be wondering, now, Okay, when exactly do I use SSR versus SSG? Yeah? Or how do I test really complex components or integrate View with my specific back end?
Lots of avenues for deeper exploration, for sure.
The official docks for View Router, Pinia, nuxt. They're excellent resources and the community is incredibly active and helpful.
So a final thought to leave you with. As web development keeps evolving so rapidly, frameworks like View really shared this constant push for better performance, the better developer experience, and.
Just more robust, scalable, and honestly more enjoyable web applications.
So how will these core ideas, component architecture, reactive, data, efficient rendering, How will they continue to shape the future of the web experiences we all use every day?
Something to think about, definitely something to think about.
Thanks for taking this deep dive with us,