Відео

please do..... way more of these

In one of your examples there is an H2 above an H3, with the first one to be visually *smaller* than the second. Based on the Information Architecture of the site this order is the desired one. I'm wondering how your approach covers this case and *respects* the same IA. I cannot think a way to use <Typography/> comps without changing the design of the page. Thanks for the content.

can you make different variants out of the same SFC? lets say a button component with different skin or looks

Vue Vine this is utter nonsense, just like JSX. And it should only remain a separate plugin, as it is now. SFC is the best there is.

Vue Vine это полнейшая шляпа, как и JSX. И это должно оставаться только отдельным плагином, как сейчас. SFC это лучшее что есть.

Благодарю вас сэр

Hey Alex thanks a lot the great video. I’m still confused about what is the difference between props.title vs ()=> props.title

For god's sake, just use React

Lovely! And TSX/JSX absolutely sucks!

the best of this video is discovering by comments the use of vueuse: "createReusableTemplate". That's great!! thnx!!!!

It's doable in React but usually you just prepare sub parts of the components until you assemble it for the default export return. If you put two unrelated component in single file, is that you just break the best practice?

I don't like this stuff. just stick to vue templating and not jsx. probably this plugin won't last a year. lol

I wish this was merged into core. There are too many sacred cows in Vue holding it back

This ain’t nothing but some pills to cure symptoms. The whole ‘we put things in folders by type’ is the actual sickness. Once you put together the things that belong together, all the naming problems disappear. E.g., you have a page that consist of multiple components. Put everything in one folder, export in index.ts only the things that are meant for the outside world and you can have the same name twice.

React vibe?

This is great!

This will be helpful when implementing the "Compound Pattern," where there's a parent-child relationship and the child must be rendered within the parent context. When both components exist in the same file, it emphasizes how tightly coupled the relationship is. Another option is to not export the child components at all and just export the big boss!

We're becoming more and more like React, idk if that's a good thing or a bad thing

Reminds me of Lit(.dev)

You could just use const Comp = defineComponent( (props) => { const count = ref(0) return () => { return h('div', count.value) } }, // extra options, e.g. declare props and emits { props: { /* ... */ } } ) and use it in template like regular sfc component

I thought this was a joke. this just makes code harder to understand especially if you have a lot of components in one file. I think React is the only framework that allows this. Angular, Svelte, Vue all agree that you should have SFC - SINGLE file components.

Great Episode! Tbh I see nothing wrong with this at all! Just a new tool / an way of doing this, that has its pros and cons like other way. It's all about deciding when to use it!

This destroys the idea of SFC, hence the name single file component. I would stick to SFC, it's the best experience no matter how big the app becomes.

You could also use TSX for a similar experience - you can then define components inside a SFC 🫨

What if we had component templates? :3 <template> <MyComponent /> </template> <template component="MyComponent"> My stuff </template>

This is an anti-pattern. The component always starts out small and eventually you end up with 10 different components in one file as your app grows. Please don't do this.

There is a good reason why you can't write multiple components in one file. It violates the Single Responsibility principle (SRP) and breaks separation of concerns. It's also harder to test each unit. It leads to less readable, dirty code. Each file should ideally represent a single unit of functionality or concern. Having one component per file ensures that the logic, template, and styling for that component are self-contained and easy to understand. Mixing multiple components in one file blurs the boundaries between them, making it harder to determine what each component is responsible for.

Amazing this is what i need to implent rigth now, thanks again for the great tip and video keep doing it 😊 Btw random question abour nuxt, os there a way to use a Middleware in oate folder level or has to be in each page

Another way of writing components further increases fragmentation... By the way, regarding optimization when using JSX. In the slides from the "Vue Vapor: Reinvention" talk by Kevin Deng (sxzz) at Vue Fes Japan 2024, there's a mention of using JSX, where Vapor also works with JSX (the unplugin-vue-jsx-vapor package by zhiyuanzmj)

Very nice. Just helped TODAY in a current project. How fun is that.

In our case we handle the number of returned data to FE via transformer and based on payload e.g. if FE wanted certain fields, FE can use the fields payload, or conditional approach e.g. pages: employee, profile-page which it then used as condition for transformer in the BE, that way, the FE has ton of options without realliying heavily from BE team.

Thank you for this video! It cleared up a lot of my doubts. But I still have one question: I'm using Nuxt 3.14 and making a `useFetch` request on the `home` page to fetch data from a local SQLite database. I've also configured `routeRules: { '/home': { prerender: true } }`. The problem is, when I run `build` and deploy it to my cloud server, the prerendered page includes the fake local data. How can I set it up to exclude this unnecessary prerendered data?

I agree with this: ua-cam.com/video/QuLfCUh-iwI/v-deo.html

Thanks Alex, I'm curious to know whether there is a technical limit to the number of 301 redirects applied and also what the performance hit might be on large numbers of 301 redirects (like 300 or so).

Thanks! Your video helped me a lot.

after I had developed with Lit for some years, I was looking for a feature like this in Vue too. it looks on the way

alien-signal package.. not a bad name tbh hahaha

Very cool concept.. would love to see more examples.

While I understand your reasoning behind using this in a large project, i also feel that it's over engineering what should be handled by educating developers with bad habits. Yes, i think it helps to prevent using incorrect semantics, and having types on everything makes me very happy, but the lack of education in the basics of web development is where the real problem lies. Tailwind is great, but only if the person using it understands the semantics of the elements they are applying classes to. While you are trying to prevent these issues, I don't think senior devs should have to spoon-feed over-engineered solutions to more inexperienced devs instead of educating them within the context of a code review. In response to the argument for using this on a large project, this should be handled with a good design system and conversations between the design and dev teams. We all need to hold each other accountable for the sake of good semantics and accessibility. The above is just my humble opinion and I do love your videos. BTW, a mention of, or a video on, the new EU Accessibility Act would be great. A lot of people don't know about it, and your platform would be very helpful in spreading awareness of this.

There are a lot of cases where you need to create a small component and writing it in the same file would be great

Thank you for explaining useFetch. It really cleared things up for me.

Nice video manniL Do you perhaps know why in prod build the websocket broke with the url in `peer.websocket.url` being undefined The preset is `node-server`

up

This smells like React and like a bad pattern, spaghetti ❌

Intro is too loud

wait what. this is cool. kinda like jsx bit

Please more vids like this. Thats the kind of content we dont find anywhere else!

technically vue has almost always been push-pull, and actually every reactivity system since like 2015 has been push-pull. When these authors talk about reactivity, they tend to say "pull based semantics" or "pull model" just to emphasize the "pull" part of "push-pull", which changes a lot of things compared to traditional push-based reactivity like rxjs. so this doesn't "switch" from pull to push-pull, that's just a misunderstanding caused by how authors talk about this stuff.

This is mind blowing, Alex!

good video alexx