This guide provides a high-level overview of how to utilize the Git interactive rebase to squash and reword commit messages, without diving into the many intricacies of Git.

What I’m Using:

• Windows Command Prompt

Scenario:

We have a feature that we branched off our main feature branch with four commits ahead that we want to squash down into one commit. We also want this one to have a meaningful name so that we can see exactly what we did when we view the history.

Note: the branch is called squash-example

Tip: If you make a mistake, typing in :u undoes the last change you did in Vi Improved (Vim).

Step 0 – Update and Backup (Optional)

Make sure you have the latest versions of both branches by doing a git fetch and git pull.

If you aren’t comfortable with the Git interactive rebase yet, I suggest making a backup. You can do this by simply creating a new branch based on the one we want to squash. You can do this with git checkout command in your command prompt as shown below:

.dmcinfo.com/wp-content/uploads/2025/05/27162644/Git-checkout-command-in-command-prompt.png" alt="Git checkout command in command prompt" />

.dmcinfo.com/wp-content/uploads/2025/05/27162644/Git-checkout-command-in-command-prompt.png" alt="Git checkout command in command prompt" />

Step 1 – Check Out the Branch You Want to Squash

First, do a git status to verify you are in the correct branch. We can then begin the interactive rebase process in two ways. First, we can specify the number of commits we want to rebase from our current state:

git rebase -i HEAD~<x>

git rebase -i HEAD~<x>

For our example, we’ll replace ~<x> with git rebase -i HEAD~5 to show us the last five commits.

The second way is to specify the sha1: 

git rebase -i <commit-sha1>

git rebase -i <commit-sha1>

Doing so will display all the commits after the specified sha1.

Step 2 – Rename the Commit We Want to Keep

First, press S to enter insert mode. Anything marked as “pick” will be kept as a commit in the history. In our case, we want to keep the very first item, which is the commit where we branched off from our master branch.

In insert mode, replace pick with reword to mark the commit we want to rename.

Once that is marked, you will be brought to a follow-up edit screen to replace the name of the commit, which will be covered in Step 4. If your main goal is to rename a commit, you can skip to Step 4 now, otherwise, we’ll cover the command for squashing in the following step.

Step 3 – Select the Commits to Squash

Like in text editors, you can highlight a chunk of text in Vim and replace them simultaneously.

Hit ESC to exit insert mode, then press CTRL + SHIFT + V to enter visual block mode and highlight all the picks that we want to squash. Press C to confirm our selection.

Type in squash then hit ESC, and it should replace all the picks to squash.

Step 4 – Save Changes

You can hit ESC and enter  to save and exit the editor. This should bring you to the rewrite commit message screen where you can edit it one last time:

Again, we can repeat  to confirm the reword and save our rebase. If you’re only looking to rename a commit, then you can stop here. However, we can see that the editor is now telling us our next command is ‘squash’—which allows you to edit commit messages.

Step 5 – Squash and rewording commit messages

When we squash, we can change the overall commit message either by editing them or commenting them out. Once we edit it, we save it again with

In this first example, I do not comment out any commit messages:

The log looks something like this:

On this screen, I comment out the other changes so they do not show up in the commit message:

After saving, you should see a message like this:

Step 6 – Force Push

The last thing we want to do is run the command:

git push --force

git push --force

This pushes up our changes and overwrites the history in the remote repository.

Step 7 – Verify That Everything Matches Up.

We can again check git log and see that instead of four commits, we only have the one.

That should cover the bare minimum as clearly and quickly as possible for squashing commits and applying a rewrite. Having a well-maintained and readable history allows for easier development down the line, so taking a few moments to make commits look clean is something you definitely want to do.

Learn more about DMC’s Application Development expertise and contact us for your next project.

The post Git as Fast as Possible: Reword and Squash appeared first on DMC, Inc..

What is @pnp/sp?

@pnp is an open-source library that can be utilized in JavaScript, NodeJS, and SharePoint Framework projects to accomplish many things that we would need to write custom REST requests for. @pnp/sp pertains specifically to SharePoint and is one part of the @pnp collection. 

Why Use @pnp/sp?

Using a library is advantageous because it abstracts the REST queries and puts them in readable, understandable code. We also get the benefits of type-checking as @pnp returns defined objects, as well as abstracting some of the nitty-gritty of REST Requests away.

Simply put, @pnp/sp makes performing requests a lot easier and should be utilized if available. A major advantage of this library is that it also offers IntelliSense, a robust code-completion aid developed by Microsoft. This means we can quickly see many different properties and methods, as opposed to looking up every single command and object in the documentation.

For example, VSCode IntelliSense allows for autocomplete in the image below.

It also shows the annotated documentation for functions.

Examples and Use Cases

1. Retrieving a List of Site Users From SharePoint

Let’s say we need to retrieve a list of all users for a given SharePoint site. We can utilize the @pnp/sp/webs in conjunction with @pnp/sp/site-users to retrieve a list of siteUsers for a given site:

const users = await web.siteUsers();

const usersFiltered = await web.siteUsers.filter(`startswith(LoginName, '${encodeURIComponent("i:0#.f|m")}')`)();

2. Getting the Current User’s Groups

We can use @pnp/sp/site-groups to easily find, delete, update, or even add a site group to a user. In this example, we’ll retrieve a list of groups the current user belongs to.

As we can see in the IntelliSense, it provides us with some properties of each group, such as ID or description, which we can then use for our code.

3. Adding a File to a Folder in SharePoint

If we need to add files, we can do so by first using a combination of @pnp/sp/folders to navigate to the folder we want to use. Once we’ve found the correct folder, we can simply use @pnp/sp/files to add the files.

const result = await web
                    .getFolderByServerRelativeUrl("https://myExample.sharepoint.come/myFiles")
                    .files.add("MyNewFile.txt", file, false);
                return result;

These are three basic examples of some common use cases in development. However, there are plenty of other libraries in @pnp/sp that can achieve many things that we would otherwise have to create our own queries for. @pnp/sp is a great resource with a wide variety of functionalities offered to SharePoint Framework developers. I suggest visiting their documentation for more examples and uses of this library.

Learn more about DMC’s SharePoint expertise and contact us to get started on your next project.

The post Easily Access SharePoint Content Using @pnp/sp appeared first on DMC, Inc..

1. Ask as Many Questions as Possible

One of the fastest ways of getting familiarized with legacy code is to simply ask a lot of questions from the previous developer if that is possible. Starting off, it might not be possible to know of all the specific questions someone may have about the code. Ideally, you should try to ask questions about the overall structure and algorithm of the program. This helps create a more defined mental map and allows you to quickly identify places to edit/change in the event you need to implement new features.

