DEV Community: Sara

Creating Accessible Forms in React

Sara — Mon, 17 Jun 2024 08:05:00 +0000

Why is accessibility in web forms important

Accessibility in web forms ensures that all users, including those using assistive technologies such as screen readers and keyboard-only navigation, can interact with and complete web forms easily. There are already established accessibility standards and best practices that developers can follow to create inclusive online web forms that improve the overall user experience by making it usable for everyone. (Some resources are included at the end of this post).

Semantic HTML form elements

One of the most important step to creating accessible forms is using the proper semantic HTML form elements such as: <form>, <input>, <label>, <select>, <textarea>, <button>, <fieldset>, <legend>, <datalist>, <output>, <option>, <optgroup>. All of these elements clearly describe their meaning in a human and machine-readable way and provide context to web content, enabling assistive technologies to interpret and interact with the content accurately.

Properly structured semantic HTML elements also enable better keyboard navigation essential for users who rely on keyboards or other input devices other than mouse. Using the correct element such as <form> will ensure that pressing the Tab key through a form follows a logical order, that will make form completion easier, or using a <button> element will trigger form submission by default when the Enter key is pressed. In the same way, associating a <label> with an <input> helps screen readers announce the label when the input field is focused, which helps users understand the purpose of the field.

In some situations, custom form elements might be needed if the provided HTML elements are not enough for the purpose of if a more customised look is required. In which case it is very important to make the custom elements accessible using the proper ARIA (Accessible Rich Internet Applications) roles and attributes. However, relying on semantic HTML elements whenever possible will certainly reduce the need for additional ARIA roles and properties which will minimise complexity and potential errors.

How to create accessible forms

Placeholders

Most often, placeholder text is used to provide instructions or an example of what kind of data is required for a certain form field. It is usually displayed with lower colour contrast and it disappears when the user starts typing. Placeholders can provide valuable guidance for many users, however it is important to always use it alongside a label as assistive technologies do not treat placeholders as labels.

Labels

Label elements provide clear, descriptive text associated with form fields that allow all users to better understand the purpose of each field. Here are a few approaches of using label elements when creating accessible forms.

Explicitly associating labels with form fields:

The most common and recommended approach is using the for attribute on a <label> element to associate it with an <input> element by matching the for attribute with the id of the input element.

   <label for="username">Username</label>
   <input type="text" id="username" name="username"/>

Wrapping the form field in label element:

Sometimes the id of a form field might not be known or even present. In cases like this, the <label> is used as a container for both the label text and the form field so that the two are associated implicitly.

   <label>
      Username
      <input type="text" name="username"/>
   </label>

However, explicitly associating labels is generally better supported by assistive technology.

Using additional instructions aside from labels

In some cases, additional instructions aside from the label might be required. Such as: a helper text below the input field or an additional description bellow a label element. To make the form accessible in scenarios like this, you can use the aria-labelledby and aria-describedby attributes. Here is an example:

   <label id="dateLabel" for="dateOfBirth"> Date of birth:</label>
   <input type="text" name="dateOfBirth" id="dateOfBirth" aria-labelledby="dateLabel dateHelperText">
   <span id="dateHelperText">MM/YYYY</span>                                                                    


   <label id="dateLabel" for="dateOfBirth">Date of birth:</label>
   <input type="text" name="dateOfBirth" id="dateOfBirth" aria-labelledby="dateLabel" aria-describedby="dateHelperText">
   <span id="dateHelperText">MM/YYYY</span>

Hiding the label

Sometimes, the design requires omitting a label from the form field, but it is still necessary for a fully accessible form. Fortunately, there is a solution you can apply in situations like this.

Hiding the label visually

The most common approach used is to hide the label visually but keep it available to the assistive technology devices. It can be achieved by using css to hide the element.

   <label for="example" class="visually-hidden">
      Example Label
   </label>
   <input type="text" id="example" name="example"/>  

   .visually-hidden {
      position: absolute;
      width: 1px;
      height: 1px;
      padding: 0;
      margin: -1px;
      overflow: hidden;
      clip: rect(0, 0, 0, 0);
      border: 0;
   }

Please note that using visibility: hidden will not work properly in this case. The label must be hidden by displaying it in a 1 pixel area like in the example in order for the screen readers to interpret it.

Labelling buttons

