Stop using Hooks For Clients | Use $lib for Efficiency! | Best place for your Clients!

แชร์
ฝัง
  • เผยแพร่เมื่อ 22 ต.ค. 2024

ความคิดเห็น • 23

  • @michaelpotter9006
    @michaelpotter9006 ปีที่แล้ว +1

    This is such an obvious efficiency --- now that I've seen it. Thanks!

    • @ConsultingNinja
      @ConsultingNinja  ปีที่แล้ว +1

      Glad to help! Thank you for watching!

  • @jpujol
    @jpujol ปีที่แล้ว

    I did this first time I tried Pocketbase. It works great, unless you use an edge environment like Vercel or Cloudflare. Then the cookies get corrupted when you instantiate the pocketbase client outside the hook handler. Haven’t tried this again for a few months, maybe adapters updates fixed this. Thank you for the vid ❤

    • @ConsultingNinja
      @ConsultingNinja  ปีที่แล้ว

      You are most welcome! Yes, this does depend on your specific use case, the PocketBase documentation used to specifically say to start a new client on every request. But I couldn't find that language anymore when I looked this last time. Thank you for watching!

  • @PiakBot
    @PiakBot ปีที่แล้ว +1

    Thank you for your tutorial very much.

    • @ConsultingNinja
      @ConsultingNinja  ปีที่แล้ว +1

      You are very welcome! Thank you for watching!

  • @DubiousDoodad
    @DubiousDoodad 11 หลายเดือนก่อน

    Hello! Thank you so much for these videos. Though, I have a question. If you were planning to deploy a site using PocketBase, wouldn't you want it to create a new instance of the pocketbase client each time a server request is made? Such as through a form action? This looks fine if its for personal use, but since there's one instance of the client for the server, then wouldn't it be sharing the same authstore for all users?

    • @ConsultingNinja
      @ConsultingNinja  11 หลายเดือนก่อน

      Hang on tight, information overload in 3, 2 , 1 , Blast off
      There are some "bases" that recommend starting a new client in your hooks.js (aka every request). And in fact PB used to , and last I checked it no longer recommended doing that. It isn't a big deal if you do though. The PocketBase SDK uses localStorage to facilitate the authStore. Pocketbase is keeping track of that behind the scenes using localStorage so every user has their own token in there. ...
      I just double checked and it looks like this is still the case Here is the relevant portion from the PB SDK
      "Auth store
      The SDK keeps track of the authenticated token and auth model for you via the pb.authStore instance.
      LocalAuthStore (default)
      The default LocalAuthStore uses the browser's LocalStorage if available, otherwise - will fallback to runtime/memory (aka. on page refresh or service restart you'll have to authenticate again). "
      There is lots that affect authentication though so be sure you research what you should do in your particular setup. An example being that I like to use SSR for all the benefits that come with that. When you do this you combine the pb.auth with cookies and the cookies get loaded and exported and checked on every request in your hooks like this:
      // update the store with the parsed data from the cookie string
      pb.authStore.loadFromCookie('pb_auth=...');
      // exports the store data as cookie, with option to extend the default SameSite, Secure, HttpOnly, Path and Expires attributes
      pb.authStore.exportToCookie({ httpOnly: false }); // Output: 'pb_auth=...'
      I am still seeing people that are worried about this and are implementing one instance as I have done in this video and then are using the pb.authStore.onChange() to trigger SvelteKits InvalidateAll() function to re-run all load functions whenever the authStore changes.
      As always be sure to check for recent updates to all relevant packages you are using. Also keep in mind authentication is complicated and there are always a million ways to do things that all have pros and cons. Be sure you are taking your specific needs and setup into account.
      Hope this helps!
      Mitch (CN)

  • @nzadam
    @nzadam ปีที่แล้ว

    I'm confused why you would moved the loading data into the hooks file. Wouldn't it make more sense to put all the routes in a single folder, or (folder), and then use a +layout.ts to make the load function data available to all the sub-routes?
    Regardless, thanks for the useful videos!

    • @ConsultingNinja
      @ConsultingNinja  ปีที่แล้ว +1

      This depends on what you are trying to accomplish and also what library you are using. First thing, this is not about loading data like from an api, this is referring to starting a client side piece of code. A lot of examples put the starting of a client inside of the hooks file, but if you dont HAVE to (some libraries require it), then you shouldn't because it is allocating memory for that client that will need to be garbage collected later. Just avoid doing it if you can given what you are trying to accomplish and what library you are using.

    • @adamshand
      @adamshand ปีที่แล้ว

      Thanks for the reply!

    • @ConsultingNinja
      @ConsultingNinja  ปีที่แล้ว

      You are welcome.

  • @dongums
    @dongums ปีที่แล้ว

    hmmm supabase auth for sveltekit documentation has initialize their client on the hooks but I'll try this

    • @TheMaxiviper117
      @TheMaxiviper117 ปีที่แล้ว

      "createSupabaseLoadClient caches the client when running in a browser environment and therefore does not create a new client for every time the load function runs." and Please stop deleting my comments ninja, trying to be helpful

    • @ConsultingNinja
      @ConsultingNinja  ปีที่แล้ว

      Yeah, there are a few tutorials for a couple other tech stacks that do the same. When pairing with SvelteKit they need to use the SvelteKit docs for how best to pair with SvelteKit. Thank you for watching!

    • @ConsultingNinja
      @ConsultingNinja  ปีที่แล้ว

      Thank you for adding this! I haven't gotten to SupaBase... yet. I have only deleted one comment the entire life of my channel and it was not from you. Sorry for the mis-understanding. I VERY much welcome additions like this as well as constructive feedback for my channel and code examples. We can always improve as developers as long as we are open to others and I certainly am. Thank you for being a part of my community!

    • @PaxNot
      @PaxNot ปีที่แล้ว

      This will not work for supabase auth because createSupabaseServerClient needs to be passed the request event and thus needs to be initialized on each request to ensure that a user is authenticated or not before serving up the request.

    • @ConsultingNinja
      @ConsultingNinja  ปีที่แล้ว +1

      Thank you for adding this. @TheMaxiViper117 mentioned that Supabase uses caching. Sounds like SupaBase needs the cached information coming through localStorage, sessionStorage, and cookies in order to work. I will do a series on SupaBase in the future and will include these tidbits when I get there. Thank you!