It is also valuable to ask about previous places the developer had difficulty in or code they believe is not as robust. There is no reason to try and resolve an issue twice if the previous developer already identified the problem. Simply keeping this information in the back of your mind whenever you write a new code that interacts with that section can help to debug smoother. However, not everyone can have the luxury of having the previous developer available, in which case you can try your luck with the client or userbase actively using the code for any history they may remember, in regards to bugs or already implemented fixes.

If either way is not possible, there are still many things you can do to make working with legacy code a lot less painful, which I will cover in the following tips.

2. Document Call Hierarchy

When working with a large spanning piece of code, it can get difficult tracing down how a function or procedure works, especially when you have to make edits that may have far extending effects that you need to account for. You can create a simple call hierarchy by noting down the specific function you call, and all the subsequent calls that function makes in sequential order.

For instance, if you have a function Run which calls function GetItems and later on SortItems, you can keep track of the process and all the necessary places you have to change the code to maintain functionality. This is especially true if there are further calls in the subfunctions such as GetItems calling its own subfunction of LoadFile. This process of documenting the hierarchy should be kept relatively simple and easy to read, something as simple as the name of the function should work.

• Run
  • GetItems
    • LoadFile
  • SortItems
• …

A key point is that you should not go in-depth as to what each function does, especially if you are looking at the code for the first time. The main reason you want to avoid that is that by documenting excessively, you might develop biases or assumptions that are initially inaccurate.

After working with the legacy code, you’ll discover nuances and small details that you may have overlooked in the first pass through that change how the process runs, like a flag being set on a variable or specific timings that may have been missed.

Keeping the documentation of hierarchy simple will allow you to identify and understand the structure, but allow you to avoid common pitfalls and red herrings that comes from not being unacquainted with the code. As you get familiarized with the code, you can develop more diagrams and discover how your new or edited code interacts with the rest of the system.

3. Double Check Your Assumptions

A subsequent tip that was briefly touched on is that you may develop assumptions after going through the first pass of the code. When bugs occur, one of the first things you should immediately look at when you have reached a dead-end is to re-check your initial assumptions. In most cases, a lot of bugs that come from editing legacy code comes from a misunderstanding over what you believe something does, and what it actually does. After reviewing changes that you implemented and making sure it works, the next step should always be to double-check assumptions that you previously made.

For example, this can occur in conditional statements, where you believe the code would go into a specific conditional branch but instead goes somewhere else entirely. Another place this can occur is in function calls that have side effects that might have been missed, setting flags in other places of the code.

4. Testing, Testing, Testing

This might be obvious, but after you make any changes, extensive testing should be done to guarantee not only that the new function works, but that everything else behaves as it did before the changes. Setting up unit testing and functional testing ahead of time can go a long way in saving time and effort by having a set of pre-defined test suites to verify that everything is working in tip-top shape.

In cases where the code is too old and setting up testing cases do not make sense, setting up logging in as many places as possible can be key in debugging potential issues. Debugging and viewing the watch screen is very viable. Having logging sequences in place for each event is just as valuable as an issue could occur and you aren't around to watch it happen, logging will help narrow down exactly where the issue occurred, and some valuable replicable context that can help track down the issue.

For each new addition, there should be at the very least, a new line of logging or monitoring that should stay until it has been verified that the program is running consistently.

5. Start Small and Go Slow

Starting small goes hand in hand with testing everything. Sometimes, a change doesn’t require knowing every single nook and cranny of a large piece of code. In other cases, it requires changing code in many different places that you may not have been identified yet. It can get overwhelming changing code in multiple places and remembering to do it all.

Making sure to go slow and looking at one section of code at a time can reduce a lot of mistakes. This isn’t just applicable to legacy code but can also be applied to most aspects of coding.

6. Document Everything

Lastly, you want to document everything. From the discoveries you’ve made at looking at the legacy code, to the new additions that you’ve added. This can as simple as notes that you can print out, or comments in the code itself. Documentation not only helps you but also helps future developers that may have to work on this software. This information will create stability for yourself when months down the line, you may have to go back and look at your own work. By setting it in a sort of electronic stone, it legitimizes the changes done to the project, beyond just being key points to remember internally.

The post 6 Tips for Working with Legacy Code That You Did Not Write appeared first on DMC, Inc..

For this tutorial, we will be leveraging the use of LINQ to make sorting quite painless, and optionally Material-UI for styling the table. At the very end, I will also briefly describe a way of implementing this table without using LINQ and only using base React.

Tools Used in this Blog:

• LINQ 
• Material-UI (Optional)
• Basic React hooks
• Functional React

Setup

First, we need some data. For the purposes of this example, I just created some dummy data that we can sort. I also defined an interface for the data type and an enum for departments that a person can belong to.

 const dataList=[
    {name: 'Ryan H.',   hours: 30, startDate: new Date('2019-01-14'), department: Department.Marketing},
    {name: 'Ariel P.',  hours: 22, startDate: new Date('2017-03-12'), department: Department.Sales},
    {name: 'Ryan Y.',   hours: 31, startDate: new Date('2015-09-12'), department: Department.Marketing},
    {name: 'Ed T.',     hours: 22, startDate: new Date('2017-03-12'), department: Department.Engineering},
    {name: 'Matt G.',   hours: 30, startDate: new Date('2017-03-12'), department: Department.Marketing},
    {name: 'Olivia H.', hours: 32, startDate: new Date('2018-05-10'), department: Department.Engineering}] as TableData[];

 const dataList=[
    {name: 'Ryan H.',   hours: 30, startDate: new Date('2019-01-14'), department: Department.Marketing},
    {name: 'Ariel P.',  hours: 22, startDate: new Date('2017-03-12'), department: Department.Sales},
    {name: 'Ryan Y.',   hours: 31, startDate: new Date('2015-09-12'), department: Department.Marketing},
    {name: 'Ed T.',     hours: 22, startDate: new Date('2017-03-12'), department: Department.Engineering},
    {name: 'Matt G.',   hours: 30, startDate: new Date('2017-03-12'), department: Department.Marketing},
    {name: 'Olivia H.', hours: 32, startDate: new Date('2018-05-10'), department: Department.Engineering}] as TableData[];

Our interface is TableData. We have an enum called Departments which lists the available department’s people may be in:

interface TableData{
    name: String,
    hours: number,
    startDate: Date,
    department: Department
}

enum Department{
    Marketing = 'Marketing',
    Sales = 'Sales',
    Engineering = 'Engineering',
}

interface TableData{
    name: String,
    hours: number,
    startDate: Date,
    department: Department
}

enum Department{
    Marketing = 'Marketing',
    Sales = 'Sales',
    Engineering = 'Engineering',
}

It’s important to note that this interface and enum is solely for structuring our table, and not for sorting. We will eventually add another interface and enum for sorting.

