Requirements

Power Automate

We will use Power Automate, Microsoft’s cloud-based business automation platform, to automate this process. In Power Automate, a single executable task is called a flow. Each component of a flow is called an action.

To copy and populate Word documents in Power Automate, we must use an action from the Word Online connector which requires a Power Automate Premium account.

SharePoint Online

For the flow we will write, we need a cloud-based location to source the Word document template and a destination to send the populated template copy. If your organization uses SharePoint Online, there are actions we can add that retrieve and save files in SharePoint out of the box!

Word

The document templates are created in Word and saved as a .docx file.

Implementation

Part 1: Creating Your Word Template

Let us start off with an example document template that has some placeholder fields.

To denote the {insert} placeholder values as fields that we want to be able to overwrite with our flow, mark each of them as a “Plain Text Control” which you can do on the “Developer” tab in the Word editor.

We can then configure the control by selecting it on the page (it should show up as a gray box outline around the placeholder text) and select the “Control Properties” widget next to the plain text control button.

This will open the following dialog. You can name the control anything, but make sure it is descriptive if you are adding multiple controls to your template so there is no confusion when connecting data sources to the controls in Power Automate.

At this point, the file is ready for use as a template. Let us save it to a location in SharePoint Online so that our Power Automate flow can make copies of it. If the account creating the flow is different from the account which uploads the document, make sure that it is saved to a location that the former can also access.

Part 2: Creating the Flow in Power Automate

To create the template population flow, go to the Power Automate console in your browser and click “Create.” The type of flow you create depends on what will trigger it. There are three cloud-native flow types available:

1. Automated Cloud flow – a flow that is triggered through a designated event.
2. Instant Cloud flow – a flow that is triggered manually through the Power Automate console or through an external command like an HTTP request.
3. Scheduled flow – a flow that is triggered automatically on a set schedule.

Your situation may differ, but as an example, we will create a flow that is manually triggered via an HTTP request that contains all the data populated to the template.

Once we’ve created the flow, we need to source the content that will populate our template. Since our content passes into the flow with the HTTP request trigger, we will update the output schema of the trigger so we have references to the values we want to pull from the request body. Again, this will differ based on the type of trigger/data source for your flow. Here is an example of what this looks like with our example HTTP trigger, where we define the input schema and specify that the request includes the “projectName” value.

Next, we will add the “Populate a Microsoft Word Template” action. When we select the template file, we can see the control fields that can be populated in our flow in the “Advanced Parameters” section, identified by the names we specified in the template document. We will specify the values that should be inserted to each field.

The output of the Word connector is an unsaved copy of our populated template file, which we will then pipe to the “Create File” action that saves the file in a specified location in SharePoint.

Once you specify the location to save the file, the flow is complete. Go ahead and save the flow and test it out.

Further Considerations

As stated before, access to template documents is not guaranteed when you create the flow, based on the SharePoint sites your account has access to. It may be worth setting up flows with an admin account in your organization to ensure they will not break if permissions for certain users are modified. Additionally, updating the template file may cause issues, as references to the control fields in your flow may break when the source template document is updated in the future. If your flow is mission-critical, make sure there is a well-defined system for modifying your template files to avoid any unexpected failures.

Power Automate is incredibly useful for automating workflows like these Word templates we have populated. Additionally, you can easily extend a flow like this with conditional logic or other downstream actions for SharePoint/other integrated services, all in one portal. DMC has extensive experience with Power Automate and many other digital workplace technologies. To see how your business processes can be optimized, give us a call!

The post Copying and Populating Word Documents in SharePoint Online Using Power Automate appeared first on DMC, Inc..

Object Retrieval Pattern

We’ll be using presigned S3 object URLs to fetch our private Amazon S3 data. See my previous post linked above to learn more about this design. Below is a diagram visualizing the dataflow of authorizing the React frontend to fetch an image file, using presigned URLs.

Initial Implementation

Let’s set up a simple component with a single <img> element that we’d like to link to our desired resource, with the resource URL passed as a prop to the component.

const S3Image = ({ objectUrl }) => {

    return <img src={objectUrl} alt="Image" />;

}

