The entire reason I made this is because I wanted to do one really simple thing: store the names of shows in a file that I could then resolve against the TvMaze API so I could track shows with minimal effort. I figured maybe other people would be interested in that the approach is extremely simple, which is the whole point.
Twilio library? That defeats the entire purpose of this, which is to allow simple CRUD operations on a JSON file to resolve against using a React/Angular style SPA. This is not intended for more complex web applications. Also, further this is simply example code, not something I am planning on updating in any way, because it served the purpose for what I needed.
I actually have made an SMS Marketing App and for that I used Python (Flask), PostgreSQL, Angular 4, and Docker with nginx to bring it all together.
I specifically say in my blog post that this isn't intended for teams or anything more complex than flat file CRUD. This would blow up really quickly and be a nightmare to work with as a team - there isn't even any sort of validation.
The truth is, most of the time I write APIs using either Java 8, Express/NodeJS in TypeScript, or Python with Flask with a persistence layer like PostgreSQL all backed by Docker. I felt like that was huge overkill for storing just the names of shows, and I didn't want to have to store this on a VPS with a reverse proxy... I figured one PHP file was really all I needed for the CRUD operations.
That should be fine, at least for avoiding this attack.
In general, though, there are solid reasons to use this pattern in React. With uncontrolled components, you won’t be able to use React to do form validation or AJAX form submission. You would need to bypass the React virtual DOM and attach listeners on the actual DOM elements.
Very good point! With that method you can still display validation errors in a “Reacty” way. But you still don’t get pre-submit validation, like marking an input invalid on blur, or displaying real-time password strength.
You can still capture an uncontrolled input's data `onChange` and `onBlur` for validation, password strength checking, later submission etc., you just don't reflect it back into the input on every render.
The only thing it affects is your ability to change the input's data via a state change, but for a password field would you ever want to do anything but get its current value or clear it?
You’re right. With a little effort you could create reusable React form fields that are not controlled but which communicate their value/blur/etc. back to React for validation purposes.
And yes, for password inputs, I can’t think of a case where you would absolutely need to control the value via React. Things like password confirmation validation and password strength indicators can be implemented via onChange and onBlur. It’s more tedious than the normal controlled input pattern, but given vulnerabilities like this one, it’s likely worth creating reusable uncontrolled inputs.
I think the doc ought to be updated to say that you shouldn't make a password field a controlled component, and maybe even warnings added if you set value at all.
Even using the same API... what a small world. I'm glad I can use yours instead now! I was actually thinking it would be fun to use Python to search the Tv Maze API for cast of different shows you like and then find common shows with the same actors. Might be a waste of time though. Nice job on Tello.