When it comes to labelling buttons, there are also a few possible solutions to make it accessible. Let's take a look at some.

Adding the label inside the element

The standard and most common approach is adding a visible text inside the button element.

   <button>Submit</button>

Using aria-label Attribute

This attribute provides an accessible name to button elements that don't have visible text, usually buttons that contain an icon.

   <button aria-label="Submit">✔️</button>

Using title Attribute

Alternatively, the text can be placed in the title attribute. This attribute can provide additional information, although it is less preferred than aria-label.

Visually hidden label

A more accessible alternative for buttons that don't have visible text is an approach similar to the visually hidden label: text that is visually hidden using CSS next to the icon.

   <button>
      <span class="visually-hidden">Submit</span> ✔️
   </button>

Using the value attribute

When using an <input type="button"> for a button element, the label can be placed in the value attribute.

   <input type="button" value="Submit" />

Using image as button

If the image button <input type="image"> is used, the label is set in the alt attribute.

   <input type="image" src="button.png" alt="Submit">

Grouping elements

Grouping form elements using the appropriate HTML elements such as <fieldset> and <legend> provides semantic meaning to assistive technologies. Screen readers can understand the relationship between form elements within the group, making it easier for the users to understand the form as well.

Grouping form elements also allows users to navigate between related fields more easily using the keyboard. Users can typically jump between form fields within the group using the Tab key, improving the overall usability and accessibility of the form.

When a group of form elements is focused, assistive technologies can announce the group's label or legend, providing users with context about the purpose of the group. This helps users better understand the structure of the form.

Grouping related fields using Fieldset and Legend

The <fieldset> element semantically groups related form fields which allows assistive technologies to interpret and understand their relationship. Visually grouped elements also make the form easier to understand and use by any user.

The <fieldset> element is used in combination with the <legend> element, which provides a caption for the group. Here is an example:

   <form>
      <fieldset>
         <legend>Personal Information</legend>
         <label for="firstName">First Name:</label>
         <input type="text" id="firstName" name="firstName">
         <label for="lastName">Last Name:</label>
         <input type="text" id="lastName" name="lastName">
       </fieldset>
       <fieldset>
         <legend>Address</legend>
         <label for="street">Street:</label>
         <input type="text" id="street" name="street">
         <label for="city">City:</label>
         <input type="text" id="city" name="city">
       </fieldset>
       <button type="submit">Submit</button>
   </form>

Radio Buttons, Checkboxes or related fields must also be grouped using <fieldset> with corresponding <legend>.

For select elements with groups of options, the <optgroup> element can be used to indicate such groups. The label attribute of the <optgroup> element is used to provide a label for the group.

Grouping related fields with WAI-ARIA

When using <fieldset> and <legend> is not an option (perhaps the design requires more custom element), the same grouping of elements can be achieved by associating the related fields using WAI-ARIA attributes. Such attributes are: aria-labelledby and aria-describedby. For example, aria-labelledby can link a group of related fields to a heading that describes their collective purpose ensuring that screen readers correctly interpret this relationship to the users.

Additionally, applying the attribute role="group" on an element such as <div> can be used to define a logical grouping of related fields, providing a semantic structure that assistive technologies can read.

Let's modify the code of the previous example by using WAI-ARIA attributes to associate related fields without using <fieldset> and <legend>:

   <form>
      <div role="group" aria-labelledby="personalInfoHeading">
         <h2 id="personalInfoHeading">Personal Information</h2>
         <label for="firstName">First Name:</label>
         <input type="text" id="firstName" name="firstName">
         <label for="lastName">Last Name:</label>
         <input type="text" id="lastName" name="lastName">
      </div>
      <div role="group" aria-labelledby="addressHeading">
         <h2 id="addressHeading">Address</h2>
         <label for="street">Street:</label>
         <input type="text" id="street" name="street">
         <label for="city">City:</label>
         <input type="text" id="city" name="city">
      </div>
      <button type="submit">Submit</button>
   </form>

Keyboard Navigation

As mentioned in this guide, enabling proper keyboard navigation is a very important step when creating accessible forms to provide a good user experience to users that use keyboard for navigating though the web. If you rely mostly on using semantic HTML elements, this is not something you need to worry about. However, when a certain custom element needs to be incorporated in a web form, you might need to follow some of the establish standards on how it should function so that you can provide proper keyboard navigation and full accessibility in your form.