export default S3Image;

const S3Image = ({ objectUrl }) => {

    return <img src={objectUrl} alt="Image" />;

}

export default S3Image;

If we want to fetch the presigned URL for the corresponding object pointed to by objectUrl, we need to ensure that the URL embedded into the <img> element is up to date with the object specified in the props. We can set up some local state to store the signed URL and a useEffect to fetch the URL when the objectPath prop changes.

import React, { useState, useEffect } from 'react';
const S3Image = ({ objectPath }) => {

    const [signedUrl, setSignedUrl] = useState('');

    useEffect( async () => {

        try {

            const response = await fetch('/get-signed-url', { objectPath });

            const data = await response.json();

            setSignedUrl(data.url);

        } catch (error) {

            console.error('Error fetching signed URL:', error);

        }

    }, [objectPath]);

 

  return (

      <img src={signedUrl} alt="Image" />

  );

};

export default S3Image;

import React, { useState, useEffect } from 'react';
const S3Image = ({ objectPath }) => {

    const [signedUrl, setSignedUrl] = useState('');

    useEffect( async () => {

        try {

            const response = await fetch('/get-signed-url', { objectPath });

            const data = await response.json();

            setSignedUrl(data.url);

        } catch (error) {

            console.error('Error fetching signed URL:', error);

        }

    }, [objectPath]);

 

  return (

      <img src={signedUrl} alt="Image" />

  );

};

export default S3Image;

For simplicity, we’ll handle the signed URL creation in lambda function running Node.js. This assumes that an API Gateway is set up to proxy the HTTP request from the react app to this Lambda function, but this pattern could be implemented with other AWS compute resources/VPC connection methods if more applicable. To see more on how to implement this API Gateway + Lambda stack, see my blog on Cloud APIs in minutes with Serverless Framework and AWS Lambda.

We’ll use the AWS SDK to generate a presigned URL for this image file.

const AWS = require('aws-sdk');

AWS.config.update({

    accessKeyId: // IAM user credentials that have access to the S3 bucket

    secretAccessKey: // IAM user secret key

    signatureVersion: 'v4',

    region: // enter your region here

});

 

const s3 = new AWS.S3();

 

module.exports = async (event) => {

    try {

        // get request parameters

        const body = JSON.parse(event.body);

       

        if(!(body.objectPath?.length)){

            return { statusCode: 400, body: JSON.stringify({error: "Invalid object path"}) };  

        }

 

        const url = s3.getSignedUrl(input.object_method, {

            Bucket: // specify the bucket we're pulling from

            Key: body.object_path,

            Expires: //specify the lifetime of the URL (in milliseconds)

        });

 

        return { statusCode: 200, body: JSON.stringify({url}) };

    } catch (error) {

        return { statusCode: 500, body: JSON.stringify(error) };

    }

}

const AWS = require('aws-sdk');

AWS.config.update({

    accessKeyId: // IAM user credentials that have access to the S3 bucket

    secretAccessKey: // IAM user secret key

    signatureVersion: 'v4',

    region: // enter your region here

});

 

const s3 = new AWS.S3();

 

module.exports = async (event) => {

    try {

        // get request parameters

        const body = JSON.parse(event.body);

       

        if(!(body.objectPath?.length)){

            return { statusCode: 400, body: JSON.stringify({error: "Invalid object path"}) };  

        }

 

        const url = s3.getSignedUrl(input.object_method, {

            Bucket: // specify the bucket we're pulling from

            Key: body.object_path,

            Expires: //specify the lifetime of the URL (in milliseconds)

        });

 

        return { statusCode: 200, body: JSON.stringify({url}) };

    } catch (error) {

        return { statusCode: 500, body: JSON.stringify(error) };

    }

}

And there it is! With this implementation alone, you’ll be able to display that image in your app, even though it’s not publicly accessible in S3.

Caveat – Signed URL Expiration

There’s one large issue with this implementation—the presigned URLs expire! Each presigned URL generated has a lifespan of a duration (configurable when the URL is generated), and after this time, requests using that URL will fail. This is to prevent persisting public access to the object. Remember, anyone with the presigned URL can use it, as long as it has not expired!

