You're Probably Using Nuxt Wrong 

back like i never left 🫡

yeah it's a pretty dense topic. let me know if you have questions

glad it was helpful

it won't render on the server, but tbh it's still unclear if/how/when Google renders JS client-side. If you want to be sure it won't be indexed, useSeoMeta is probably your best bet

It is "probably" still indexed by Google *but* SEO would be better when rendering it on the server. Not even starting to talk about OG tags which aren't available otherwise (if they rely on the data)

appreciate u fr

glad you think so :)

yes. For data to be accessible (not be a promise) in the script setup.

@@nishantrai982 Thanks! I listened to the video in the background and missed this key detail.

Very good point!

I follow the example in the documentation - "Use Custom Fetch Composable" - it's basically a wrapper around the use fetch with default request options. You can use the functions onResponse and onRequest in the options to change both the response and request respectively. Or just set the headers field, either from runtimeConfig if it's an app config, or from another composable if it's a user auth header for example

Alexander Lichter dropped a banger video that could be helpful here - ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-jXH8Tr-exhI.htmlsi=RMZ23k-Vkwbqi6y9

In one project I created my own instance under composables and use that instance to pass data.

nuxt sucks because of this.

@@najlepszyinformatyk1661 makes you think they intentionally do bad docs... so they can sell their courses and certificate wich seems a thing now.... i think everyone would laugh in Estonia.. i would t try to get hired saying i have a "nuxt certificate" , would be seen as stupid tax.

The deeper you get into open-source libraries, the more you realize every library has this issue. Learning to read source and auto-generated documentation is key to mastering these tools.

Nuxt 2 gave me a horrible impression of Nuxt, so horrendous I just don't touch Nuxt nowadays. There was no human readable documentation, no typing, too much forced magical globals, string to symbol magic (even into global symbols), no proper informative errors, impossible migration/updates, very slow development of Nuxt 3 and the bridging methods, errors happening from absolutely nothing for zero reasons (that are non-documented and impossible to track down), very slow hot module replacement and a whole lot of other things that made me lose so much sleep and gave me gray hair. Just think about it: forced global variables, that have absolutely zero typing/type-hinting. Never fails to be a ground for eventual impossible to track down runtime errors. Forcing you into re-typing everything manually via .d.ts into global scope. Again, unmaintainable, unreliable and evil, because human factor. At least they have typing now

Idk what your talking about the docs are great now

the component will suspend with await, using lazy is a way to opt out of it client side i think it’s really nice to have the same code for both ssr and client, but the specifics of all the options can get confusing.

So true!!

any specific tools youre thinking of? im always down to make some more vids !

​@@LearnVue I had to spend some time to figure out what was called on the server, what was not for example. Correct me if I'm wrong, but as I understand, server components (still experimental) are actually the only way to have secure logic inside components. Otherwise you have to use the server part and make api calls (where the first render may be safe and made on the server but all subsequent calls are made client side).

@@blokche_dev Correct

Use ( Shift + < )