DEV Community

Cover image for Stop Building Your UI Components like this❌
Harsh Choudhary
Harsh Choudhary

Posted on

Stop Building Your UI Components like this❌

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 hasty abstractions which is a story for another day, today's agenda is to learn how to make actually reusable components.

Lots of the time while abstracting the reusable component it turns into a mess of props. You've probably seen "reusable" components with over 50 props! Those end up being enormously difficult to use and maintain, at the same time it brings performance problems and actual bugs that are hard to track.

Adding one prop for a new use-case is not just an if statement and you end up making a lot of changes in the component making the code size huge and unmaintainable.

But if we're mindful of the kinds of abstractions we create, then we can make something truly easy to use and maintain, is bug-free, and not so big that users pay the download penalty.

Kent C dodd's has explained the problem in-depth, give it a watch:
Simply React

How does a reusable component looks like?

We've got a LoginFormModal component that's abstracted the modal for the login and registration forms. The component itself isn't all that complicated and only accepts a handful of props, but it's pretty inflexible and we'll need to create more modals throughout the application so we want something that's a lot more flexible.

<LoginFormModal
  onSubmit={handleSubmit}
  modalTitle="Modal title"
  modalLabelText="Modal label (for screen readers)"
  submitButton={<button>Submit form</button>}
  openButton={<button>Open Modal</button>}
/>

Enter fullscreen mode Exit fullscreen mode

Towards the end, we will create our component which can be used like this:

<Modal>
  <ModalOpenButton>
    <button>Open Modal</button>
  </ModalOpenButton>
  <ModalContents aria-label="Modal label (for screen readers)">
    <ModalDismissButton>
      <button>Close Modal</button>
    </ModalDismissButton>
    <h3>Modal title</h3>
    <div>Some great contents of the modal</div>
  </ModalContents>
</Modal>
Enter fullscreen mode Exit fullscreen mode

But isn't this more code and more complex than just passing the prop😒.
We have passed the responsibility to the user of the component rather than the creator, this is called inversion of control. It's definitely more code to use than our existing LoginFormModal, but it is simpler and more flexible and will suit our future use cases without getting any more complex.

For example, consider a situation where we don't want to only render a form but
want to render whatever we like. Our Modal supports this, but the
LoginFormModal would need to accept a new prop. Or what if we want the close
button to appear below the contents? We'd need a special prop called
renderCloseBelow. But with our Modal, it's obvious. You just move the
ModalCloseButton component to where you want it to go.

Much more flexible, and less API surface area.

This pattern is called Compound Component - components that work together to form a complete UI. The classic example of this is <select> and <option> in HTML.

It is widely used in many real-world libraries like:

Let's create our first Compound Component while building a reusable modal.

Building our first compound component

import * as React from 'react'
import VisuallyHidden from '@reach/visually-hidden'

/* Here the Dialog and CircleButton is a custom component 
Dialog is nothing button some styles applied on reach-dialog 
component provided by @reach-ui */
import {Dialog, CircleButton} from './lib'

const ModalContext = React.createContext()
//this helps in identifying the context while visualizing the component tree
ModalContext.displayName = 'ModalContext'

function Modal(props) {
  const [isOpen, setIsOpen] = React.useState(false)

  return <ModalContext.Provider value={[isOpen, setIsOpen]} {...props} />
}

function ModalDismissButton({children: child}) {
  const [, setIsOpen] = React.useContext(ModalContext)
  return React.cloneElement(child, {
    onClick: () => setIsOpen(false),
  })
}

function ModalOpenButton({children: child}) {
  const [, setIsOpen] = React.useContext(ModalContext)
  return React.cloneElement(child, {
    onClick: () => setIsOpen(true),
})
}

function ModalContentsBase(props) {
  const [isOpen, setIsOpen] = React.useContext(ModalContext)
  return (
    <Dialog isOpen={isOpen} onDismiss={() => setIsOpen(false)} {...props} />
  )
}