This will not be an issue for any media fetched and displayed in the browser on page load (like our image component above), but what if you want to provide a download link to the image file? The user may linger on the page after it’s initially loaded and only request the file from S3 by clicking the link after the signature has expired. This leads to a nasty error screen and is probably not what your users want to see.

So, we don’t want to let presigned URLs embedded into the page expire, but we also don’t want to disable the presigned URL’s timeout. To get around this, we’ll add logic to periodically re-generate the presigned URL for the given asset. Below is our component, updated with the logic to re-fetch the URL periodically (using the useInterval custom hook from the use-interval package).

import React, { useState, useCallback } from 'react';

import useInterval from 'use-interval';

 

const S3Image = ({ objectPath }) => {

    const [signedUrl, setSignedUrl] = useState('');

    // define the function used to fetch the signed URL

    const getSignedUrl = useCallback(async () => {

        try {

            const response = await fetch('/get-signed-url', { objectPath });

            const data = await response.json();

            setSignedUrl(data.url);

        } catch (error) {

            console.error('Error fetching signed URL:', error);

        }

    }, [objectPath]);

    // call the function defined above every second

    useInterval( getSignedUrl, 1000, true );

    return <img src={signedUrl} alt="Image" />;

};

export default S3Image;

import React, { useState, useCallback } from 'react';

import useInterval from 'use-interval';

 

const S3Image = ({ objectPath }) => {

    const [signedUrl, setSignedUrl] = useState('');

    // define the function used to fetch the signed URL

    const getSignedUrl = useCallback(async () => {

        try {

            const response = await fetch('/get-signed-url', { objectPath });

            const data = await response.json();

            setSignedUrl(data.url);

        } catch (error) {

            console.error('Error fetching signed URL:', error);

        }

    }, [objectPath]);

    // call the function defined above every second

    useInterval( getSignedUrl, 1000, true );

    return <img src={signedUrl} alt="Image" />;

};

export default S3Image;

This implementation can be further ruggedized by modifying our Lambda function to return the lifetime along with the URL itself, such that the client knows exactly when it will need to regenerate it. However, regenerating the URL is not a time or compute intensive operation, so simply regenerating more often than you would ever expect the presigned URL timeout to be set to is most likely a reliable solution.

Abstracting as a Custom Hook

As a one-off use of this procedure, this implementation is perfectly suitable now. However, this logic would muddy your state management design if added in multiple locations or more complex components. To avoid this, let’s abstract this logic into a custom hook that provides the presigned URL for the S3 object path passed to it.

import React, { useState, useCallback } from 'react';

import useInterval from 'use-interval';

 

export const useSignedUrl = (objectPath) => {

    const [signedUrl, setSignedUrl] = useState('');

    const getSignedUrl = useCallback(async () => {

        try {

            const response = await fetch('/get-signed-url', { objectPath });

            const data = await response.json();

            setSignedUrl(data.url);

        } catch (error) {

            console.error('Error fetching signed URL:', error);

        }

    }, [objectPath]);

    useInterval( getSignedUrl, 1000, true );

    return signedUrl;

};

import React, { useState, useCallback } from 'react';

import useInterval from 'use-interval';

 

export const useSignedUrl = (objectPath) => {

    const [signedUrl, setSignedUrl] = useState('');

    const getSignedUrl = useCallback(async () => {

        try {

            const response = await fetch('/get-signed-url', { objectPath });

            const data = await response.json();

            setSignedUrl(data.url);

        } catch (error) {

            console.error('Error fetching signed URL:', error);

        }

    }, [objectPath]);

    useInterval( getSignedUrl, 1000, true );

    return signedUrl;

};

This simplifies our component definition significantly.

import useSignedUrl from './useSignedUrl';

const S3Image = ({ objectPath }) => {

    const signedUrl = useSignedUrl(objectPath);

    return <img src={signedUrl} alt="Image" />;

};

export default S3Image;

import useSignedUrl from './useSignedUrl';

