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
Ps: you can control the re-rendering in react components by using memo
And there it is folks, as easily predicted @toxictoast has given us the typical "wah wah is not, please shut up" response so common amongst cultists drinking too deeply of the tainted flavor-aid. Because how DARE anyone have an opinion that differs from his own. I mean if people start pointing out the BALD FACED LIES about how "great" React is, someone might actually stop using it in places where it's doing harm.
You can't maintain a an echo chamber of lies when people start speaking out. Hence your butthurt reaction screaming about a "shit post" because it DARES to contradict the delusional fairy tale that "JS is the solution to every blasted problem, who cares how many users it screws over!". @rkallan gave us a great example of that with the incompetent wreck that is Materials UI, where they use 5k of JavaScript and a form that doesn't work right scripting off, to do what HTML and CSS can do in a half dozen lines of code. All because the people who made MUI don't know enough HTML to be telling anyone how to build websites. Don't believe me, take a look at the markup any of their template examples vomit up. Broken stupid DIV soup with zero semantics, zero accessibility, and that's just the markup.
It's also comedy that I'm speaking out against how it screws over site owners and users, and you think I'm making it about me. Because nothing says a narcissistic "me me me" like saying how non-inclusive the result is, talking about accessibility failings, and how many people it leaves out to dry.
But sure, I'm making it about me. Of course I am... and I'm the one "biased by opinion" as I talk about actual issues and problems that apparently mean NOTHING to you. Thus why it's no surprise RRKallan thought you don't care about accessibility or simplicity of code, because that's what I'm talking about and defending.
Whilst you seem to be defending... well, your opinion to the exclusion of others, whilst omitting any facts. As I wrote over on Medium, stop contradicting, start refuting.
You could start by providing an example of something built in React that doesn't have accessibility failings, a lack of graceful degradation, etc, etc. But no, you'll just keep spewing unsupported propaganda, glittering generalities, and defense of the indefensible all to maintain that all-so-precious status quo that lets unqualified flim-flam snake-oil peddlers bamboozle, hoodwink, and otherwise sucker mark after mark.
Because again, apparently my caring about all the clients and users this stuff screws over is a "me me me" response.
If you know so much about it and this and that is shit. Rewrite it then and make it better? What about that? That would be a Time used Best instead you use it to cry about what everybody should and shouldnt do.
You are so entitled to this shit that you turn into a Karen.
Ah yes, the "I failed to even understand the argument" response. What you seem to have failed to have grasped is that the alternative, the "better built" version ALREADY EXISTS. It's called vanilla code. I don't need to "rewrite it" because 80%+ (excuse me as I pull a percentage out my backside) of what it does is stuff plain jane HTML, CSS, and JS can do better without it, and the remainder amounts to nothing more than stuff nobody should be doing in the first place if you care in the slightest about usability and accessibility.
And if I'm talking about what others should and shouldn't do, it's because I'm parroting concepts from things like the specifications and guidelines of the underlying languages, instead of the nonsensical propaganda the framework fanboys cream their panties over as they tell usability, accessibility, specifications, guidelines, and the very intent under which all these technologies were created to sod off.
Though nice attempt at "moving the goalpost". But sure, I'm the Karen. Are you just going to keep crying "wah wah, is not" or do you have a rational counterargument about how great these systems are? I mean seriously, AGAIN, show me something built with this junk that doesn't have massive accessibility and usability failings, and that doesn't result in using two to ten times the code needed to do the exact same job!
You can't can you? That's why you're the one shit-posting since you've failed to make a single response that is anything more than the very thing you're complaining about. And then you want to talk about being "entitled"?
Tell me another one Josephine!
@toxictoast
I now about memo in React.
Why using memo when you can easily prevent?
If this is the only argument from you, then sorry. Because @deathshadow60 is giving arguments why and also provided an example. Based on my assumptions i placed example on the opinion of @deathshadow60 and to try to make his argument / opinion a little bit clear.
In our work there will be a lot of opinions. To grow we need to listen to each other, and give arguments.
The why you are reacting I personally dislikes and gives the feeling that you don't want to look out of your scope. I hope that i'm totally wrong about it.
To defend your reaction. It could be the why how @deathshadow60 reacts. The way of reaction could be more friendlier. But it could also be his way of communicate.
Why should i use my precious time and proof you wrong? i can proof you wrong (not 100% but at least over 75%)
Some Things are better done without Frameworks and Libraries (the fact that you call react a Framework is the proof that you have no idea) i'll give you that.
But some things should be done easier for the dev.
End-Users doesnt care if its 100+ Lines Vanilla Code, or 30 Lines of React, Angular, Vuejs.
But yeah - keep on compel your opinion to others with wall of texts and texts.
Im done with you now. Keep on Commenting nonsense i wont react to it anymore (pun intended)
@rkallan "his way of communication"
I'm a New Englander, by nature we're not a friendly people. There's an old joke:
In the deep south if you have a problem, everyone flashes you a smile, showers you in soothing-syrup platitudes, pats you on the back, and sends you packing with nothing more than the mental masturbation of "Thoughs and prayers"
In New England, we will berate and browbeat you, dissect every mistake you've ever made, call you a dumbass straight to your face... and then give you the shirt off our back if it actually helps.
Because you have to break things down to build them back better.
If I'm harsh on the topic, it's from seeing an endless stream of users being screwed over by these bad practices, and site owners getting equally bent over the log and told to "squeal like a pig" by the ignorant trash that are front-end frameworks.
But as @toxictoast seems to think, caring about other people is narcissism. Of course it is.
@toxictoast wow, the other predictable response common to the "wah wah is not", accusation of entitlement and ad-hominem... and now the Brave Sir Robin "run away, run away" because you're incapable of providing a rational counterpoint. As always with these types of "keep your opinion to yourself" twaddles, they can't defend their opposing opinion with facts, so they run away crying like a petulant five year old.
You even use the "end user doesn't care" argument. Is there a playbook those of you yumming up the lies about how great this manure is go by? An "Idiots guide to not defending your viewpoint" or something?
Here's a tip, end users do care when your bloated train wreck of code that's delivered doesn't gracefully degrade scripting off. They do care when it takes so long to load they say "screw this" and decide to go to another site. They do care when you have accessibility woes that sends them to a competitor, or worse into the legal system to sue the pants off you.
Just ask Domino's, Winn-Dixie, Beyoncé, Harvard U, Blue Apron, Nike and so forth about that. Or the banks, public utilities, medical facilities, and government organizations I've consulted at the past decade. But sure, "the user doesn't care about the code". Another of the fallacies people mindlessly parrot utterly devoid of fact.
Not that Domino's seems to care that their "JS for nothing" is so broken now, 90% of the time even non-disabled users can't order a freaking pizza. That HAS to be killing their bottom line.
Even more comical is the "AAAH, WALL OF TEXT" response so common to the poorly educated and gullible Twitter generation, who freak out over anything longer than a paragraph. All the more laughable on a website where people are posting ARTICLES. If you hate text so blasted much, why are you even here?
Keep digging that ditch pal.
@deathshadow60
For me no need to defend your why of communication 😉 but as we now not every body understand likes each why if communication.
Personal I like the direct communication. Only what I want to try is that we come to a point to understand and listen to each arguments.
I so much agree with you! The frontend world is just bloated to beyond being usable. For no reason at all... Setting up a tool chain in 'modern' stacks is just adding one fix on top of another fix ten times...! And no one on the teams I meet even understand what is going on. It is so freaking funny.
It stops being funny when all this garbage results in accessibility violations, and these site owners and app dev's end up in court over it. Or the ridiculous bloat, slowness, etc. etc. incurs a technical debt that causes a downfall.
But the fanboys of all this trash with their endless mindless propaganda if not outright lies don't want to hear that, and attempt to silence anyone who dares to even bring the subject up.
It is horrifying the number of people diving for these frameworks -- and CREATING frameworks -- who can't even manage to do something as simple as proper numbered heading orders, or use the media attribute properly if at all.
When the people making these systems can't even write basic HTML properly, how and why should we trust anything more complex they vomit up? Look at ANY of their examples, templates, and so forth, and it's all utter incompetent trash.
As said on an early comment, i'm not agree on all your points :) But thats normal i think.
I agree on the lack of accessibility and simplicity of frontend codes in a lot applications.
Also the usage of external packages which could be done easily with a few lines of code.
Maybe i'm wrong, please tell if so. But based on user experience there is a lot not possible when you only focus and program based on accessibility.
SSR and CSR needs to be in balance. Not everything is faster with only CSR or SSR. And when using CSR there needs to be a fallback with SSR for accessibility.
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.
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.
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.
Great approach
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.