Depending on the type and purpose of element, the standars can slightly differ. For example, creating a custom <select> (comobox) element might require different keyboard navigation than a <button> element would. Since this is a bit larger topic, in this guide we'll only mention a few of the most common requirements for a custom form field.

For example, each element contained in a form should be focused and interacted with using the Tab key. This is usually achieved by using the tabindex attribute. Some elements such as <select>, <input> or <button> should have a keyDown event listener on Enter key that will allow the specific option to be selected, the specific button clicked or the form to be submitted. In the same way, pressing the Escape key should dismiss open popups/menus and similar elements.

All standards, rules and patterns for specific elements can be found on the WAI-ARIA documentation.

Form validation and Errors

Effective form validation includes providing clear information about required and optional fields along with concise error messages that are accessible to screen readers and other assistive technologies.

Required fields

Required fields in forms are usually marked by using either the required attribute, the * symbol next to the label or both. While this may provide a good visual experience for some users, to make sure that all users can easily interact with the form additional attributes such as aria-required should be used, especially when using custom elements other than the semantic HTML form elements.

Most current web browsers automatically set the value of aria-required to true when the HTML5 required attribute is present.

Please note that the aria-required attribute, like all ARIA states and properties, only helps the screen readers and such devices to interpret an element as required but they have no impact on element functionality. Functionality and behaviour must be added in with JavaScript.

Displaying errors

Displaying errors in forms can be as simple as showing a certain text containing a message explaining the error for incorrect input. When using the semantic HTML elements like input with the specific type attribute such as: 'date', 'number', 'tel', 'email' etc. such message is shown by default that is already adapted for accessibility. But when a more customised error message is needed, specific attributes must also be applied to ensure accessibility.

The attributes aria-invalid and aria-errormessage should be used together to indicate an error in a form field. Both aria-invalid and aria-errormessage are applied to the input field while the aria-invalid is a boolean value indicating if there is an error or not, and aria-errormessage contains the id of the element where the error message is shown. The aria-errormessage attribute should only be used when the value of a field is not valid that is when aria-invalid is set to 'true'. If the field is valid and you include the aria-errormessage attribute, make sure the element referenced is hidden, as the message it contains is not relevant. Here is an example:

   <label for="email">*Email address:</label>
      <input
         id="email"
         type="email"
         name="email"
         aria-invalid="true"
         aria-errormessage="emailError"
      />
   <span id="emailError">Incorrect email</span>

However, the screen reader won't automatically read the error message when it appears solely based on the presence of aria-errormessage attribute. To allow announcing the error message when there is an error on change on the input or on form submit, you should apply another attribute on the element that contains the error message: aria-live. This attribute can have one of the three values:

assertive - Indicates that updates to the region have the highest priority and should be presented to the user immediately.
off (default) - Indicates that updates to the region should not be presented to the user unless the user is currently focused on that region.
polite - Indicates that updates to the region should be presented at the next graceful opportunity, such as at the end of speaking the current sentence or when the user pauses typing.

FormFusion and accessibility

If you are like me and you are not a fan of repeating code or you simply don't want to worry too much about accessibility you can always use libraries such as FormFusion that make creating forms easy and worry-free. The library offers fully accessible form elements easy to customise along with built-in validation.

Here is an example of the form mentioned previously, built using FormFusion:

   import { Form, Input } from 'formfusion';
   import './App.css';

   function App() {
      return (
         <Form>
            <fieldset>
              <legend>Personal Information</legend>
              <Input
                type="alphabetic"
                id="firstName"
                name="firstName"
                label="First name"
                classes={{ root: 'formControl', error: 'formControl__error' }}
              />
              <Input
                type="alphabetic"
                id="lastName"
                name="lastName"
                label="Last name"
                classes={{ root: 'formControl', error: 'formControl__error' }}
              />
              <Input
                type="email"
                id="email"
                name="email"
                label="Email"
                required
                classes={{ root: 'formControl', error: 'formControl__error' }}
              />
            </fieldset>
            <fieldset>
              <legend>Address</legend>
              <Input
                type="text"
                id="street"
                name="street"
                label="Street"
                classes={{ root: 'formControl', error: 'formControl__error' }}
              />
              <Input
                type="alphabetic"
                id="city"
                name="city"
                label="city"
                classes={{ root: 'formControl', error: 'formControl__error' }}
              />
            </fieldset>
            <button type="submit">Save</button>
          </Form>
        );
      }

      export default App;