For the case of simulation, I’ll be placing the data into another file and returning it from a function call called fetchData.

export const fetchData = () => { return dataList;}

export const fetchData = () => { return dataList;}

For the table, we’ll be using Material-UI, but this method will absolutely work with just a regular table. If you don’t want to use Material-UI tables, just replace the tags with the corresponding ones below. Everything but TableBody has a corresponding tag which just contains a collection of <tr> tags.

Now we pull our data from the other file by calling fetchData, set up the appropriate table headers, and map our data to the corresponding table cells. For the sake of keeping clean code, I moved the sortable table headers to another component, so our code should look somewhat like this:

import React from "react";
import {Table, TableRow, TableCell, TableBody } from '@material-ui/core';
import { fetchData, TableData } from "./fetchData";
import { SortableHeader } from "./sortableTableHeader";

export const TableExample = () => {
    const dataList = fetchData();
    return(
        <div>
            <Table>
                <SortableHeader/>
                <TableBody>
                    {dataList.map((data) => { return(
                        <TableRow>
                            <TableCell>
                                {data.name}
                            </TableCell>
                            <TableCell>
                                {data.hours}
                            </TableCell>
                            <TableCell>
                                {data.startDate.toDateString()}
                            </TableCell>
                            <TableCell>
                                {data.department}
                            </TableCell>
                        </TableRow>
                        )})}
                </TableBody>
            </Table>
        </div>
    )
}

import React from "react";
import {Table, TableRow, TableCell, TableBody } from '@material-ui/core';
import { fetchData, TableData } from "./fetchData";
import { SortableHeader } from "./sortableTableHeader";

export const TableExample = () => {
    const dataList = fetchData();
    return(
        <div>
            <Table>
                <SortableHeader/>
                <TableBody>
                    {dataList.map((data) => { return(
                        <TableRow>
                            <TableCell>
                                {data.name}
                            </TableCell>
                            <TableCell>
                                {data.hours}
                            </TableCell>
                            <TableCell>
                                {data.startDate.toDateString()}
                            </TableCell>
                            <TableCell>
                                {data.department}
                            </TableCell>
                        </TableRow>
                        )})}
                </TableBody>
            </Table>
        </div>
    )
}

import React from "react";
import { TableHead, TableRow, TableCell } from "@material-ui/core";

export const SortableHeader = () => {
    return (
        <TableHead>
            <TableRow>
                <TableCell>Name</TableCell>
                <TableCell>Hours</TableCell>
                <TableCell>Date</TableCell>
                <TableCell>Department</TableCell>
            </TableRow>
        </TableHead>
    );
};

import React from "react";
import { TableHead, TableRow, TableCell } from "@material-ui/core";

export const SortableHeader = () => {
    return (
        <TableHead>
            <TableRow>
                <TableCell>Name</TableCell>
                <TableCell>Hours</TableCell>
                <TableCell>Date</TableCell>
                <TableCell>Department</TableCell>
            </TableRow>
        </TableHead>
    );
};

Which outputs something like this:

Implementation

Our overall goal is to create an ordered queue of sorting configurations that will apply each sorting in order through the use of LINQ to our data. We will then update our data list which will be re-rendered and displayed in the desired sorting configuration.

Step 1: Define a Sorting configuration

A sorting configuration is essentially an object that has two things. The property/column of the list that we’re trying to sort, and the sorting type such as ascending or descending. Since our rows are all the same object type: TableData, we can use keyof TableData to get all the properties/columns of our table. The only thing we’d have to do is make an enum of the different sorting types that we need, in this case we’ll stick with the standard ascending/descending.

interface SortingConfiguration{
    propertyName: keyof TableData,
    sortType: SortingType,
}

enum SortingType{
    Ascending,
    Descending,

interface SortingConfiguration{
    propertyName: keyof TableData,
    sortType: SortingType,
}

enum SortingType{
    Ascending,
    Descending,

Step 2: Utilize useState to Maintain a List of our Sorting Configurations

If you’ve never used useState, it’s a React hook that returns an array of two things: the first being the state of an object that is being maintained. The second is basically a function/dispatch that you can call to change the state. Here we’re initializing our list of sorting configurations to be an empty list since we want to start off with an unsorted table.

Note: If you do want a table column to be sorted by default, all you would need to do is add a SortConfiguration object in between the square brackets

  const [sortConfig, updateSortConfig] = useState<SortingConfiguration[]>([]);
    //Below is an example of sorting columns by name by default.
    const [initializedSortConfig, updateInitSortConfig] = useState<SortingConfiguration[]>([
        {propertyName: 'name', sortConfig: SortingType.Descending}
    ]);

  const [sortConfig, updateSortConfig] = useState<SortingConfiguration[]>([]);
    //Below is an example of sorting columns by name by default.
    const [initializedSortConfig, updateInitSortConfig] = useState<SortingConfiguration[]>([
        {propertyName: 'name', sortConfig: SortingType.Descending}
    ]);

Step 3: Create a Function That Adds, Modifies, and Removes Our Sorting Configurations

Most sortable headers are clickable headers that switch between a cycle of unsorted -> descending -> ascending -> unsorted -> etc, but there are many different orders or ways in which you may wish to set this up. You should be able to create your own custom function that edits the sorting configuration given three basic criteria:

1. Add a sorting configuration to a column when there is not an existing configuration
2. Modify a sorting configuration when there is an existing configuration
   • For example, going from descending to ascending, or vice versa
3. Provide a way to remove a sorting configuration
   • This can be a part of criteria #2, but it is important enough to warrant its own criteria

We’ll be following a cycle of unsorted -> descending -> ascending -> unsorted -> etc… for the purposes of this guide.

We will be making a function called sortBy that will take in a key of TableData. Basically, whenever we call sortBy on a given property/column, it should automatically fulfill our three criteria: add a new configuration when we don’t have one, alter a configuration if we do, and remove a configuration when we need to. We wrap it in a useCallback because, in the next step, we will pass this function down to a prop.

So our basic structure looks like this:

 const sortBy = useCallback(
        (propertyName: keyof TableData) => {
            let pendingChange = [...sortConfig];
            const index = pendingChange.findIndex((config) => 
       						config.propertyName === 	propertyName)
            if(index > -1){
                // Existing configuration
            } else {
                // No existing configuration
            }
            updateSortConfig([...pendingChange]);
        },
        [sortConfig]
    )

