loading...
Cover image for Commonly Used UI Components In React

Commonly Used UI Components In React

flippedcoding profile image Milecia McG ・3 min read

There are certain components, like dropdowns and modals, that always show up on the front-end. Requirements might make you change a few things about these components, like styling, but most of the core logic stays the same. If you work with React, making common UI components is relatively easy. I'll go over a few of these components and show you the code you can use to create them.

One quick note, the code for these will be very basic with little to no styling. I tried to limit the number of functions in the components as well. That’s so you can customize them to work with your specific application. So please feel free to take these simple templates and make them as fancy as you want!

Dropdown

Sometimes you see dropdowns so often that you forget they're everywhere. They aren't complicated to make, but people do take different approaches. The main thing to remember is that this is just a list of data at the end of the day. Whether it's a dynamic list or each of the values navigate to a different screen, the dropdown itself is simple. Here's an example implementation. Remember to replace the hard-coded list with your back-end call!

https://codesandbox.io/s/youthful-fermat-w6ui2

Form

How many websites or apps have you used recently didn't have a form? You have to log into applications and you'll always see a form trying to get a email address from you. Many elements go into making good forms, like validation or useful tooltips. Once you know what information you need from the user, the form isn't so hard to make. Here's an example with a lot of the form elements.

https://codesandbox.io/s/white-river-tl7fs

Modal

Any type of popup you encounter and many forms will be modals. They're good elements to use to show meaningful information from a current page without redirecting to a new page or changing the layout. It's useful to get information from users as well because it lets you isolate an element on the screen so the user is forced to pay attention to it. There are libraries out there for modals in React, but making one can be fairly simple. Here's an example.

https://codesandbox.io/s/elated-borg-xugyc

Search

Making search boxes is extremely common in applications. You'll see them in e-commerce, finance, CRMs, and almost anything else with searchable data. It's one of those things that's good to have in your toolbox. Here's one implementation of a search that returns a list of items as you type.

https://codesandbox.io/s/inspiring-cannon-cm7f2

These are just a few of the components you'll see all the time. Hopefully the code examples are useful! Keep in mind that if you're a front-end developer these kinds of coding challenges can come up in interviews. It is really easy to take these components for granted and forget how complex they can become.

Individually, the way they work is simple. But when someone wants a single page application where these components update dynamically based on what the other components are doing, things can get crazy really fast. Also remember that these are typically components users interact with directly. Design them to be accessible and user friendly and your users will be more likely to give you the information you need.


I'm thinking about doing more articles that have real code examples in them, but I can't decide if the code articles should take priority over the non-technical articles. I'd really appreciate your feedback because I want to keep writing stuff you find useful! I'll still be writing both kinds of articles, just trying to figure out which is more useful. Let me know in the comments or on Twitter: https://twitter.com/FlippedCoding

Posted on by:

flippedcoding profile

Milecia McG

@flippedcoding

Starting classes soon! | Software/Hardware Engineer | International tech speaker | Random inventor and slightly mad scientist with extra sauce

Discussion

pic
Editor guide
 

Hi Milecia, thank you for the post.

You can also embed sandboxes (, for which you can check out the Editor Guide).

{% codesandbox inspiring-cannon-cm7f2 %}

 

😱 I didn't know that! I'll update this now! Thank you!

 

You're welcome
& Nice~ Thank you for the update~

 

I'd highly recommend Material UI's components with theming. Theming is done in the root of your application (the ThemeProvider) and applied to all children. It can be used to dynamically set things like light and dark theme or brand colours, and it can fully override any CSS (in this case JSS) of the components.

 

Thank you Milecia
I'll use it ;)

 
Sloan, the sloth mascot Comment marked as low quality/non-constructive by the community View code of conduct

Sadly this is all just a stunning example of why I consider react and its kin/kine utter and complete garbage. JavaScript client-side doing things that are none of JavaScript's business any time after around a decade ago, zero graceful degradation client side given the train-wreck of scripting being the only functionality, writing two to five times the code needed to have it vomit up two to ten times the code needed because "wah wah, JavaScript is the answer to everything"...

