Protecting Routes with Auth

[@MattChinander]

Can't wait for middleware support where all routes or routes part of a pathless route can have this type of check so it doesn't need to be repeated everywhere.

[@JEsterCW]

rel

[@DarlantenCaten]

Any top level parent route acts as a middleware since its loader runs first.

[@MattChinander]

@@DarlantenCaten Loaders run in parallel

[@DarlantenCaten]

@@MattChinander does it matter? If the parent router loader redirects it the data will never leave server, hence you have your auth middleware right there

[@zduduu6329]

@@DarlantenCaten It does matter since the children loaders could be initiating fetches based on the user ID like shown in the video. Since loaders run in parallel, you currently have to write a requireAuth for every loader. With a middleware, you just need to write it once and all loaders inherit the user ID (or get redirected to login from middleware if user ID doesn't exist).

[@truth-12345.]

This is why I love Remix, it's direct to the point.

[@diurivj]

I’m eager for remix middleware support

[@JEsterCW]

rel

[@reed6514]

Throwing a redirect is interesting.
I made a php web framework & it never even crossed my mind to use exceptions in that way. Idk if i will, but it's an interesting idea.

[@Jason-eo7xo]

remix is so awesome. im in love

[@simonswiss]

Clever greenscreen positioning in the middle, hiding neither the code nor the UI 🎉

[@yarapolana]

My remix code is so slow at building, 22+ seconds to build... and have to manually refresh when I change something in the code.

[@ginger-viking]

Have you upgraded to using remix as a vite plug in?

[@yarapolana]

@@ginger-vikingthanks for answering, I am stuck
1- there is a library that breaks with 2.4.0. So I have to depend on 2.2.0.
2- There is a bug in vite for projects in 2.2.0 where vite fails to read files outside of the working repo (I am using turborepo)

[@hckhanh]

3:23 How about return redirect() instead of throwing?

[@shivam-dua]

When using return you would have to check if the value is instance of Response if yes return the value else its a userId and execution can continue. I have noticed that it messes up with the return type of loader when using useLoader(). Throwing is a much cleaner way, plus you can handle the thrown Response using remix ErrorBoundary().

[@Andre4991]

If you just return the redirect, you'll have to check inside the loader if you got a userId string or a Response object from `requireAuthCookie`, and branch on that. It's a lot more verbose.
Much simpler to throw the Response and immediately bail out.

[@hckhanh]

@@shivam-dua I don't think it will mess up the return type of the loader, cause it will return TypedResponse. I already tried it.
TypeScript will automatically remove it from the loader type, since it's not existed.

[@dagoacarralero5080]

but, where is precisely this thrown redirect being handled, i think i would rather be explicit, return the redirect or userId, and handle that on the requireAuth caller spot, next month would be hard to remember that contract is still there other wise; i don't know