 const sortBy = useCallback(
        (propertyName: keyof TableData) => {
            let pendingChange = [...sortConfig];
            const index = pendingChange.findIndex((config) => 
       						config.propertyName === 	propertyName)
            if(index > -1){
                // Existing configuration
            } else {
                // No existing configuration
            }
            updateSortConfig([...pendingChange]);
        },
        [sortConfig]
    )

We use the spread operator to make a copy of the sortConfiguration. Then we use findIndex to search our copied list and see if there is an existing configuration that’s in our list. We’ll be using a lot of the spread operator, so if you aren’t experienced with using it, you can see more examples in this blog by Jacob Bruce. Now that we have the basic structure laid out, let’s address the first criteria. This one is relatively simple since all we’re doing is adding a sorting configuration given the propertyName that was passed in:

  if(index > -1){
                // Existing configuration
            } else {
                pendingChange = [
                    ...pendingChange,
                    { propertyName: propertyName, sortType: SortingType.Descending },
                ];
            }

  if(index > -1){
                // Existing configuration
            } else {
                pendingChange = [
                    ...pendingChange,
                    { propertyName: propertyName, sortType: SortingType.Descending },
                ];
            }

Here we use the spread operator to push a new sorting configuration to the end of the queue.

Now we have to handle our second and third criteria which you can only do on an existing configuration. We can remove extra code if instead of modifying we save the existing sort direction, remove the current configuration and lastly, add in a new configuration if it’s necessary to ‘modify’. Technically, our modification is removing a configuration of a property and adding in the same property back, but with a different sortType, but doing it this way makes it so we don’t have to write two similar code branches.

In short, we use our index we found to store the existing sort type. We then remove that configuration using splice. Lastly, we use our saved sorting type to determine if we needed to add a new configuration. In this example, we check if it’s Descending, and if that’s the case, we change that sortType to Ascending. Note how, if the sorting type is Ascending, we do not ‘modify’ our sorting configuration list, but rather just let the code remove the configuration.

Put together we have:

 const sortBy = useCallback(
        (propertyName: keyof TableData) => {
            let pendingChange = [...sortConfig];
            const index = pendingChange.findIndex((config) => 
                                    config.propertyName === propertyName)
            if(index > -1){
                //Save the sortType
                var currentSortType = pendingChange[index].sortType;
                //Remove existing config
                pendingChange.splice(index, 1);
                //check if the sort type we saved is descending
                if (currentSortType === SortingType.Descending) {
                    pendingChange = [
                        ...pendingChange,
                        { propertyName: propertyName, sortType: SortingType.Ascending },
                    ];
                }
            } else {
                pendingChange = [
                    ...pendingChange,
                    { propertyName: propertyName, sortType: SortingType.Descending },
                ];
            }
            updateSortConfig([...pendingChange]);
        },
        [sortConfig]
    )

 const sortBy = useCallback(
        (propertyName: keyof TableData) => {
            let pendingChange = [...sortConfig];
            const index = pendingChange.findIndex((config) => 
                                    config.propertyName === propertyName)
            if(index > -1){
                //Save the sortType
                var currentSortType = pendingChange[index].sortType;
                //Remove existing config
                pendingChange.splice(index, 1);
                //check if the sort type we saved is descending
                if (currentSortType === SortingType.Descending) {
                    pendingChange = [
                        ...pendingChange,
                        { propertyName: propertyName, sortType: SortingType.Ascending },
                    ];
                }
            } else {
                pendingChange = [
                    ...pendingChange,
                    { propertyName: propertyName, sortType: SortingType.Descending },
                ];
            }
            updateSortConfig([...pendingChange]);
        },
        [sortConfig]
    )

Now the loop of unsorted -> descending -> ascending -> unsorted -> etc… is complete.

Step 4: Attach Our Function to the Table Headers

Now that we created our function, we need to attach it to table headers and make them something we can click. Since we’re passing down our props to our SortableTableHeader don’t forget to export our interfaces and enums to avoid errors. We’ll need to pass two things to our SortableTableHeader the first is our newly created sortBy function, and the second is our current sortConfig which will be used for arrow indicators to show what direction we’re sorting.

<Table>
    <SortableHeader 
          sortBy={sortBy} 
          sortConfig={sortConfig}
          />
      <TableBody>
		………
</Table>
</TableBody>
</pre>

<pre class="brush:js">
interface SortableHeaderProps{
    sortBy: (string: keyof TableData) => void;
    sortConfig: SortingConfiguration[];
}

export const SortableHeader = ({sortBy, sortConfig}:SortableHeaderProps) => {
    return (
        <TableHead>
            <TableRow>
                <TableCell>Name</TableCell>
                <TableCell>Hours</TableCell>
                <TableCell>Date</TableCell>
                <TableCell>Department</TableCell>
            </TableRow>
        </TableHead>
    );
};

<Table>
    <SortableHeader 
          sortBy={sortBy} 
          sortConfig={sortConfig}
          />
      <TableBody>
		………
</Table>
</TableBody>
</pre>

<pre class="brush:js">
interface SortableHeaderProps{
    sortBy: (string: keyof TableData) => void;
    sortConfig: SortingConfiguration[];
}

export const SortableHeader = ({sortBy, sortConfig}:SortableHeaderProps) => {
    return (
        <TableHead>
            <TableRow>
                <TableCell>Name</TableCell>
                <TableCell>Hours</TableCell>
                <TableCell>Date</TableCell>
                <TableCell>Department</TableCell>
            </TableRow>
        </TableHead>
    );
};

To keep code DRY, I’ll be making a list of the columns that we want, and the TableData property they correspond to. This way, we can map over the function without copy/pasting TableCell four times.

const tableColumn = [
        {label:'Name', property:'name'},
        {label:'Hours', property:'hours'},
        {label:'Date', property:'startDate'},
        {label:'Department', property:'department'}
        ] as TableColumn[];

const tableColumn = [
        {label:'Name', property:'name'},
        {label:'Hours', property:'hours'},
        {label:'Date', property:'startDate'},
        {label:'Department', property:'department'}
        ] as TableColumn[];

Now, we can attach our function to the tablecell by adding the onClick prop to the TableCell, and pass in the corresponding property for the column being mapped. We can also apply our CSS stylings to the table cells at this point. Here I use Material UI’s styling solution, but the key point when doing this is setting the CSS property cursor: ‘pointer’.

 <TableHead>
            <TableRow>
                {tableColumn.map((column, index) => {
                    return(
                        <TableCell key={index} 
                            className={headerCell}
                            onClick={()=>sortBy(column.property)}
                        >
                            {column.label}
                        </TableCell>
                    )
                })}
            </TableRow>
        </TableHead>

 <TableHead>
            <TableRow>
                {tableColumn.map((column, index) => {
                    return(
                        <TableCell key={index} 
                            className={headerCell}
                            onClick={()=>sortBy(column.property)}
                        >
                            {column.label}
                        </TableCell>
                    )
                })}
            </TableRow>
        </TableHead>

Lastly, we’ll add an indicator arrow through conditional rendering to show the current sort direction. To do this, we have two conditionals to check what we render. The first is checking if there is an existing sorting configuration, and the second is checking if the sortType is ascending/descending. To make this easier, we can write a simple function that gets us the current sortType from the sorting configuration and returns an appropriate icon.