Much like every other framework, it's a monument to 3i. Ignorance, incompetence, and ineptitude... to the point I am thoroughly convinced its CREATORS aren't qualified to write a single like of HTML or CSS.

Just take the first example of a dropdown... You have to stand in AWE of the incompetence required to vomit up 52k of markup and 15 MEGABYTES of "JavaScript for Nothing" being loaded for a dropdown that any COMPETENT developer would only have spent 1.2k of markup and 2.5k of CSS on! It only makes you work harder, not smarter...

This is even more of a problem since again, it doesn't gracefully degrade scripting off/blocked, doesn't work on screen readers, so if you deploy this on a website you're looking at possible legal ramifications. See how now even Dominos is under fire for Americans with Disabilities Act violations. GARBAGE like using React in this manner is EXACTLY the type of coding practice guaranteed to get you pimp slapped under the US ADA, or equivalent laws abroad like the UK's EQA. Made all the more terrifying by the fact it's no longer just banks, government agencies, health care, and so forth being held to WCAG or even stricter standards. With the supreme court refusing to hear Dominos case making the lower court ruling stand, we now have precedent for any business to be held accountable for these types of failings.

Good client side scripting should enhance an already fully working page, and never be the only means of providing functionality. In that way ALL of these react examples are utter and complete failures at web development.

10 to 100 times the code needed whilst flipping the bird at usability and accessibility? Yeah, how is this a good choice in technologies apart from covering up for not knowing enough HTML or CSS to even be working on the front-end in the first place?

I don't get it.

 

Good React code is smaller than HTML, not bigger. React strives for reusable components. Pure HTML is not reusable. You write it once and that's it.

 
Sloan, the sloth mascot Comment marked as low quality/non-constructive by the community View code of conduct

That's because it barely outputs any HTML at all in the majority of use cases. hence why ALL the code fiddles if you ran the bloody page with scripting disabled, has ZERO page content whatsoever.

Instead it's using JavaScript to vomit up JavaScript to kind-of TRY and put together broken inaccessible incomplete markup client side, instead of creating useful well written markup SERVER-SIDE.

Hence why for example this gem of "I cans haz teh intarwebs"

codesandbox.io/s/white-river-tl7fs

Is wasting on the output side 37k of markup on what should be a FORM, H1, five LABEL, five INPUT, a BUTTON, and MAYBE an extra DIV. That's not even 2k of HTML's flipping job!

That they then have the markup applied by vomiting it together innerHTML style instead of ACTUALLY using the DOM, have a DIV where there should be a FIELDSET, are wasting a INPUT to do BUTTON's job like it's still 1997, have ZERO semantic relationship between the LABEL and the INPUT because they omitted the ID's on the INPUT, etc, etc... Basically it takes 400 extra bytes to make 100% certain it deploys client-side 15 times the markup needed.

Nothing like 36k of accessibility violations with zero graceful degradation doing 2k of HTML's job. And for what? So you can slop it together with 2.4k of scripting instead of just manning up and using HTML properly?

Colour me unimpressed... and it's nonsense like this I've spent the past decade cleaning up after court case after court case, client after client... because the moment you pull derpy coding stunts like this, is the moment you risk ending up like Dominos. Or that Portuguese bank... or the dozens of smaller banks, public utility companies, health clinics, and so forth that make up the bulk of my clientele.

I don't care how 'resusable" it is when it's spitting out 15 times the code needed client side, making you write more code server-side than you need, that relies on even more library code, that results in websites that don't gracefully degrade telling large swaths of potential users to go suck an egg.

Maybe if people stopped using five to twenty times the code needed to do the job BEFORE we even include the size of these derpy frameworks into the equation, they would see how mind-numbingly STUPID these systems are.

But again, the people who MAKE these systems with every example make it plainly obvious they don't know enough about HTML or CSS to be working on the front-end, much less making systems that sucker in all the rubes and nubes. "For people who know nothing about websites, BY people who know nothing about websites" is not a recipe for success.