const S3Image = ({ objectPath }) => {

    const signedUrl = useSignedUrl(objectPath);

    return <img src={signedUrl} alt="Image" />;

};

export default S3Image;

With this, we have a clean, generalized solution for embedding restricted S3 content in our components.

The post Embedding Private Media Files Securely in a React Frontend with Amazon S3 and AWS Lambda appeared first on DMC, Inc..

However, say that your bucket is storing private/proprietary information. You wouldn’t want just anybody to be able to retrieve that data with an HTTP request, would you? In this blog, we’ll explore how we can securely and efficiently access Amazon S3 objects with either direct AWS or third-party authentication/authorization.

Bucket Policies

Bucket policies are the first step to restricting public access to objects. They apply to entire buckets in S3, and can be set up to only allow certain AWS IAM users, user roles, or methods of access to retrieve objects within the bucket to which it’s applied.

Here’s a straightforward bucket policy to restrict any access to an S3 bucket except for those that provide IAM credentials that match to a specific user:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::ACCOUNT_ID:user/USER_NAME"
            },
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::BUCKET_NAME/*"
            ]
        }
    ]
}

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::ACCOUNT_ID:user/USER_NAME"
            },
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::BUCKET_NAME/*"
            ]
        }
    ]
}

Now this solution works for any situation where the client fetching the S3 object is able to provide permanent IAM credentials in their request. However, this is very rarely a valid solution. What if we have an existing authentication solution that we want to use to determine access to an S3 object? Or what if we don’t want/need to edit this policy whenever a new user needs access?

Accommodating Third-party Authentication

To abstract the IAM authentication layer entirely, we could proxy the S3 files through some intermediate compute resource within our VPC that:

1. can authenticate a request with a 3rd party auth solution.
2. can access the buckets directly, with its own static set of IAM credentials.

Below is a diagram of this dataflow. Only the solid lines are data transfers that contain the data of the S3 object being requested.

This is, strictly speaking, an effective solution. However, S3 objects can be very large, so passing the whole object through some intermediary compute resource may incur unacceptable memory/data transfer costs. What we’d want is a way to securely access the S3 object while still being able to pull it directly from the bucket to the end client making the request, in order to take advantage of S3’s ultra-cost-efficient retrieval pricing.

Enter – the presigned URL!

Presigned URLs are used to temporarily authorize operations across AWS to anybody who has the URL. To generate a presigned URL for a specific action, your IAM policy must be authorized to perform that action. To mitigate the chance that the power of a presigned URL falls into the wrong hands, they are configured to only serve their purpose for a defined timeout.

Using presigned URLs generated to provide access to individual S3 objects at request time, we can extend the secure access approach above, such that:

1. The client sends an authenticated request using the 3rd-party auth to a compute resource (lambda works perfectly) with full read-access to our S3 bucket.
2. The compute resource authenticates this request against 3rd party auth.
3. The compute resource generates a pre-signed URL for the S3 object requested and returns it to the client.
4. The client fetches the S3 object using the presigned URL before it times out.

Notice how the file is requested directly from S3 in this setup! With that, we have a secure and performant solution.

To see an example implementation of this design, see my follow-up post, Embedding private media files securely in a React frontend with Amazon S3 and AWS Lambda.

The post Externally Authenticated Access to S3 Objects Over the Internet appeared first on DMC, Inc..

For example, say you need to set up a service that sends an email containing data from the same data sources accessed by your API when triggered by an HTTP request. The API’s codebase could very easily be extended to provide this functionality, but doing so can lead to several types of tech debt.

• Design – The API surface should abstract the complexities of data retrieval/syncing, so adding endpoints to manage this process goes against the design pattern.
• Security – If this is an external-facing API, you might run into serious security issues with allowing processes that consume your API to trigger such an action!
• Cost optimization – This is probably not a concern if your code just needs to send an email, but if you need to perform a more compute or memory intensive action, like a sync between two data sources. If this data sync is a very bursty workload, then running it on the same resources provisioned for nominal API usage may lead to surge pricing.

So, looks like you need a scheduled process within your cloud infrastructure that runs this operation separately from your API. This now seems like a lot more of an undertaking. The source code for this tiny task should be very quick to implement, but the overhead of provisioning, testing, deploying, and maintaining new resources dedicated for that task seems too high.

Serverless Functions to the Rescue!

Serverless functions like AWS Lambda (which is what we’ll focus on) are perfect for these kinds of actions. They’re quick and easy to develop and can cost almost nothing compared to reserved compute like EC2 for small tasks like sending an email or two.

The code below is an example of an entire Lambda function implementation, minus any package dependencies. See how quickly these can be developed?

 
var AWS = require('aws-sdk');
AWS.config.update({region: 'us-west-2'});
var ses = new AWS.SES({apiVersion: '2010-12-01'});

exports.handler = async (event) => {
    var params = // email params
    try {
        var data = await ses.sendEmail(params).promise();
        return {
            statusCode: 200,
            body: JSON.stringify("Email sent! Message ID: " + data.MessageId),
        };
    } catch (error) {
        console.error(error);
        return {
            statusCode: 500,
            body: JSON.stringify("Error sending email: " + error.message),
        };
    }
};

 
var AWS = require('aws-sdk');
AWS.config.update({region: 'us-west-2'});
var ses = new AWS.SES({apiVersion: '2010-12-01'});

exports.handler = async (event) => {
    var params = // email params
    try {
        var data = await ses.sendEmail(params).promise();
        return {
            statusCode: 200,
            body: JSON.stringify("Email sent! Message ID: " + data.MessageId),
        };
    } catch (error) {
        console.error(error);
        return {
            statusCode: 500,
            body: JSON.stringify("Error sending email: " + error.message),
        };
    }
};

But wait! What if a second data sync action needs to be added? A third? Serverless functions are great for implementing one-off features like this in a vacuum, but managing a whole flock of serverless functions with their own source code, their own VPC configurations, their own deployment processes, etc., can become an unmanageable mess very quickly.

Serverless Framework

The Serverless Framework package provides a suite of Infrastructure-as-Code capabilities built to allow you to deploy and configure one or more serverless functions defined within a single directory. This means that you can easily keep your functions’ implementations and configurations all tracked within one repository!

Let’s walk through the setup of a project using the serverless framework to show how simple it is.

Create a Node Project and Install the Serverless Framework Package

In your project directory, with your Unix shell of choice, run the following.

 
npm init
npm install serverless

 
npm init
npm install serverless

Use the Serverless Framework CLI to Pick the Project Template

The CLI will provide a list of templates to choose from. For this post, we’re going to create a Lambda application targeting Node.js with an Amazon API Gateway integration for triggering our functions.

 
? What do you want to make?
  AWS - Node.js - Starter
> AWS - Node.js - HTTP API
  AWS - Node.js - Scheduled Task
  AWS - Node.js - SQS Worker
  AWS - Node.js - Express API
  AWS - Node.js - Express API with DynamoDB
  AWS - Python - Starter
  AWS - Python - HTTP API
  AWS - Python - Scheduled Task
  AWS - Python - SQS Worker
  AWS - Python - Flask API
  AWS - Python - Flask API with DynamoDB
  Other

 
? What do you want to make?
  AWS - Node.js - Starter
> AWS - Node.js - HTTP API
  AWS - Node.js - Scheduled Task
  AWS - Node.js - SQS Worker
  AWS - Node.js - Express API
  AWS - Node.js - Express API with DynamoDB
  AWS - Python - Starter
  AWS - Python - HTTP API
  AWS - Python - Scheduled Task
  AWS - Python - SQS Worker
  AWS - Python - Flask API
  AWS - Python - Flask API with DynamoDB
  Other

Name the project once you’ve selected the template. 

 
? What do you want to make? AWS - Node.js - HTTP API
? What do you want to call this project? example-project

 
? What do you want to make? AWS - Node.js - HTTP API
? What do you want to call this project? example-project

This should generate the following files in your Node project.

The configuration of each Lambda function and this gateway are all specified in the generated serverless.yaml file.

 
service: example-project
frameworkVersion: '3'
provider:
  name: aws
  runtime: nodejs18.x
functions:
  api:
    handler: index.handler
    events:
      - httpApi:
          path: /
          method: get

 
service: example-project
frameworkVersion: '3'
provider:
  name: aws
  runtime: nodejs18.x
functions:
  api:
    handler: index.handler
    events:
      - httpApi:
          path: /
          method: get

This config tells the API gateway to invoke our Lambda (referenced here as the auto-generated function name of index.handler, which matches the function code’s file name and export field) in a Node 18 runtime, whenever a GET request is sent to the API gateway. The auto-generated function (in ./index.js) looks like this.

 
module.exports.handler = async (event) => {
  return {
    statusCode: 200,
    body: JSON.stringify(
      {
        message: "Go Serverless v3.0! Your function executed successfully!",
        input: event,
      },
      null,
      2
    ),
  };
};

 
module.exports.handler = async (event) => {
  return {
    statusCode: 200,
    body: JSON.stringify(
      {
        message: "Go Serverless v3.0! Your function executed successfully!",
        input: event,
      },
      null,
      2
    ),
  };
};

Creating the Functions

Let’s update index.js to include both of our emailing functions.

 
var AWS = require('aws-sdk');
AWS.config.update({region: 'us-west-2'});
var ses = new AWS.SES({apiVersion: '2010-12-01'});
const sendEmailAndReturnResponse = async (params) => {
  try {
      var data = await ses.sendEmail(params).promise();
      return {
          statusCode: 200,
          body:
    JSON.stringify("Email sent! Message ID: " + data.MessageId),
      };
  } catch (error) {
      console.error(error);
      return {
          statusCode: 500,
          body: JSON.stringify("Error sending email: " + error.message),
      };
  }
};
           
exports.mail1 = async (event) => {
    var params = getEmailParams1(event); // getEmailParams1 is a function that you'll define for your own system
    return sendEmailAndReturnResponse(params);
};
exports.mail2 = async (event) => {
    var params = getEmailParams2(event); // getEmailParams2 is a function that you'll define for your own system
    return sendEmailAndReturnResponse(params);
};

 
var AWS = require('aws-sdk');
AWS.config.update({region: 'us-west-2'});
var ses = new AWS.SES({apiVersion: '2010-12-01'});
const sendEmailAndReturnResponse = async (params) => {
  try {
      var data = await ses.sendEmail(params).promise();
      return {
          statusCode: 200,
          body:
    JSON.stringify("Email sent! Message ID: " + data.MessageId),
      };
  } catch (error) {
      console.error(error);
      return {
          statusCode: 500,
          body: JSON.stringify("Error sending email: " + error.message),
      };
  }
};
           
exports.mail1 = async (event) => {
    var params = getEmailParams1(event); // getEmailParams1 is a function that you'll define for your own system
    return sendEmailAndReturnResponse(params);
};
exports.mail2 = async (event) => {
    var params = getEmailParams2(event); // getEmailParams2 is a function that you'll define for your own system
    return sendEmailAndReturnResponse(params);
};

Configuring the Functions

Updates the serverless.yaml file to map both functions to POST requests sent to their endpoints, and to route the API gateway endpoints to each function correctly.

 
service: example-project
frameworkVersion: '3'
provider:
  name: aws
  runtime: nodejs18.x
functions:
  api:
    handler: index.mail1
    events:
      - httpApi:
          path: /
          method: post
  api:
    handler: index.mail2
    events:
      - httpApi:
          path: /
          method: post

 
service: example-project
frameworkVersion: '3'
provider:
  name: aws
  runtime: nodejs18.x
functions:
  api:
    handler: index.mail1
    events:
      - httpApi:
          path: /
          method: post
  api:
    handler: index.mail2
    events:
      - httpApi:
          path: /
          method: post

Enter your AWS account credentials, and both of your functions will be deployed to a new Lambda application for you!

Update Your Functions

Updates to the serverless.yaml or the function source code can be easily applied to the deployments by simply re-running the command above. Serverless Framework tracks the configuration of your functions with AWS CloudFormation, so it knows exactly what to update when changes have been pushed.

The post Cloud Deployments in Minutes with Serverless Framework and AWS Lambda appeared first on DMC, Inc..

Out-of-the-box UI rarely matches an application’s predetermined design alone, however. In these situations, we are required to open these components and tinker with their CSS styles directly.

Material UI offers extensive documentation for component styling and customization, but the actual process of reworking these styles can be confusing and frustrating. In this blog post, I hope to simplify this process by covering 3 common pitfalls when overriding Material UI styles. 

This post will exemplify these pitfalls by overriding styles on an MUI TextField component. The implementation of these examples can be found in this Code Sandbox. The source code we will start off with is a single TextField component rendered to the page, with style overrides controlled with MUI’s built-in createTheme() function: 

const theme = createTheme({
 components: {
   MuiInputBase: {
     styleOverrides: {
       root: {}
     }
   }
 }
});
export default function App() {
 return (
   
     
       
         }}
       />
     
   
 );
}

const theme = createTheme({
 components: {
   MuiInputBase: {
     styleOverrides: {
       root: {}
     }
   }
 }
});
export default function App() {
 return (
   
     
       
         }}
       />
     
   
 );
}

With no overrides in place to begin, the rendered page looks like this: 

There are multiple approaches to specifying style overrides within your project, and you may require something different than what is provided in this demo. For more information on the different approaches for locating style overrides, check out the MUI documentation.  

Part 1: MaterialUI Slot Selectors 

Style overrides are most commonly located in a “theme” object. This object designates custom styles to components and the “slots” that compose a given component. Each slot maps to a single HTML element rendered within the larger component. 

To add or override a style, we specify both the component and slot that we are targeting. The styles we specify are applied in a CSS class specific to that element. In the example below, we target the input element within an MUI TextField, which is accessed by the MUI component MuiInputBase and slot root:  

const theme = createTheme({
  components: {
    MuiInputBase: {
      styleOverrides: {
        root: {
          color: "green"
        }
      }
    }
  }
});

Pitfall: Choosing the Wrong Slot 

When we specify styles for a component, they may appear in the rendered CSS but not induce a visible change on the page. In this case, the slot you specified may not be the correct one to target. A good practice to prevent this issue is to determine where the styles you want to override are initially applied and ensure you specify those slots in your theme. 

For example, say that I am trying to both increase the width of the TextField border and remove the preset borderRadius. If I apply both updates to the MuiInputBase-root slot, I get the following result: 

const theme = createTheme({
  components: {
    MuiOutlinedInput: {
      styleOverrides: {
        root: {
          borderWidth: 3,
          borderRadius: 0
        }
      }
    }
  }
});

As you can see, the border has been removed, but the box width remains the same. If I investigate the styling specified for each slot, I see that there is a default value of borderRadius specified for MuiOutlinedInput-root, but the default borderWidth set on MuiOutlinedInput-notchedOutline is still being applied:

If I move this override to the correct slot, we can see the desired output: 

const theme = createTheme({
  components: {
    MuiOutlinedInput: {
      styleOverrides: {
        root: {
          borderRadius: 0
        },
        notchedOutline:{
          borderWidth: 3
        }
      }
    }
  }
});

Part 2: Correct MUI Class Reference Syntax 

Beyond the theme specification exemplified above, MUI theme overrides allow string keys that specify selectors, providing greater control over the styles applied.  

There are many features of this string notation, but two features are used most frequently: 

• Specifying the component-slot names of a descendant MUI component (akin to CSS descendant combinators) 
• Specifying a state selector that applies styles to the component only if it is in a certain state (akin to CSS pseudo-classes) 

An example of both can be seen below: 

const theme = createTheme({
 components: {
   MuiOutlinedInput: {
     styleOverrides: {
       root: {
         borderRadius: 0,
         "&. MuiSvgIcon-root": {
           color: "rgb(100,100,100)"
         },
         "&.Mui-focused": {
           backgroundColor: "rgb(220,240,250)",
         }
       },
       notchedOutline: {
         borderWidth: 3,
         borderColor: "black"
       }
     }
   }
 }
})

Here, we have added an adornment icon to the TextField, which has a default color of black (“rgb(0,0,0)”), but we can specify a selector for this MUI component and update its color to a dark gray (“rgb(220,240,250)”). Additionally, we can set the background color of the field whenever the field is in focus by specifying a background color in the state selector “.Mui-focused”.

Pitfall: String Selector Syntax

These string-notation selectors are fantastic for adding a higher level of specificity to your overrides, but they also fall outside of the typing for MUI themes – every key with this notation is just a string. This means that applying styles to incorrectly formatted selectors will fail silently. Given the extensive feature set of these string selectors, consulting the MUI documentation on formatting is best for more complex cases. For simpler and more common cases like the one above, here is a quick tip that may save you some time:

• Descendant selectors follow the notation “& .[Component]-[Slot]”. Note the space after the ampersand.  
• State selectors follow the notation “&.[state]” with no space after the ampersand. 

This small difference is due to how these strings are parsed into plain CSS selectors. Descendant components are implemented with descendant CSS combinators as mentioned above, which require a space. State selectors are simply appended to the existing component class name, so the space is not included. Failing to follow this format for either type of selector results in styles not being applied. Below, we can see that neither the background highlight nor the color modification of the adornment icon is applied when the format is incorrect. 

const theme = createTheme({
 components: {
   MuiOutlinedInput: {
     styleOverrides: {
       root: {
         borderRadius: 0,
         "&. MuiSvgIcon-root": {
           color: "rgb(100,100,100)"
         },
         "&.Mui-focused": {
           backgroundColor: "rgb(220,240,250)",
         }
       },
       notchedOutline: {
         borderWidth: 3,
         borderColor: "black"
       }
     }
   }
 }
});

Part 3: Selector Specificity is Correct 

The nested selector structure shown in the last two examples follows the same rule as applying classes to HTML elements: if two classes are applied to an element and one class has a more specific selector than the other, then the more specific class’s styles will be displayed with higher priority than the other.

In MUI theme overrides, specificity is determined by matching slot selectors and state selectors, as well as any base CSS selector. 

Pitfall: Override’s selector is still not a higher specificity than the out-of-the-box styling

There are already many selectors in the default styles of an MUI component that are very specific to certain elements within it. If your style override does not appear and the default style is still applied, check the style’s specificity and try to match it to your overriding selector. 

I’ll demonstrate this by extending the example from the last two sections. If you look at the image from the last section, you’ll notice that our custom black border is not present when the text box is selected. The border becomes thinner, and the color changes to a darker blue.

If we dig around the DOM a bit when the TextField component is in focus, we can see a default TextField style that is making this change with the help of the higher specificity of the “.Mui-focused” state selector: 

If we want to override the border color of the text field when it is in focus, we need to match the level of specificity from the selector of the default style: 

const theme = createTheme({
 components: {
   MuiOutlinedInput: {
     styleOverrides: {
       root: {
         borderRadius: 0,
         "&. MuiSvgIcon-root": {
           color: "rgb(100,100,100)"
         },
         "&.Mui-focused": {
           backgroundColor: "rgb(220,240,250)",
           "& .MuiOutlinedInput-notchedOutline":{
             borderColor: "black"
           }
         }
       },
       notchedOutline: {
         borderWidth: 3,
         borderColor: "black"
       }
     }
   }
 }
});

Now, if we look at the DOM and the resultant page, we see that the more specific default style has been successfully overridden: 

Another important consideration here is that the selectors must be nested in the right order to be successfully applied; if the .MUI-focused state selector is nested in MuiOutlinedInput-notchedOutline class selector, then the style would not apply. 

Conclusion

MUI’s default styles and style overrides provide a very high level of configurability to web developers, but opening their out-of-the-box solutions can be tricky. The pitfalls exemplified are not the only possible issues, but from my experience, keeping these common problems in mind will considerably reduce the time needed to debug your styles. 

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

The post 3 Common Pitfalls of Theme Customization with Material UI  appeared first on DMC, Inc..