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