 const getSortDirection = (property:keyof TableData) => {
        var config = sortConfig.find((sortConfig) => sortConfig.propertyName === property)
        if(config){
            if(config.sortType === SortingType.Descending){
                return <ArrowDownwardIcon/>
            }
            else {
                return <ArrowUpwardIcon/>
            }
        }
        return null;
    }

 const getSortDirection = (property:keyof TableData) => {
        var config = sortConfig.find((sortConfig) => sortConfig.propertyName === property)
        if(config){
            if(config.sortType === SortingType.Descending){
                return <ArrowDownwardIcon/>
            }
            else {
                return <ArrowUpwardIcon/>
            }
        }
        return null;
    }

Our SortableTableHeader code should now look like this, with the appropriate CSS stylings applied in place of headerCell and sortLabel, if you aren’t using Material-UI.

export const SortableHeader = ({sortBy, sortConfig}:SortableHeaderProps) => {

    const {headerCell, sortLabel} = useStyles();

    const tableColumn = [
        {label:'Name', property:'name'},
        {label:'Hours', property:'hours'},
        {label:'Date', property:'startDate'},
        {label:'Department', property:'department'}
        ] as TableColumn[];

    const getSortDirection = (property:keyof TableData) => {
        var config = sortConfig.find((sortConfig) => sortConfig.propertyName === property)
        return config ?
            config.sortType === SortingType.Descending ?
                <ArrowDownwardIcon/>
                :<ArrowUpwardIcon/>
            :null
    }

    return (
        <TableHead>
            <TableRow>
                {tableColumn.map((column, index) => {
                    return(
                        <TableCell key={index} 
                            className={headerCell}
                            onClick={()=>sortBy(column.property)}
                        >
                            <span className={sortLabel}>
                                {column.label}
                                {getSortDirection(column.property)}
                            </span>
                        </TableCell>
                    )
                })}
            </TableRow>
        </TableHead>
    );
};

export const SortableHeader = ({sortBy, sortConfig}:SortableHeaderProps) => {

    const {headerCell, sortLabel} = useStyles();

    const tableColumn = [
        {label:'Name', property:'name'},
        {label:'Hours', property:'hours'},
        {label:'Date', property:'startDate'},
        {label:'Department', property:'department'}
        ] as TableColumn[];

    const getSortDirection = (property:keyof TableData) => {
        var config = sortConfig.find((sortConfig) => sortConfig.propertyName === property)
        return config ?
            config.sortType === SortingType.Descending ?
                <ArrowDownwardIcon/>
                :<ArrowUpwardIcon/>
            :null
    }

    return (
        <TableHead>
            <TableRow>
                {tableColumn.map((column, index) => {
                    return(
                        <TableCell key={index} 
                            className={headerCell}
                            onClick={()=>sortBy(column.property)}
                        >
                            <span className={sortLabel}>
                                {column.label}
                                {getSortDirection(column.property)}
                            </span>
                        </TableCell>
                    )
                })}
            </TableRow>
        </TableHead>
    );
};

If everything went correctly, you should now see table headers with arrows showing the corresponding sort directions on them.

Step 5: Applying the Sort Configuration with LINQ

The last step is to finally apply the sorting in order.

We’ll be defining our variable, ‘sortedRows’ by a useMemo function, with a dependency on sortConfig and dataList, so that we re-render our sortedRows whenever our sort configuration changes, or whenever our data list changes.

Next, we can turn our standard list of items into a LINQ list by putting it in a LINQ.from call. Now, in order to leverage LINQ’s sorting functionality, our list of values has to be an IOrderedEnumerable object. We can get this by applying a basic orderBy function to our LINQ and passing it a lambda that just returns one, which basically says sort this by the key ‘nothing’, and return ‘1’ in all cases to avoid doing any comparison. This returns us our list in an unmodified order, but as an IOrderedEnumerable type.

 //Set up default ordering
        let sorted = linq.from(dataList).orderBy(() => 1);

 //Set up default ordering
        let sorted = linq.from(dataList).orderBy(() => 1);

The reason why we want to do this is so we can apply multiple sorts on top of this which is possible by using the thenBy and thenyByDescending functions from LINQ and using those requires an IOrderedEnumerable. Now that that’s established, we can loop through each of the sorting configurations in order and check which sort type we’re applying.

let sorted = linq.from(dataList).orderBy(() => 1);
        //Loop through the queue
        sortConfig.forEach((sortConfig) => {
            if (sortConfig.sortType === SortingType.Ascending) {
                //Ascending sorting
            } else {
                //Descending sorting
            }
        });

let sorted = linq.from(dataList).orderBy(() => 1);
        //Loop through the queue
        sortConfig.forEach((sortConfig) => {
            if (sortConfig.sortType === SortingType.Ascending) {
                //Ascending sorting
            } else {
                //Descending sorting
            }
        });

Our last step in sorting is to apply the thenBy conditional on the corresponding property, and LINQ will handle the complicated sorting for us, including comparing integers, strings, and dates. You can read more on LINQ functions, and even pass in your own comparable which is useful for handling sorting between more complex types, but in the case of this guide, we’ll just stick to basic sorting since we’re handling primitive types. If it’s descending, we can use thenByDescending which makes things easier.

 if (sortConfig.sortType === SortingType.Ascending) {
                sorted = sorted
                    .thenBy((dataRow) => dataRow[sortConfig.propertyName]);
            } else {
                sorted = sorted
                    .thenByDescending((dataRow) => dataRow[sortConfig.propertyName]);
            }

