Hey! I just wrote a comprehensive guide on redirecting in Nuxt. It turns out there are a lot of different ways to do this, depending on what you need done! You can read it on the Mastering Nuxt blog: How to Redirect in Nuxt (Every Single Way) In other news, Alex and I are continuing to put out new podcast episodes each week. Interviews with Daniel Roe and Evan You are coming up in the next couple weeks, so stay tuned for that! The next thing I'm working on is the Nuxt Tips Collection. I'm already at 64 tips and counting, almost all of them completely brand new for the book! Enjoy your tips, and enjoy the rest of your week! — Michael 🔥 Make Testing Easy Testing is important to do, but it can be hard to do. In my experience, good architecture lends itself to easy-to-write tests (or at least, easier-to-write). The inverse is also true, that difficult-to-write tests are typically a symptom of poor architecture. Of course, sometimes tests are just hard to write, and there's no way around it. The best thing we can do is borrow a tool from mathematics and science, and transform a difficult problem into an easier but equivalent one: - Humble Components — UI is notoriously hard to test, and always has been. So keep as much in Humble Components, components that only receive props and emit events and nothing else. By making our UI as simple as possible we also make it much easier to test.
- Extract logic to composables — And I mean all of your logic. Components (that aren't Humble) should only contain the bare minimum to connect all the different composables together. Think of them as Controller Components, the "C" in MVC.
- Composables are thin layers of reactivity — The easiest thing in the world to test are pure functions that have no dependencies. If you can make the majority of your codebase simple JS or TS code, you've already won. Composables then become simple wrappers that add a layer of reactivity to this business logic.
🔥 Destructuring in a v-for Did you know that you can destructure in a v-for? <li v-for="{ name, id } in users" :key="id" > </li>
It's more widely known that you can grab the index out of the v-for by using a tuple like this: <li v-for="(movie, index) in [ 'Lion King', 'Frozen', 'The Princess Bride' ]"> - </li>
When using an object you can also grab the key: <li v-for="(value, key) in { name: 'Lion King', released: 2019, director: 'Jon Favreau', }"> : </li>
It's also possible to combine these two methods, grabbing the key as well as the index of the property: <li v-for="(value, key, index) in { name: 'Lion King', released: 2019, director: 'Jon Favreau', }"> #. : </li>
🔥 Ref vs. Reactive Is it better to use ref or reactive when using the composition API? Here are a few situations where ref is better than reactive. Using ref on objects makes it clear where an object is reactive and where it's just a plain object: // I can expect this ref to update reactively if (burger.value.lettuce) { // ... } // I have no clue if this value is reactive if (burger.lettuce) { // ... }
When using one of the watch methods, refs are automatically unwrapped, so they're nicer to use: // Ref const refBurger = ref({ lettuce: true }); watch( // Not much, but it's a bit simpler to work with refBurger, () => console.log("The burger has changed"), { deep: true } ); // Reactive const reactiveBurger = reactive({ lettuce: true }); watch( reactiveBurger, () => console.log("The burger has changed"), );
One last reason why refs make more sense to me — you can put refs into a reactive object. This lets you compose reactive objects out of refs and still use the underlying refs directly: const lettuce = ref(true); const burger = reactive({ // The ref becomes a property of the reactive object lettuce, }); // We can watch the reactive object watchEffect(() => console.log(burger.lettuce)); // We can also watch the ref directly watch(lettuce, () => console.log("lettuce has changed")); setTimeout(() => { // Updating the ref directly will trigger both watchers // This will log: `false`, 'lettuce has changed' lettuce.value = false; }, 500);
🎙️ #012 — Geotastic, a Vue-based Browser Game (with Creator Eduard But) Today on DejaVue, Alex and Michael are joined by Game and Web Developer Eduard But, who created Geotastic - a Vue-based browser game revolving around geographical knowledge and uses Googles Maps and Streetview API! Starting with Edu's background in programming and web development and initial experiences with Vue.js, we dive deep into how it happened he got into Game Development, which multiplayer game he built first and why and eventually talk about Geotastic. With more than 1.5 Million registered users, Edu reveals details about the financial model, how he keeps things up and running, challenges while maintaining and which new game mode will come to Geotastic soon! Tune in to hear all of the above and more. Watch on YouTube or listen on your favourite podcast platform. Chapters: In case you missed them: 📜 12 Design Patterns in Vue Design patterns are incredibly useful in writing code that works well over the long run. They let us use proven solutions to problems that basically every single app has. But there isn't a lot written about how design patterns apply specifically to Vue. In this article, I cover 12 design patterns that I think are crucial to writing great Vue apps. Check it out here: 12 Design Patterns in Vue 📜 3 Kinds of Props in Vue One of Vue's core features is the use of props. Props are how we pass data around in Vue, from parent to child components. But not all props are created equal. There are three main kinds: - Template Props
- Configuration Props
- State Props (or Data Props).
Check it out here: 3 Kinds of Props in Vue 📅 Upcoming Events Here are some upcoming events you might be interested in. Let me know if I've missed any! VueConf CN 2024 — (July 6, 2024) Check it out here PragVue 2024 — (September 17, 2024) The first Czech Vue.js conference, taking place in Cinema City - Nový Smíchov Check it out here Vuejs.de Conf — (October 8, 2024 to October 9, 2024) A community-driven Vue conference in Germany. Listen to great talks from great speakers and meet the wonderful VueJS Community. Check it out here Vue Fes Japan 2024 — (October 19, 2024) Check it out here VueConf Toronto 2024 — (November 18, 2024 to November 20, 2024) My favourite Vue conference, in my own backyard! A three-day event with workshops, speakers from around the world, and socializing. Check it out here 💬 Write Less "A good way to stay flexible is to write less code." — Pragmatic Programmer 🧠 Spaced-repetition: UI states to get right The best way to commit something to long-term memory is to periodically review it, gradually increasing the time between reviews 👨🔬 Actually remembering these tips is much more useful than just a quick distraction, so here's a tip from a couple weeks ago to jog your memory. When building a UI, there are many different states that you need to consider: - Normal — Sometimes called the "happy path," this is when things are working as expected. For example, in an email client, you'd show some read emails, some unread emails, and maybe a few that are in the "spam" folder.
- Loading — Your UI has to do something while getting the data, right? A couple tricks:
1. Use a computed prop to combine multiple loading states — you don't want spinners all over the page. 2. Wait about 200ms before showing a spinner. If the data loads before that, it feels faster than if you quickly flash the loading spinner on and then off again. - Error — Things will go wrong, and you need to handle that gracefully. Effectively communicating problems to users to help them get unstuck is very tricky (don't make me guess the password requirements!). Hopefully, you have a good UX designer.
Empty — What happens when you have no emails to read, have completed all your tasks, or haven't uploaded any videos yet? A chart showing the "Last 30 Days" of data will probably look weird with no data. - Partial Data — Often similar to the empty state, but your big table with filtering and sorting also needs to work with only two rows of data. The list of emails shouldn't break with only one email in it.
- Lots of data — Okay, now you have 1294 unread emails. Does your UI break? Maybe that infinite scrolling doesn't make as much sense as when there were only 42 emails.
🔗 Want more Vue and Nuxt links? Michael Hoffman curates a fantastic weekly newsletter with the best Vue and Nuxt links. Sign up for it here.
p.s. I also have four products/courses: Clean Components Toolkit, Vue Tips Collection 2, Mastering Nuxt 3, and Reusable Components | 
评论
发表评论