It is true everyone feels elated abstracting the most often copy-pasted code in the codebase into a reusable component. One bad effect of that is h...
For further actions, you may consider blocking this person and/or reporting abuse
Stunning example of why I say most React developers don't know enough HMTL or CSS to be working with web technologies, particularly given the bloated mid-2000's wreck of "JS for everything" mess.
Because to be frank, a login modal isn't even something I'd use JS for, unless it were to enhance the already working form by hooking the submit, grabbing the formData, so as to avoid the pageload whilst still allowing a normal page-load if scripting is blocked/disabled/irrelevant. And that's assuming the client has bought into the "rawrz rawrz teh pageloods es teh evuls vyrus f satin" LIES.
I mean seriously, If I were building a login form the markup would be this:
With EVERYTHING else done from the CSS using :target. All that's needed to open the modal is href="#login" on an anchor.
But sure, you need all that component junk, dozens of functions, and ten times the code to do this, that way you can tell users with accessibility needs to go **** themselves with "JS for nothing" and CSR rubbish... Which of course "saves bandwidth" and "improves the user experience." Sure it does...
levelup.gitconnected.com/modal-dia...
But what do I know? I consider the very idea of "components" to be lazy copypasta garbage for people unqualified to build websites or web crapplications. HTML and CSS aren't so complex you need to be pulling these types of bloated "JS for nothing" stunts, much less some goofy JSX packaging rubbish. For people trampling over each-other in a rush to use web technologies for applications and CSR trash, it's amazing how many seem to flat out refuse to embrace any of the most basic concepts.
Woah! You need to calm down, no one is stopping anyone to choose whatever tech stack they want to build good stuffs. The modal was just a demonstrated example to make people aware of the mistakes they are making in React.
You want to use plain JS use it, React came into existence because of the maintainability problems in vanilla JS. I agree forms/modal should not be this complex but handling DOM is also complex, React makes it easy. We have to live with the trade-off.
Good news is frameworks like Remix built on top of react is making things happen like the good old way. So yeah in the future we will get best of the both world.
No, React is a bloated wreck created by people not qualified to work with node.js or client-side scripting. It addresses no "maintainability problems" that wouldn't exist if people would just LEARN. But instead of learning HTML, CSS, and JS and the most basic of development principles, they get suckered into diving into 3i garbage riddled with bad practices. 3i of course being the most common problem in web development: ignorance, incompetence, and ineptitude.
As an accessibility and usability consultant I WASTE so much of my time ripping out client-side scripted garbage like React. I've NEVER seen anything done with it that wouldn't be cleaner, simpler, or easier without it! Be it CSR and SPA trash pissing on accessibility from so on-high you'd think the almighty just got back from a kegger, or server-side where it just makes you use two to ten times the code -- especially now that we have template literals native making JSX even dumber than it already was.
React -- or any of these other "frameworks" -- does NOT make ANYTHING easy. To think that it does is outright delusional. Half of what people build with it could have been done far simpler without it, the other half has no business being scripted in the first place.
There is NOTHING of value it can teach anyone other than how not to use JavaScript -- client OR server-side.
All i read here is just mimimi :D
if you dont like React, fine, but dont comment shit like this because noone will care.
You have your Opinion, fine - no one asked for it.
I'm not totally agree with @deathshadow60 but turn off javascript in your browser and check the most web applications. Only a small part of the applications will work and still visitable as intend. As example try to buy and pay on e-commerce site. You will see it's not possible.
Also a simple check how bit crawlers will read your page / application.
Also a common mistake is to use only client-side checking when submitting forms, user can bypass these checks.
Part what I miss is user experience.
@toxictoast
Why is the comment shit? Based on your comment you don't care about the accessibility of your application and simplicity of code.
Example of Material ui toggle button (mui.com/components/toggle-button/).
On MUI there is is used a button which call a JS function on button click to set or remove class Mui-selected and to set attribute value of aria-pressed to true or false.
When clicking on the button the component will re-render because properties are changed.
This same could be reach without JS and with only HTML & CSS
and with the use of .checkbox-container input:checked + label you can change the look and feel. Less code no re-render of the component
An another example is the use of submitting a form. A common seeing approach is setting form element value on element value change to state. This state is used when submitting the form.
If form is submitted, with JS the values of all form elements are reachable with event.currentTarget.elements
No you get me wrong
I am not willing to discuss stuff somebody doesn't want to know about and is biased by his opinion. That's why the comment is shit. Because no matter what anybody says and who is in the right or not... he will always have something to brag about 😀
I am caring about ux and my ui
Yeah surely this is the smart way to build simple stuff that you know can't get more complex.
Be smart don't overcomplicate things when not needed.
I partially disagree: If you aim for webcomponents, having all code (html,css,js) isolated, it does not make any difference to the user. The only thing would be size and performance, but interface and contract wise, you won't see a difference.
Great approach
I still have doubts using context instead of passing props explicitly is more elegant.
It's just another way of creating abstraction while trying to avoid a simpler abstraction.
While passing props abstraction here is, primitive and obvious (it's literally just passing parameters to another function) context is not, it requires further knowledge and documentation read and not idiomatic.
To simplify passing props, we can consider passing repeating parameters with a spread/rest operator and pass only the changing parameters. This way you can reduce repeating defining props repeatedly but will be still easier to reason where and how those parameters are coming from.
Still, thanks for this article and sharing your knowledge with other ways to approach problems.
Sorry but I disagree with your point, even when you are passing the props you need to manage state of the props yourself. Maybe you are manging in the parent component which will become clumsy because let's say some other state of the parent rerender the whole component will re-render which will render your reusable component because props changed.
Managing state locally in reusable component helps you with not only readabliity but also with performance plus you can memoize stuffs easily.
Nice! I read about a similar concept on Patterns.dev: patterns.dev/posts/compound-pattern/
They also use named exports for the child components so that you can import everything into a single variable. I don't know how much of a difference that makes with tree shaking, etc.
Great article! 👍🎉
how to plan a component library, including how to select a JavaScript framework to use ? break up spells that really work
Awesome article.