 if (sortConfig.sortType === SortingType.Ascending) {
                sorted = sorted
                    .thenBy((dataRow) => dataRow[sortConfig.propertyName]);
            } else {
                sorted = sorted
                    .thenByDescending((dataRow) => dataRow[sortConfig.propertyName]);
            }

In the code above, you see that the arguments for the lambda are an element of the sortedList. In this case, I named it dataRow because each item in the sorted is a LINQ from our dataList so we can think of it as one row. It then selects a corresponding key via the propertyName of our sortConfig, which as you recall is either “name”, “hours”, “startDate’, and “department”. In short, this is us targeting that specific column.

Now, if you have null data, Javascript will run into the null comparison issue, which will mess up the sorting. A quick workaround I do is to sort all the data that is null on the bottom, but prefacing this thenBy with another thenBy that basically checks if the property is null.

Here we return -1 when the data is null which means the object is ‘less than’ an object which does have data, and is sorted lower on the list.

The last thing we need to do is to turn our LINQ into an array by calling .toArray(), and returning that value so that our sortedRows has an array of a sorted dataList. Putting it all together, we have this:

const sortedRows = useMemo(() => {
        //Set up default ordering
        let sorted = linq.from(dataList).orderBy(() => 1);
        //Loop through the queue
        sortConfig.forEach((sortConfig) => {
            if (sortConfig.sortType === SortingType.Ascending) {
                sorted = sorted
                    .thenBy((dataRow) => (dataRow[sortConfig.propertyName] === null ? -1 : 1))
                    .thenBy((dataRow) => dataRow[sortConfig.propertyName]);
            } else {
                sorted = sorted
                    .thenByDescending((dataRow) =>
                    dataRow[sortConfig.propertyName] === null ? -1 : 1
                    )
                    .thenByDescending((dataRow) => dataRow[sortConfig.propertyName]);
            }
        });
        return sorted.toArray();
    }, [sortConfig, dataList]);

const sortedRows = useMemo(() => {
        //Set up default ordering
        let sorted = linq.from(dataList).orderBy(() => 1);
        //Loop through the queue
        sortConfig.forEach((sortConfig) => {
            if (sortConfig.sortType === SortingType.Ascending) {
                sorted = sorted
                    .thenBy((dataRow) => (dataRow[sortConfig.propertyName] === null ? -1 : 1))
                    .thenBy((dataRow) => dataRow[sortConfig.propertyName]);
            } else {
                sorted = sorted
                    .thenByDescending((dataRow) =>
                    dataRow[sortConfig.propertyName] === null ? -1 : 1
                    )
                    .thenByDescending((dataRow) => dataRow[sortConfig.propertyName]);
            }
        });
        return sorted.toArray();
    }, [sortConfig, dataList]);

You should now have a functioning table with multiple sortable headers! A key thing to note is that you can pass a comparable to the thenBy function instead of just selecting by key. If for some reason things are not sorting as they should, that should be the first point of debugging.

Bonus: Sorting without LINQ

If you’ve made it this far, or just skipped ahead to this section, we’ll be going over the basics of sorting rows based on multiple headers by just using basic comparators.

Comparators are just functions that take in two objects and return a number depending on how they relate to one another. A zero means they’re equal, positive numbers are greater, and negative numbers are less. Now let’s work on converting our sorting function to one that doesn’t use LINQ at all.

Sorting multiple columns may seem complex, but in practice, it’s not really that difficult. Given a list of sorting configurations in the desired order, all you have to check is if the first comparator results in an equality, use the next comparator in order. If we have a list of {a ,1 }, {a , 2}, and {b, 1}. Sorting by the first column results in the equality of a’s. All we’d need to do is check our second column’s comparator to determine what order they should go in.

In this guide, we’ve already implemented a function that can order our sort configurations for us. All we need to do is add a comparators to our SortConfiguration so we can keep track of which compare function we need to use.

export interface SortingConfiguration{
    propertyName: keyof TableData,
    sortType: SortingType,
    compareFunction: TableDataComparable
}

export type TableDataComparable = ((a: TableData, b:TableData) => number);

export interface SortingConfiguration{
    propertyName: keyof TableData,
    sortType: SortingType,
    compareFunction: TableDataComparable
}

export type TableDataComparable = ((a: TableData, b:TableData) => number);

Next, we add that field to our sortBy function:

const sortBy = useCallback(
        (propertyName: keyof TableData, compareFunction: TableDataComparable) => {
            let pendingChange = [...sortConfig];
            const index = pendingChange.findIndex((config) => config.propertyName === propertyName)
            if(index > -1){
                //Save the sortType
                var currentSortType = pendingChange[index].sortType;
                //Remove existing config
                pendingChange.splice(index, 1);
                //check if the sort type we saved is descending
                if (currentSortType === SortingType.Descending) {
                    pendingChange = [
                        ...pendingChange,
                        { propertyName: propertyName, sortType: SortingType.Ascending , compareFunction: compareFunction},
                    ];
                }
            } else {
                pendingChange = [
                    ...pendingChange,
                    { propertyName: propertyName, sortType: SortingType.Descending, compareFunction: compareFunction },
                ];
            }
            updateSortConfig([...pendingChange]);
        },
        [sortConfig]
    )

const sortBy = useCallback(
        (propertyName: keyof TableData, compareFunction: TableDataComparable) => {
            let pendingChange = [...sortConfig];
            const index = pendingChange.findIndex((config) => config.propertyName === propertyName)
            if(index > -1){
                //Save the sortType
                var currentSortType = pendingChange[index].sortType;
                //Remove existing config
                pendingChange.splice(index, 1);
                //check if the sort type we saved is descending
                if (currentSortType === SortingType.Descending) {
                    pendingChange = [
                        ...pendingChange,
                        { propertyName: propertyName, sortType: SortingType.Ascending , compareFunction: compareFunction},
                    ];
                }
            } else {
                pendingChange = [
                    ...pendingChange,
                    { propertyName: propertyName, sortType: SortingType.Descending, compareFunction: compareFunction },
                ];
            }
            updateSortConfig([...pendingChange]);
        },
        [sortConfig]
    )

Next, we update our interfaces and define comparators for each of our table columns.

interface SortableHeaderProps {
    sortBy: (string: keyof TableData, compareFunction: TableDataComparable) => void;
    sortConfig: SortingConfiguration[];
}
...
const CompareByEquality = (column: keyof TableData) => (a: TableData, b: TableData) => {
        if(a[column] === b[column]){
            return 0
        } else{
            if (a[column] > b[column]){
                return 1;
            }
            return -1;
        }
    }

    const tableColumn = [
        {   label: 'Name', 
            property: 'name', 
            compareFunction: 
            (a: TableData, b: TableData) => {
                 return a['name'].localeCompare(b['name'] as string) 
            } 
        },
        {
            label: 'Hours', 
            property: 'hours',
            compareFunction: CompareByEquality('hours')
        },
        {   label: 'Date', 
            property: 'startDate', 
            compareFunction: CompareByEquality('startDate') 
        },
        {   label: 'Department',
            property: 'department', 
            compareFunction: CompareByEquality('department') }
    ] as TableColumn[];

interface SortableHeaderProps {
    sortBy: (string: keyof TableData, compareFunction: TableDataComparable) => void;
    sortConfig: SortingConfiguration[];
}
...
const CompareByEquality = (column: keyof TableData) => (a: TableData, b: TableData) => {
        if(a[column] === b[column]){
            return 0
        } else{
            if (a[column] > b[column]){
                return 1;
            }
            return -1;
        }
    }