FormFusion will automatically add all of the necessary attributes to make the form fully accessible. It will also handle the validation and how the errors are displayed depending on the selected validation method (validateOnChange or validateOnBlur). The final HTML structure of this code in the browser, assuming that the email field was already interacted with, will look like this:

   <form class="FormFusion">
      <fieldset>
         <legend>Personal Information</legend>
          <div class="FormFusion-Input__root formControl">
            <label for="firstName" class="FormFusion-Input__root__label">First name</label>
            <input 
              id="firstName" 
              name="firstName" 
              class="FormFusion-Input__root__field" 
              type="text" 
              pattern="^[a-zA-Z\s]+" 
              data-type="alphabetic" 
              value="" 
              aria-invalid="false" 
            />
            <span
              class="FormFusion-Input__root__error formControl__error"
              id="FormFusion-firstName-error"
              aria-live="polite">
            </span>
          </div>
          <div class="FormFusion-Input__root formControl">
            <label for="lastName" class="FormFusion-Input__root__label">Last name</label>
            <input 
              id="lastName" 
              name="lastName" 
              class="FormFusion-Input__root__field" 
              type="text" 
              pattern="^[a-zA-Z\s]+" 
              data-type="alphabetic" 
              value="" 
              aria-invalid="false" 
            />
            <span
              class="FormFusion-Input__root__error formControl__error"
              id="FormFusion-lastName-error"
              aria-live="polite">
            </span>
          </div>
          <div class="FormFusion-Input__root formControl">
            <label for="email" class="FormFusion-Input__root__label">Email</label>
            <input 
              id="email" 
              name="email" 
              required="" 
              class="FormFusion-Input__root__field" 
              type="email" 
              data-type="email" 
              value="" 
              aria-invalid="true" 
              aria-errormessage="FormFusion-email-error" 
            />
            <span
              class="FormFusion-Input__root__error formControl__error"
              id="FormFusion-email-error"
              aria-live="polite">
              Please include an '@' in the email address. 'sa' is missing an '@'.
            </span>
          </div>
        </fieldset>
        <fieldset>
          <legend>Address</legend>
          <div class="FormFusion-Input__root formControl">
            <label for="street" class="FormFusion-Input__root__label">Street</label>
            <input 
              id="street" 
              name="street" 
              class="FormFusion-Input__root__field" 
              type="text" 
              value="" 
              aria-invalid="false" 
            />
            <span
             class="FormFusion-Input__root__error formControl__error"
             id="FormFusion-street-error"
             aria-live="polite">
           </span>
          </div>
          <div class="FormFusion-Input__root formControl">
            <label for="city" class="FormFusion-Input__root__label">City</label>
            <input 
              id="city" 
              name="city" 
              class="FormFusion-Input__root__field" 
              type="text" 
              pattern="^[a-zA-Z\s]+" 
              data-type="alphabetic" 
              value="" 
            />
            <span
              class="FormFusion-Input__root__error formControl__error"
              id="FormFusion-city-error"
              aria-live="polite">
            </span>
          </div>
        </fieldset>
        <button type="submit">Save</button>
      </form>

The full code for this example can be found on Github and Stackblitz.

Conclusion

Accessibility in web forms is crucial for creating inclusive web applications. By using semantic HTML elements, following best practices, and applying ARIA roles and attributes, developers can ensure all users, including those that use assistive technologies, can easily complete forms. Well-structured forms with clear labels, logical tab order, and accessible error messages improve usability for everyone. Tools like FormFusion simplify this process by providing accessible form components. Prioritising accessibility from the start ensures a better user experience for all and contributes to a more inclusive digital world.

Resources

https://developer.mozilla.org/en-US/docs/Web/Accessibility

https://www.w3.org/WAI/ARIA/apg/patterns/

https://www.w3.org/WAI/standards-guidelines/aria/

Exploring React’s Latest extensions to forms

Sara — Thu, 14 Mar 2024 08:08:11 +0000

React 19 brings exciting enhancements to form handling. It allows developers greater control over user interactions and smoother form management. Let’s outline the key three features:

form now accepts a function passed as action prop. If a URL is passed, the form still behaves like the HTML form component but when a function is passed, it will handle the form submission. The function can be async and it’s called with a single argument containing the form data of the submitted form.
useFormStatus hook: Provides status information of the last form submission. Developers can leverage this hook to dynamically respond to user input and provide real-time feedback.
useFormState hook: Allows updating component state based on the result of a form action. Developers can use it to pass an existing form action function as well as an initial state and it returns new action along with the latest form state to be used.

Integrating FormFusion with React’s Latest Updates:

FormFusion (form management library) integrates with all of the React’s latest form features. React’s approach to handling a function as an action prop is the default method used in the FormFusion library via the onSubmit prop, however it also supports React’s approach out-of-the-box. Developers can use either and still get the same benefits.

While React’s form extension allows for client-side submissions, validation remains vital. FormFusion extends the form’s built-in validation by providing validation rules and intuitive error handling mechanisms. Developers can easily apply one of the 500+ validation rules FormFusion offers and bind them to form elements, ensuring data integrity and delivering user-friendly error messages.

React 19’s form enhancements, combined with FormFusion’s advanced form management capabilities, open up new opportunities for developers. By leveraging FormFusion’s validation, submission on the client-side, and useFormStatus for real-time feedback, developers can build highly performant and user-friendly forms with ease.

FormFusion: The right way to build forms in React

Efficient solution for easy form management with built-in validation, input masking, full accessibility and completely customisable look.

formfusion.dev

Automating React Component Generation with a Shell Script

Sara — Thu, 29 Feb 2024 11:26:11 +0000

React components are the building blocks of a React application. Creating them manually can be time-consuming, especially when they follow a similar structure. In this blog post, we'll explore how to automate the process of generating React components using a shell script. We'll build a script that takes a predefined template and creates components with custom names and file structure.
*This example is only for Linux or MacOS

Prerequisites

Before we begin, ensure that you have the following set up:

A working shell environment (e.g., Bash).
Node.js and npm installed on your machine.

