I get that it's cool in theory to use all this native functionality, but at the end of the day having this giant form with multiple hidden inputs is way less readable and maintainable to me, compared to an "onClick"
The “bop bop bop bop”, followed by a little chuckle at 8:44 really reminded me of Bob Ross. Which is awesome. On a more serious node: you could use the form method to distinguish different forms, right? And the button value to differentiate further when needed?
Hello. If I had a form that added a like to a blog post or something would you recommend just removing the default submit button styling so only a font awesome icon is shown?
everything old is new again and I mean that in the best possible way 😅 side note, having educators create a framework makes learning it soooooo much easier.
Bravo! Give it a year and The Industry will wake up and start using Remix. If I may ask an unrelated question - Mr. Florence, which keyboard (and mouse) are you using in this recording? It's not mechanical, is it?
Hi, is _action with value being added to FormData with ? Because Chrome does not seem to include button by default if I just call new FormData(form) in fetch.
What if I also wanted to create an API for the same actions (like e.g. the delete action) and provide it to my customers? Should I separate that into a different route (so duplicate it) or how is that meant to be done in remix universe?
If you have the `Form` post to a different path via `action="/somewhereelse"`, like described at 00:01:30, ... 1. how to prevent the browser from navigating there, and 2. how to get potential server-validation errors back to render them below the input fields?
Maybe more of an architecture question but how would you scale this out to a route that has potentially dozens of mutations? For example a dashboard. I've gotten really accustomed to building reusable components that do their own data management, ie you embed the Users, Orders, and Products widgets on the dashboard page and they take care of their own data needs. How would you handle something like that in Remix without having super bloated loader and action functions?
I've not tried Remix yet, but isn't this a good candidate for nested routes? I'm trying to imagine a scenario where this would be possible where the mutations aren't in a list
@@frontendtony that's what I was wondering, maybe the idea of like portable or embeddable routes. I just remember the rails days of a dashboard#index action where you're loading like 10 separate pieces of data in one controller action.
2:47 While I like this approach, React is throwing an error for this approach since 'onClick' handler is missing. Is it possible to suppress that error? EDIT: Use defaultValue :)
I love the "use real forms" stuff, it's great to be able to dust off my PHP and Django web dev experience from 15 years ago! Has the Remix team been thinking about how to model forms in such a way that we can get TypeScript coverage between frontend (default export) and backend (loader and action exports)? Having these all in the same route module file is already such a neat developer experience, it would be even cooler to have the tooling help a little more with this stuff! I've been playing around with different ways of doing this in Remix but haven't found anything that fits naturally with the inherently untyped nature of the web APIs (e.g. FormData and input name and value attrs).
I personally tie the form typing with validation using Zod. Someone recently created remix-validated-form as well to add onto zod or yup and just make using forms a little nicer.
Great solution. Can we get one where inputs are dependent on another input's value? Like when sub category select options are dependent upon category select value.
This is a good use case for useFetcher OnChange of the first select, you can trigger a fetcher submission to retrieve the options for the second dropdown and populate it. Or for a normal react solution simply send all options down on first page load, and useState to track which set to show
just curious how it would work if I wanted to delete a few users simultaneously like clicking five times on different names with slow connection, I guess it will do the job for my last click but not for all of them right? btw really like remix and your videos
Yeah that's what I've been thinking, like if you have a table and select multiple users how can you handle that ? I bet you can it's just a matter of understanding how.
Наука
Oh, man! Using a hidden input field brings me old good memories. I love Remix.
Remix Singles are Awesome and Ryan Florence is the best DEMO person, to the point and crystal clear. Love these.
I can't get enough of remix. Make the web simple again!
"It's what ur code doesn't do" killed me
So amazing what you guys have built so far! I cannot wait for more videos like this!
Love those videos. Great commentary and always something new to learn even with a few years of experience on my back.
Thanks Remix! These short videos are great and I love them!
discovering these videos again today and they are awesome. 2 years old is a million years in web time but these are still amazing.
"Buttons are input fields" It's funny how stuff I learned 20 years ago (while reading html 4.0 spec) sounds like news now 😂 -- Awesome framework!
Mind blown! Great job guys!
Amazing series! Remix is just 🔥💚
Been watching this video with a smile on the face. This tells you all I guess!
♥💛💚💙🖤
"bop-bop-bop-bop-booop"... I will do it all the way from now. With Remix :D
Remix is so much better than Next.js. Good job!
I ❤ Remix! I was so tired of Next and now I like to do a web dev once again!
Awesome videos, thanks!
Maybe a video that shows how you would approach reusable components, used on many routes that fetch and post data?
These singles are great.
Papapapa this was fun & enlighten. What such a good tech, now I see why the REMIX
I get that it's cool in theory to use all this native functionality, but at the end of the day having this giant form with multiple hidden inputs is way less readable and maintainable to me, compared to an "onClick"
Aaah thanks i run into that problem sometime ago 🤦 but now i now i know how to handle it. Thanks you☺️🥳
Yeahh rayan keep it comming
The “bop bop bop bop”, followed by a little chuckle at 8:44 really reminded me of Bob Ross. Which is awesome.
On a more serious node: you could use the form method to distinguish different forms, right? And the button value to differentiate further when needed?
It's all HTML, so yes and yes. Do it however you like.
Thank you so much!
Thanks a lot!
Yep. I did enjoy it.
almost 10 years of webdev and i never thought to use a button as a form input with a value. wild stuff
Reminds me of aspnet postback model and client side auto update using updatepanel of the early 2000s. I dig it, it's a mix of old and new.
Hello. If I had a form that added a like to a blog post or something would you recommend just removing the default submit button styling so only a font awesome icon is shown?
everything old is new again and I mean that in the best possible way 😅 side note, having educators create a framework makes learning it soooooo much easier.
Bravo! Give it a year and The Industry will wake up and start using Remix. If I may ask an unrelated question - Mr. Florence, which keyboard (and mouse) are you using in this recording? It's not mechanical, is it?
damnn! this is nice
You are correct - I never implement an abort fetch for rapid clicking 😅
Hi, is _action with value being added to FormData with ? Because Chrome does not seem to include button by default if I just call new FormData(form) in fetch.
What if I also wanted to create an API for the same actions (like e.g. the delete action) and provide it to my customers? Should I separate that into a different route (so duplicate it) or how is that meant to be done in remix universe?
If you have the `Form` post to a different path via `action="/somewhereelse"`, like described at 00:01:30, ...
1. how to prevent the browser from navigating there, and
2. how to get potential server-validation errors back to render them below the input fields?
nice work dear friend , i like , nice share , stay connected
Is there a sample code discussed here on a gist/repo?
Maybe more of an architecture question but how would you scale this out to a route that has potentially dozens of mutations? For example a dashboard. I've gotten really accustomed to building reusable components that do their own data management, ie you embed the Users, Orders, and Products widgets on the dashboard page and they take care of their own data needs. How would you handle something like that in Remix without having super bloated loader and action functions?
I've not tried Remix yet, but isn't this a good candidate for nested routes?
I'm trying to imagine a scenario where this would be possible where the mutations aren't in a list
@@frontendtony that's what I was wondering, maybe the idea of like portable or embeddable routes. I just remember the rails days of a dashboard#index action where you're loading like 10 separate pieces of data in one controller action.
As one of these old developers I would add an hidden input for the action as well, like in the olden days :)
which tool do you use for disalbe/enable javascript on developer mode?
2:47 While I like this approach, React is throwing an error for this approach since 'onClick' handler is missing. Is it possible to suppress that error?
EDIT:
Use defaultValue :)
I love the "use real forms" stuff, it's great to be able to dust off my PHP and Django web dev experience from 15 years ago! Has the Remix team been thinking about how to model forms in such a way that we can get TypeScript coverage between frontend (default export) and backend (loader and action exports)? Having these all in the same route module file is already such a neat developer experience, it would be even cooler to have the tooling help a little more with this stuff! I've been playing around with different ways of doing this in Remix but haven't found anything that fits naturally with the inherently untyped nature of the web APIs (e.g. FormData and input name and value attrs).
I personally tie the form typing with validation using Zod.
Someone recently created remix-validated-form as well to add onto zod or yup and just make using forms a little nicer.
Why don't you use the method="delete" in the form? That way you wouldn't need to define the "_action" name on the button.
Holly Button !!! 😯
can we use just method="DELETE"?
Really enjoy it. "bop bop bop bop", makes me laugh.
Great solution. Can we get one where inputs are dependent on another input's value?
Like when sub category select options are dependent upon category select value.
This is a good use case for useFetcher
OnChange of the first select, you can trigger a fetcher submission to retrieve the options for the second dropdown and populate it.
Or for a normal react solution simply send all options down on first page load, and useState to track which set to show
I'm old school hidden but data-* on the button might also work for the id.
The sound effects while deleting make this video! 🤣
Any RTE for remix js????
just curious how it would work if I wanted to delete a few users simultaneously like clicking five times on different names with slow connection, I guess it will do the job for my last click but not for all of them right? btw really like remix and your videos
nice video on concurrent mutations, thanks!
Yeah that's what I've been thinking, like if you have a table and select multiple users how can you handle that ? I bet you can it's just a matter of understanding how.
5:25 ah yes, classic DOM clobbering 😁
A replacement for _action i've been using is "intent"
7:09 bop bop bop bop bop bop buh bup 🤣. Can that please be the official name for that concept?
Throtting or debounce, there is a lodash utility for this as well.
Ohh thats how that works
I don't do much, but I always used to abort unnecessary requests
A user could change the values of the hidden fields before submitting. It seems like there should be a more secure way of doing this.
So the user is going to hack themselves? This is silly
8:46 type `ej` for enabling and `dj` for disabling javascript
I wish action was passing $REQUEST