    const tableColumn = [
        {   label: 'Name', 
            property: 'name', 
            compareFunction: 
            (a: TableData, b: TableData) => {
                 return a['name'].localeCompare(b['name'] as string) 
            } 
        },
        {
            label: 'Hours', 
            property: 'hours',
            compareFunction: CompareByEquality('hours')
        },
        {   label: 'Date', 
            property: 'startDate', 
            compareFunction: CompareByEquality('startDate') 
        },
        {   label: 'Department',
            property: 'department', 
            compareFunction: CompareByEquality('department') }
    ] as TableColumn[];

Here, I just use equality for returning the values, but for more complex objects, you can define your own comparator function. As for the name, I used string’s localCompare as an example of an in-line lambda comparator.

After that, we just add the compareFunction into our onClick, so that our sortBy function has all the correct parameters.

<TableCell key={index}
    		className={headerCell}
   	 	onClick={() => sortBy(column.property, column.compareFunction)}
>
<TableCell key={index}
    		className={headerCell}
   	 	onClick={() => sortBy(column.property, column.compareFunction)}
>

<TableCell key={index}
    		className={headerCell}
   	 	onClick={() => sortBy(column.property, column.compareFunction)}
>
<TableCell key={index}
    		className={headerCell}
   	 	onClick={() => sortBy(column.property, column.compareFunction)}
>

Lastly, we need to change our definition for sortedRows:

const sortedRows = useMemo(() => {
        if(sortConfig.length === 0){
            return [...dataList];
        }
        let sorted = [...dataList].sort(
            (a: TableData, b:TableData) =>{
                 for(const config of sortConfig){
                    const result = (config.compareFunction(a,b))
                    if(result !== 0){
                        if(config.sortType === SortingType.Ascending){
                            return result;
                        }
                        else{
                            return -result;
                        }
                    }
                }
                return 0;
            }
        )
        return(sorted)
    }, [sortConfig, dataList]);

const sortedRows = useMemo(() => {
        if(sortConfig.length === 0){
            return [...dataList];
        }
        let sorted = [...dataList].sort(
            (a: TableData, b:TableData) =>{
                 for(const config of sortConfig){
                    const result = (config.compareFunction(a,b))
                    if(result !== 0){
                        if(config.sortType === SortingType.Ascending){
                            return result;
                        }
                        else{
                            return -result;
                        }
                    }
                }
                return 0;
            }
        )
        return(sorted)
    }, [sortConfig, dataList]);

First, we check if there’s a sort configuration and if there isn’t we want to go back to our unsorted state by returning a copy of the data list.

If there is a sort configuration, we make a copy of dataList using the spread operator and sort with a lambda function that goes over our loop of sortConfigs. It then tests each a, and b, TableData against the compareFunction in the sortConfig. If we have an equal match, we try to and apply the subsequent sort config until we have a result that isn’t 0. Next, we check if it’s ascending or descending, and so we flip the result to its opposite value with a negative sign. Lastly, we finish going through our sort configuration and find that all matches, then we know both rows are equal.

That about does it for sorting multiple columns in React.

Learn more about DMC’s Application Development expertise.

The post Sorting Multiple Columns in a Table with React appeared first on DMC, Inc..

You will need these dependencies to follow along:

• React
• Material-UI
• React Developer Tools (optional)
• randomcolor (optional)

What are Grids?

A grid is a container or item that automatically handles different screen sizes and orientations. The grids can change their size depending on the window’s current size and adjust shape accordingly. This ensures that we give the users exactly the best interface and it allows the content to appear consistent across different platforms.

How to Get Grids

If you already know how to add Material-UI to your current project, you can skip this section. Otherwise, you can add the dependency by running:

• npm install @material-ui/core or
• yarn add @material-ui/core

To make this tutorial easier to follow, we’ll also be adding randomcolor so that we can visually see our grids easier.

After that’s done, simply import all the elements we installed, and we can start working on learning the basics of Material-UI Grids.

Let’s start with: 

import React from 'react';
import './App.css';
import {Grid} from '@material-ui/core';
import randomColor from 'randomcolor';

function App() {
  return (
    <div className="App" style={{background:randomColor()}}>
     Hooray nothing is here!
    </div>
  );
}

export default App;

import React from 'react';
import './App.css';
import {Grid} from '@material-ui/core';
import randomColor from 'randomcolor';

function App() {
  return (
    <div className="App" style={{background:randomColor()}}>
     Hooray nothing is here!
    </div>
  );
}

export default App;

It shows you something like this:

Getting Started is Easy

To use Material UI Grids, we can start with wrapping our ‘Hooray nothing is here!’ with a Grid, and notice that nothing changes.

You can think of Grids like a ‘replacement’ for a div, but they’re much more special.

Grid Item vs. Grid Container?

import React from 'react';
import './App.css';
import {Grid} from '@material-ui/core';
import randomColor from 'randomcolor';

function App() {
  return (
    <div  className="App">
        <Grid style={{background:randomColor()}}>
          Hooray something is here!
        </Grid>
    </div>
  );
}

export default App;

import React from 'react';
import './App.css';
import {Grid} from '@material-ui/core';
import randomColor from 'randomcolor';

function App() {
  return (
    <div  className="App">
        <Grid style={{background:randomColor()}}>
          Hooray something is here!
        </Grid>
    </div>
  );
}

export default App;

A Grid can have two types of layouts: containers and items. It’s a pretty easy concept, a container contains grid items, and a grid item is in a grid container. A container has special properties that can be set but we’ll touch on that later. The two properties are not mutually exclusive, so you can have a grid that’s both an item and a container.

function App() {
  return (
    <div  className="App">
      <Grid container>
        <Grid item style={{background:randomColor()}}>
          Hooray something is here!
        </Grid>
      </Grid>
    </div>
  );
}

function App() {
  return (
    <div  className="App">
      <Grid container>
        <Grid item style={{background:randomColor()}}>
          Hooray something is here!
        </Grid>
      </Grid>
    </div>
  );
}

Grid Items, Columns, and Break Points

This section contains the most important information for understanding Material UI Grids. Feel free to re-read it a few times if it doesn’t make sense at first. 

By default, Material UI Grids will try to space your items perfectly evenly, so if you have something simple, like 4 grids items, each item will take up 25% of the window.

But, Material UI Grids work on a 12 column grid-layout, and each grid width is a certain percentage of that. So, if we have a Grid of 6, that width should be about 50%.

So we can have something like this:

function App() {
  return (
    <div  className="App">
      <Grid container>
        <Grid item xs={6} style={{background:randomColor()}}>
          Hooray something is here!
        </Grid>
        <Grid item xs={6} style={{background:randomColor()}}>
          Hooray something is too!
        </Grid>
      </Grid>
    </div>
  );
}

function App() {
  return (
    <div  className="App">
      <Grid container>
        <Grid item xs={6} style={{background:randomColor()}}>
          Hooray something is here!
        </Grid>
        <Grid item xs={6} style={{background:randomColor()}}>
          Hooray something is too!
        </Grid>
      </Grid>
    </div>
  );
}

There are a couple of key things to note here like containers and items, but we’ll cover that later. What we’re more interested in is the property that says xs={6}.

Like I stated before, Material UI divides the numbers we give it to 12 columns and spaces our content appropriately. Now, we have a layout that looks something like this:

Material-UI defines how the Grid acts according to specific breakpoints. Below is a table that shows when a specific breakpoint is reached.

Breakpoints are defined starting from the bottom up, meaning if we have xs defined, but not sm or md, it will apply that breakpoint style of the lowest possible key.

If we were to define an md key, then our xs breakpoint would apply, up until we hit that md window size. Our defined xs key only affects screen widths between 0-959px. At 960+ px, our md key would apply.

That was a lot of information, so let’s see it in practice.

In the gif above, each of the four different lines on the bottom of the screen represent different breakpoints. As you can see, when the window screen crosses across the different boundaries, we apply the properties that were specified to Material UI.

<Grid container>
  <Grid item xs={6} sm={2} md={8} lg={12} xl={3} style={{background:randomColor()}}>
     Hooray something is here!
  </Grid>
  <Grid item xs={6} sm={10} md={4} lg={12} xl={9} style={{background:randomColor()}}>
     Hooray something is too!
  </Grid>
</Grid>

<Grid container>
  <Grid item xs={6} sm={2} md={8} lg={12} xl={3} style={{background:randomColor()}}>
     Hooray something is here!
  </Grid>
  <Grid item xs={6} sm={10} md={4} lg={12} xl={9} style={{background:randomColor()}}>
     Hooray something is too!
  </Grid>
</Grid>

One thing to note is that, if we look at xs={6} for both of our Grid items, it splits the space evenly. When we get to the breakpoint of lg and specify the {12} size, we basically ‘fill’ that 12 column limit and move our content on to a new row.

By placing our breakpoints to equal 12, we say that we want this Grid item to occupy its own row.

This might be enough for the given use case, but with Grid containers, we can go even further.

Container Magic

With Grid Containers, we can arrange all of our grid items the way that we want to. The first thing we want to do is add spaces around the grid items so that the content isn’t directly touching one another. We can add the prop ‘spacing’ and which takes in a value between 0 and 10.

The space between each grid is the number you chose, times 8pixel. For example, spacing={2} is 16 pixels.

For this example, we’ll refactor it slightly so that the background color only applies to the content inside the grid, and not the actual grid itself, so we can see the spacing.

function App() {
  return (
    <div  className="App">
      <Grid container spacing={3}>
        <Grid item xs={6}>
          <div style={{background:randomColor()}}>Hooray something is here!</div>
        </Grid>
        <Grid item xs={6}>
          <div style={{background:randomColor()}}> Hooray something is too! </div>
        </Grid>
        <Grid item xs={4}>
          <div style={{background:randomColor()}}> Another item! </div>
        </Grid>
        <Grid item xs={4}>
          <div style={{background:randomColor()}}> Showing off rows! </div>
        </Grid>
        <Grid item xs={4}>
          <div style={{background:randomColor()}}> Last item! </div>
        </Grid>
      </Grid>
    </div>
  );
}

function App() {
  return (
    <div  className="App">
      <Grid container spacing={3}>
        <Grid item xs={6}>
          <div style={{background:randomColor()}}>Hooray something is here!</div>
        </Grid>
        <Grid item xs={6}>
          <div style={{background:randomColor()}}> Hooray something is too! </div>
        </Grid>
        <Grid item xs={4}>
          <div style={{background:randomColor()}}> Another item! </div>
        </Grid>
        <Grid item xs={4}>
          <div style={{background:randomColor()}}> Showing off rows! </div>
        </Grid>
        <Grid item xs={4}>
          <div style={{background:randomColor()}}> Last item! </div>
        </Grid>
      </Grid>
    </div>
  );
}

And now, we have our grids spaced apart!

We can also add the prop direction to our container to pick if we want the grids to be in row or column form. When the direction is in a column, instead of the default row configuration, each grid gets its own row.

We can still define breakpoints to size our component, however, the breakpoint values will only effect width, so an xs={6} will continue to occupy about 50% of the page.

Lazy Layouts (Auto-layout)

There’s been a lot of talk about breakpoints which may be off-putting, however, Grids has an answer with its auto-layout functionality. In a given row, we only need to define at least one actual numeric value of the items in a given breakpoint for the system to figure itself out. We still have to specify that the Grid items are the same breakpoints, but with this, we only have to write one number:

function App() {
  return (
    <div  className="App">
      <Grid container spacing={3}>
        <Grid item xs>
          <div style={{background:randomColor()}}> A</div>
        </Grid>
        <Grid item xs={7}>
          <div style={{background:randomColor()}}> B </div>
        </Grid>
        <Grid item xs>
          <div style={{background:randomColor()}}> C </div>
        </Grid>
        <Grid item xs>
          <div style={{background:randomColor()}}> D </div>
        </Grid>
      </Grid>
      <Grid container spacing={3}>
        <Grid item xs>
          <div style={{background:randomColor()}}> 1</div>
        </Grid>
        <Grid item xs>
          <div style={{background:randomColor()}}> 2 </div>
        </Grid>
        <Grid item xs>
          <div style={{background:randomColor()}}> 3 </div>
        </Grid>
        <Grid item xs>
          <div style={{background:randomColor()}}> 4 </div>
        </Grid>
      </Grid>
    </div>
  );
}

function App() {
  return (
    <div  className="App">
      <Grid container spacing={3}>
        <Grid item xs>
          <div style={{background:randomColor()}}> A</div>
        </Grid>
        <Grid item xs={7}>
          <div style={{background:randomColor()}}> B </div>
        </Grid>
        <Grid item xs>
          <div style={{background:randomColor()}}> C </div>
        </Grid>
        <Grid item xs>
          <div style={{background:randomColor()}}> D </div>
        </Grid>
      </Grid>
      <Grid container spacing={3}>
        <Grid item xs>
          <div style={{background:randomColor()}}> 1</div>
        </Grid>
        <Grid item xs>
          <div style={{background:randomColor()}}> 2 </div>
        </Grid>
        <Grid item xs>
          <div style={{background:randomColor()}}> 3 </div>
        </Grid>
        <Grid item xs>
          <div style={{background:randomColor()}}> 4 </div>
        </Grid>
      </Grid>
    </div>
  );
}

That about does it for Material-UI Grids.

Learn more about DMC’s Application Development Expertise and contact us with project inquiries!

The post A Simple Guide to Material UI Grids appeared first on DMC, Inc..