Create a folder named template and create three files: index.js, component.css and interfaces.d.ts (if you're using typescript). If you are using scss or any other styling, create the style file according to your needs.

Step 1: Setting up the Template

First, let's set up a template file that represents the structure and content of a React component. For this simple example, we'll create a simple component that uses css for styling.

// index.js

const COMPONENT_NAME = () => { 
    return (
       <div><h1>COMPONENT_NAME</h1></div> 
    );
}; 

export default COMPONENT_NAME;

For the styling, create an empty component.css file.

In the template, we use COMPONENT_NAME as a placeholder that will be replaced with the actual component name during the generation process.

Step 2: Creating the Shell Script

Now, let's create the shell script that will generate React components based on the template.

Open a text editor and create a new file named generate-component.sh. Place the file in the root folder of your project or anywhere you want. For the example, we'll add the script in the root directory of an existing React project.

Copy and paste the following code into the file:

#!/bin/bash 

# Prompt the user to enter the path to the component template
read -p "Enter the template path: " template

# Prompt the user to enter the path where the component will be created
read -p "Enter the destination where you want to create the new component: " dest

# Prompt the user to enter the name of the component
read -p "Enter the name of the component: " component_name

The first step is to use prompt to get the necessary information about the component. The first line reads our input for the path where the template component is located. The second line, reads our input for the path where we want to create the new component, and the third line reads out input for the name of the new component. This can be case insensitive since later in the script we'll capitalize the component name.

Next we'll check whether the template folder or destination folder given by us exist. If the destination folder i.e the new component location folder doesn't exist, it is created. Add the following code in the script:

#!/bin/bash

# Check if the template folder exists
if [! -d "$template"]; then
echo "Template folder '$template' does not exist."
exit 1
fi

# Check if the destination folder exists, if not, create it
if [! -d "$dest/$component_name"]; then
mkdir -p "$dest/$component_name"
fi

Next, what we want to do is copy all contents from the template folder to the newly created component folder. Add the following commands to the script:

#!/bin/bash 

# Copy all contents from the template folder to the destination folder
cp -R "$template"/* "$dest/$component_name"

You should see the new folder created with the same files as the template.

Next, we'll improve the script a bit and make all the renaming to customize the new component.

First, we'll capitalize the component name and replace the placeholder with our new component name, and then we'll rename the component.css file to our component_name.css. If you're using scss or other, you'll need to adapt the script to use that file extention.

#!/bin/bash 

# Capitalize the first letter of the component name
first_letter = $(echo "${component_name:0:1}" | tr '[:lower:]' '[:upper:]')
capitalized_name = "${first_letter}${component_name:1}"

# rename all occurencies of COMPONENT_NAME with the capitalized component
find "$dest/$component_name" - type f - exec sed - i '' - e "s/COMPONENT_NAME/$capitalized_name/g" { } +

# rename the css file from component.css to $component_name.css
mv "$dest/$component_name/component.css" "$dest/$component_name/$component_name.css"

And finally, we'll print a success message that will tell us that the component is created successfully.

#!/bin/bash 

echo "Component '$capitalized_name' created successfully!"

Step 3: Running the Script

To run the script, open a terminal, navigate to the directory where the script file is located, and execute the following command:

sh ./generate-component.sh

Note that you might need to change the permissions to run the script. To make the file executable you can run

chmod +x generate-component.sh

Once you run the script, it will prompt you to enter the template path, the location where you want the component to be created and the component name. If you want to make the generation quicker without option to enter the path names, you can adapt the script to use pre-defined locations for the template and the components folder.

After entering the information, the script will generate a new component file based on the template, replacing the placeholder with the provided component name.

Step 4: Generating components using npm in a React project

This step covers incorporating the script in an existing React project and running it using npm.

First, place the script we created in the previous steps in the React project where you want to automate component generation. You can add it either to the root directory, in a new scripts folder etc.

Next, open the package.json file and scroll down to the "scripts" property.

Add the following code in the scripts part:

"generate-component": "sh ./generate-component.sh"

You can also name the script however you like. Save the file and you should be able to run it by running

npm run generate-component

Conclusion

In this blog post, we've explored how to create a shell script to automate the generation of React components using a predefined template. With this script, you can save time and effort by quickly generating components with a consistent structure.

Feel free to enhance the script further based on your specific requirements, such as generating additional files (e.g., stylesheets) or adding more complex logic.

Client side validation using FormFusion

Sara — Tue, 27 Feb 2024 08:40:00 +0000

Client-side validation is a fundamental aspect of web development, vital for delivering user-friendly interfaces and reinforcing the security of online platforms. It involves performing validation checks on the user’s device when filling out forms before sending the data to the server.

Why is it important?

It provides instant feedback, making the user’s experience smoother and less error-prone.
Reduces server load by minimising unnecessary server requests for invalid data.
Enhances security by limiting what the user can input, thereby preventing malicious attacks like SQL injection or cross-site scripting.

There are two different types of client-side validation that can be found on the web:

Built-in form validation: It uses HTML form validation features, requiring minimal Javascript. This results in better performance than JavaScript validation, although it is less customisable.
JavaScript validation: Coded using JavaScript, it offers complete customisation. However, it requires creating everything and may be less performant than built-in validation.

This is where FormFusion comes into play. It leverages everything built-in form validation offers plus extends the list of available validation attributes that can be used. It offers 500+ validation types.

FormFusion is a minimal yet efficient library that does not rely on any external dependencies. It is neatly packaged into familiar React components and hooks and doesn't require much learning. It is a completely free library available to use for anyone.

You can read more about what FormFusion offers here: https://formfusion.dev.
Or checkout some of the examples on Github https://lnkd.in/gnyqHTu5.

It’s important to note that client-side validation should not be viewed as a replacement for server-side validation. Server-side validation is also crucial and should always be used along with client-side validation since the network request can still be altered.

Sharing React Components Across Projects using Git Submodules

Sara — Mon, 26 Feb 2024 10:03:49 +0000

Reusing components and code is a fundamental aspect of React projects, offering developers the ability to write code once and leverage it across different parts of an application. But as projects evolve and grow, the need of reusing components and functionality across various React projects becomes increasingly apparent.

There are a few ways and platforms that offer code sharing across projects (which I will mention later), however, in this post, we explore a simple concept of code-sharing between different React projects in a more private way by using Git submodules without relying on third-party platforms or tools.

Git submodules are a feature in Git that allows you to integrate external repositories as dependencies within your project, maintaining their independence and version control.

Section 1: Setting up Git Submodules for Component Sharing

First, we'll need three different remote Git repositories. One will contain the code that we need to reuse - in this case a simple Button component, and the other two projects will be simple React apps with the Button from the shared repository.

Create three empty remote repositories using the version control tool of your choice (for example Github) named: first-app, second-app and component-library.

Then, clone the first-app and second-app locally and in each of its root directory run:

git submodule add <repository_url> <submodule_path>

where repository_url is the url of the repository you created that will contain the shared Button component, in this case component-library and submodule_path is the name of the directory that will contain the component-library repository, for this example, let's name it components.

Section 2: Creating the shared component

Next clone the component-library repository and in the root directory of the component library add a new folder button with index.js file for the component code and button.css for the styling:

// index.js

import './button.css';

function Button() {
  return (
    <button className="button">
      This is a Button component from my
      Component library
    </button>
  );
}

export default Button;

// button.css

.button {
  background-color: #E8AA42;
  padding: 10px;
  border: 0;
  border-radius: 5px;
  box-shadow: 0 8px 16px 0 rgba(0, 0, 0, 0.2), 0 6px 20px 0 rgba(0, 0, 0, 0.19);
}

Then, commit and push the changes to the remote:

git add .
git commit -m "create button component"
git push

Section 3: Using the Shared Components in the other React Project

Now that we built the shared component, let's use it in the two projects.

First we need to create the apps. Since it is a simple idea, we'll be using create-react-app to create two of the different projects that will share code.

Clone the first-app locally and in its root directory run:

npx create-react-app .

Since we already setup the submodule, we need to update it to get the latest changes we did.

git submodule update

To use the shared component, open the App.js file and import the Button component from the src/components/button folder.

Start the application with npm run start and test the changes! You should be able to see the button component.

Repeat the same process with the second-app repository.

Section 4: Managing Changes and Updates

Changes and updates can be done from any repository that uses the submodule or the submodule itself. But note that after some changes are made, you'll need to pull the changes in the repository where you'll need them before making other changes.

This is maybe one of the biggest disadvantages of using git submodules instead of code-sharing platforms, however the purpose of this post is to explain how to share code with minimum configuration while keeping your code in your private repositories without using third-party platforms. If this doesn't fit your situation you can use other tools and platforms such as Bit.de, Storybook alongside Chromatic, Styleguidist and others.

Section 5: Testing shared components in isolation (Optional)

If you also want to view and test the shared components in isolation, then you can do that by adding a little more configuration.

For this, we'll need to use a build tool that will create the environment where we'll test the shared components. There are a few options here, but this example will use Parcel as it's light and quick and easy to setup. You can also use any other build tool of your choice, whichever best fits your scenario.

First, open the component-library project and in the root directory, create the following package.json file:

{
  "name": "component-library",
  "source": "index.html",
  "scripts": {
    "start": "parcel",
    "build": "parcel build"
  },
  "devDependencies": {
    "parcel": "latest"
  }
}

󠄻󠄩󠄿
Then run the following to install parcel:

npm install --save-dev parcel

Next, since we're working with React projects we need to install react and react-dom:

npm install react react-dom

Create the entry index.html file and paste the following code:

<html lang="en">
<head>
  <meta charset="utf-8" />
  <title>My Component Library</title>
</head>
<body>
  <div id="app"></div>
  <script type="module" src="index.js"></script>
</body>
</html>

Create an index.js file and paste the following code:

import { createRoot } from "react-dom/client";
import { App } from "./App";

const container = document.getElementById("app");
const root = createRoot(container)
root.render(<App />);

And finally create the App.js file with the Button component that we want to test:

import Button from './button';

export function App() {
  return <Button />;
}

To run the application run:

npm run start

and to build run:

npm run build

These commands will build the application and write the output in dist directory.

You can then open the local server on http://localhost:1234 and you should see the Button component.

While this post does not cover the details of deploying projects, once you have successfully set up the code-sharing mechanism, you can proceed with deploying and publishing the component library on your preferred server. By doing so, you gain the ability to preview and test the shared components at any time.

Section 6: Alternatives

Some other alternatives that provide similars value are:

Bit.dev - a platform that facilitates component-driven development and component sharing across projects. It provides a centralized hub for developers to discover, share, and collaborate on reusable components. With Bit.dev, you can publish and version components, manage their dependencies, and integrate them into different projects, regardless of the framework or tooling being used. It offers features like component documentation, testing, and a package manager-like experience for sharing and consuming components.

Storybook - a popular open-source tool for developing UI components in isolation. It allows you to build and organize a library of components, view them in different states, and document their usage. Storybook supports various frameworks like React, Vue, Angular, and more.

Styleguidist - a documentation tool specifically designed for React component libraries. It helps you create living style guides and documentation by providing an interactive environment where you can showcase and test your components.

Chromatic - a tool that focuses on visual testing and UI review for component-driven development. It integrates with popular component frameworks like React, Angular, and Vue, and helps you catch UI bugs, perform visual regression testing, and collaborate with team members on component changes.

Conclusion:

While Git submodules offer a straightforward approach to code sharing, it's important to note that this approach may not be suitable for every scenario. Like any other tools and platforms, it has its own set of advantages and disadvantages. Therefore, it is crucial to thoroughly research and evaluate your specific needs before deciding on the best option for your project.

Consider factors such as the complexity of your codebase, the scale of your projects, the level of collaboration required, and the desired level of control over dependencies. Additionally, take into account the learning curve, maintenance overhead, and compatibility with your existing development workflow.

You can find the examples of this tutorial here:

mitevskasara / library

Library of cross-application UI components

LibraryUI - Cross-Application Components

Welcome to the library repository! This repository is part of an example in my blog post Share React Components Across Projects with Git Submodules showcasing how to share code between different Git repositories. It specifically contains the implementation of a reusable Button component that is used across multiple projects.

The main goal of this repository is to provide an example of how Git submodules can be leveraged to share React components (or other pieces of code) across multiple repositories, ensuring reusability and consistency.

Demo: https://library-smitevskas-projects.vercel.app/

Overview

This repository hosts the source code for a customizable Button component, written in React, which is used by multiple projects. The button is designed to be easily styled and configured according to the needs of different applications.

This repository uses Parcel as its build…

View on GitHub

mitevskasara / first-app

Created with StackBlitz ⚡️

React + Vite

This template provides a minimal setup to get React working in Vite with HMR and some ESLint rules.

Currently, two official plugins are available:

@vitejs/plugin-react uses Babel for Fast Refresh
@vitejs/plugin-react-swc uses SWC for Fast Refresh

View on GitHub

mitevskasara / second-app

second-app

This repository is part of an Example of code-sharing between different Git repositories. It uses a shared Button component from https://github.com/mitevskasara/library

View on GitHub

DEV Community: Sara

Creating Accessible Forms in React

Why is accessibility in web forms important

Semantic HTML form elements

How to create accessible forms

Placeholders

Labels

Explicitly associating labels with form fields:

Wrapping the form field in label element:

Using additional instructions aside from labels

Hiding the label

Hiding the label visually

Labelling buttons

Adding the label inside the element

Using aria-label Attribute

Using title Attribute

Visually hidden label

Using the value attribute

Using image as button

Grouping elements

Grouping related fields using Fieldset and Legend

Grouping related fields with WAI-ARIA

Keyboard Navigation

Form validation and Errors

Required fields

Displaying errors

FormFusion and accessibility

Conclusion

Resources

Exploring React’s Latest extensions to forms

Integrating FormFusion with React’s Latest Updates:

FormFusion: The right way to build forms in React

Automating React Component Generation with a Shell Script

Prerequisites

Step 1: Setting up the Template

Step 2: Creating the Shell Script

Step 3: Running the Script

Step 4: Generating components using npm in a React project

Client side validation using FormFusion

Why is it important?

There are two different types of client-side validation that can be found on the web:

Sharing React Components Across Projects using Git Submodules

Section 1: Setting up Git Submodules for Component Sharing

Section 2: Creating the shared component

Section 3: Using the Shared Components in the other React Project

Section 4: Managing Changes and Updates

Section 5: Testing shared components in isolation (Optional)

Section 6: Alternatives

Conclusion:

mitevskasara / library

Library of cross-application UI components

LibraryUI - Cross-Application Components

Table of Contents

Overview

mitevskasara / first-app

Created with StackBlitz ⚡️

React + Vite

mitevskasara / second-app

second-app