function ModalContents({title, children, ...props}) {
  return (
    //we are making generic reusable component thus we allowed user custom styles
   //or any prop they want to override
    <ModalContentsBase {...props}>
      <div>
        <ModalDismissButton>
          <CircleButton>
            <VisuallyHidden>Close</VisuallyHidden>
            <span aria-hidden>×</span>
          </CircleButton>
        </ModalDismissButton>
      </div>
      <h3>{title}</h3>
      {children}
    </ModalContentsBase>
  )
}

export {Modal, ModalDismissButton, ModalOpenButton, ModalContents}
Enter fullscreen mode Exit fullscreen mode

Yay! We did quite some work, we can now use the above component like:

<Modal>
     <ModalOpenButton>
         <Button>Login</Button>
     </ModalOpenButton>
     <ModalContents aria-label="Login form" title="Login">
         <LoginForm
            onSubmit={register}
            submitButton={<Button>Login</Button>}
          />
      </ModalContents>
  </Modal>
Enter fullscreen mode Exit fullscreen mode

The code is more readable and flexible now.

elegant,gorgeous code

Bonus: Allowing users to pass their own onClickHandler

The ModalOpenButton and ModalCloseButton set the onClick
of their child button so that we can open and close the modal. But what if the users
of those components want to do something when the user clicks the button (in
addition to opening/closing the modal) (for example, triggering analytics).

we want to create a callAll method which runs all the methods passed to it like this:

callAll(() => setIsOpen(false), ()=>console.log("I ran"))
Enter fullscreen mode Exit fullscreen mode

I learned this from Kent's Epic React workshop. This is so clever, I love it.

const callAll = (...fns) => (...args) => fns.forEach(fn => fn && fn(...args))
Enter fullscreen mode Exit fullscreen mode

Let's use this in our components:

function ModalDismissButton({children: child}) {
  const [, setIsOpen] = React.useContext(ModalContext)
  return React.cloneElement(child, {
    onClick: callAll(() => setIsOpen(false), child.props.onClick),
  })
}

function ModalOpenButton({children: child}) {
  const [, setIsOpen] = React.useContext(ModalContext)
  return React.cloneElement(child, {
    onClick: callAll(() => setIsOpen(true), child.props.onClick),
  })
}
Enter fullscreen mode Exit fullscreen mode

The power can be used by passing an onClickHandler to our custom button like this:

<ModalOpenButton>
  <button onClick={() => console.log('sending data to facebook ;)')}>Open Modal</button>
</ModalOpenButton>
Enter fullscreen mode Exit fullscreen mode

Celebrating guy

Conclusion

Don't make hasty abstractions and don't leave everything to props. Maybe it is a simple component now but you don't know what use-cases you would need to cover in future, don't think of this as the trade-off between time and maintainability, the complexity can grow exponentially.

Levitate the power of composition in React with compound components and make your life easier.

Also, check Kent's Epic React Course where I learnt about Compound components patterns and a lot more.

A little about me I am Harsh and I love to code. I have been doing this since 16. I feel at home while building web apps with React. I am currently learning Remix.

If you liked the blog, Let's Connect! I am planning to bring more such blogs in the Future.

Twitter
Linkedin

Know more about me: Harsh choudhary

Check my Testing hooks blog or how to build generic custom hook blog.

Discussion (28)

Collapse
lukeshiru profile image
Luke Shiru

I 100% agree with your take, just to add to the article, if you have a component that will always have the same combination of elements, like let's say a button with an icon inside, you might do something like this:

const ButtonIcon = ({ iconShape, ...props }) => (
    <Button {...props}>
        <Icon shape={iconShape} />
    </Button>
);
Enter fullscreen mode Exit fullscreen mode

And quickly realize that if you want to set the className of Icon, or any other property for that matter, you need to go ahead and add that to the props of ButtonIcon which is a pain. One way of dealing with this while keeping this being a single component, is to take an iconProps property and spread that:

const ButtonIcon = ({ iconProps, ...props }) => (
    <Button {...props}>
        <Icon {...iconProps} />
    </Button>
);
Enter fullscreen mode Exit fullscreen mode

And 🎉 tada! 🎉 you can now use the component as a button, and at the same time still have full control over the underlying Icon, without having to add new properties to ButtonIcon every time you need something for Icon:

<ButtonIcon
    className="fancy-button"
    iconProps={{ className: "fancy-icon", shape: "start" }}
/>;
Enter fullscreen mode Exit fullscreen mode

Cheers!

Collapse
harshkc profile image
Harsh Choudhary Author • Edited on

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.

Collapse
dhruvindsddev profile image
Dhruvin

Great approach

Collapse
deathshadow60 profile image
deathshadow60 • Edited on

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:

<form action="/login" method="post" id="login" class="modal">
    <a href="#" class="modalClose" hidden></a>
    <section>
        <a href="#" class="modalClose" hidden></a>
        <h2>Login</h2>
        <fieldset>
            <label>
                Username<br>
                <input type="text" name="username" required><br>
            </label><label>
                Password<br>
                <input type="password" name="password" required><br>
            </label>
        </fieldset>
        <footer>
            <button>Submit</button>
        </footer>
    </section>
<!-- #login.modal --></form>

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.

Collapse
harshkc profile image
Harsh Choudhary Author • Edited on

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.

Collapse
deathshadow60 profile image
deathshadow60

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.

Thread Thread
toxictoast profile image
ToxicToast

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.

Thread Thread
rkallan profile image
RRKallan

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

<div class="checkbox-container">
    <input id="checkbox-1" name="checkbox-1" type="checkbox" />
    <label for="checkbox-1"><svg ... /></lable>
</div>
Enter fullscreen mode Exit fullscreen mode

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

Thread Thread
toxictoast profile image
ToxicToast

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

Thread Thread
toxictoast profile image
ToxicToast

Ps: you can control the re-rendering in react components by using memo

Thread Thread
deathshadow60 profile image
deathshadow60 • Edited on

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.

Thread Thread
toxictoast profile image
ToxicToast • Edited on

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.

Thread Thread
deathshadow60 profile image
deathshadow60 • Edited on

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!

Thread Thread
rkallan profile image
RRKallan

@toxictoast

Ps: you can control the re-rendering in react components by using memo

I now about memo in React.
Why using memo when you can easily prevent?

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.

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.

Thread Thread
toxictoast profile image
ToxicToast

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)

Thread Thread
deathshadow60 profile image
deathshadow60

@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.

Thread Thread
deathshadow60 profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
deathshadow60 • Edited on

@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.

"JS for nothing and your scripts for free. That ain't workin', that's not how you do it. Lemme tell ya, these guys ARE dumb."

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.

Thread Thread
rkallan profile image
RRKallan

@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.

Collapse
nicped profile image
Nicolai Høeg Pedersen

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.

Collapse
deathshadow60 profile image
deathshadow60 • Edited on

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.

Collapse
rkallan profile image
RRKallan

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.

Collapse
iainsimmons profile image
Iain Simmons

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.

Collapse
jacopkane profile image
Furkan Tunalı

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.

Collapse
harshkc profile image
Harsh Choudhary Author

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.

Collapse
jfbrennan profile image
Jordan Brennan • Edited on

Good advice, but this still depends on React.

UI components should not be built with React or any other library/framework.

UI components should be made with vanilla HTML, CSS, and JS for maximum compatibility and speed and minimal size and complexity.
Applications (i.e. overall structure, navigation, and state management) should be made with a framework.

Collapse
hobart2967 profile image
Marco Klein

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.

Collapse
zippcodder profile image
Deon Rich

Great article! 👍🎉

Collapse
garylester profile image
GarylEster

how to plan a component library, including how to select a JavaScript framework to use ? break up spells that really work