Won’t passing the actual action to your custom hook force it to be bundled in the frontend code? Which would be you would include and other back end code in your front end like the prisma client for example? Would it be better to just pass the action type as a generic to the function?
@@sjc5 Any plan to update the repo to reflect this change? I am still new to typescript and remix, so i conceptually understand the above, but not sure what the follow on changes would be if instead of the action itself, you only had a action_type.
Thanks! Put simply, the SSR story isn't nearly as nice with create-t3-app as with Remix. It's totally possible to SSR, but you have to build these SSG helpers to do it in a nice way, and it's just not even close to as nice as Remix's built-in loader pattern IMO. Also, you can export hooks from Remix resource routes -- you can't export hooks from NextJS server-side files! That alone makes Remix a better DX.
@@SeanLazer I think in most cases for data loading, you’ll want to use standard route-level loaders. Otherwise you’re reintroducing spinners. Similarly, for mutations involving a page transition, the standard Remix action pattern makes sense. This is more just a helper around useFetcher to make building those “same page mutation” APIs really painless.
UPDATE: An evolved version of this pattern has now been published to npm as an easily consumable toolkit: github.com/sjc5/remix-easy-mode#readme
Well done! ❤
This is great!
This seems like a good pattern, I may use this on my app
Good timing, now available as a package! github.com/sjc5/remix-easy-mode#readme
Cool. Thanks.
Question: What would the advantages of this be compared to simply re-exporting the action from the api route, which i am currently doing?
Won’t passing the actual action to your custom hook force it to be bundled in the frontend code? Which would be you would include and other back end code in your front end like the prisma client for example?
Would it be better to just pass the action type as a generic to the function?
Excellent point. It really should just be a generic.
@@sjc5 Any plan to update the repo to reflect this change? I am still new to typescript and remix, so i conceptually understand the above, but not sure what the follow on changes would be if instead of the action itself, you only had a action_type.
@@joelalexander7293 Yeah good idea, should do a follow-up on this and get the repo updated.
@@joelalexander7293 Now available as a package, of course addressing this concern :) github.com/sjc5/remix-easy-mode#readme
@@sjc5 awesome, thanks!
Really cool, but wondering if there's a reason to choose this stack vs. just going with create-t3-app in the first place?
Thanks! Put simply, the SSR story isn't nearly as nice with create-t3-app as with Remix. It's totally possible to SSR, but you have to build these SSG helpers to do it in a nice way, and it's just not even close to as nice as Remix's built-in loader pattern IMO.
Also, you can export hooks from Remix resource routes -- you can't export hooks from NextJS server-side files! That alone makes Remix a better DX.
@@sjc5 Awesome. So do you use this approach for data loading/mutating in conjunction with Remix's loaders/actions for other data?
@@SeanLazer I think in most cases for data loading, you’ll want to use standard route-level loaders. Otherwise you’re reintroducing spinners. Similarly, for mutations involving a page transition, the standard Remix action pattern makes sense. This is more just a helper around useFetcher to make building those “same page mutation” APIs really painless.