Forem: Moray Macdonald

Using AWS IAM roles with Node SDKv3

Moray Macdonald — Tue, 08 Oct 2024 10:55:54 +0000

Recently I was upgrading our Node backend and decided to upgrade our S3 helpers from AWS SDKv2 to SDKv3. Apart from splitting the SDK into individual dependencies for each component (very nice), it also makes some pretty major changes around how requests are made.

Once I got my head around creating command objects and sending them to the client instead of just called the appropriate method, the migration was fairly smooth and worked well with the test credentials on my dev machine. Unfortunately, as soon as I started to roll out the changes onto our staging environment, my logs started filling up with familiar "Could not load credentials from any providers" errors. Normally this is a sign to any AWS veterans that you've forgotten to give your EC2 instance the right IAM role, but in this case all the instances had the right role, and the role still had the correct permissions.

After a bit of digging, I came across this forum post which contained the answer. In SDKv3, the credential provider that comes with the individual service packages has been made much stricter and can only read credentials from certain places. This means that the new S3Client can't read credentials inserted into your EC2 instance from its IAM role via the Instance Metadata Service (IMDS).

If you are getting credentials based on your instance's IAM role (and if not, why not?) you need to specify the credential provider explicitly from the credential-provider-node package. So for example, if you need to access S3 resources, you need to do this:

import { S3Client } from '@aws-sdk/client-s3';
import { defaultProvider } from '@aws-sdk/credential-provider-node';

const s3 = new S3Client({
  region: 'eu-west-2',
  credentials: defaultProvider(),
});

Other clients for other services also have the credentials option. Now you should be able to access your services as you expect!

Which React render callback pattern do you prefer?

Moray Macdonald — Mon, 23 Sep 2024 16:47:08 +0000

I found myself with an hour to myself on Friday afternoon so thought I'd relax with a good old refactoring session to tidy up some deeper parts of our React app. Whilst digging, I found that we use a couple of different abstraction patterns when one component needs to control the rendering of another. In both cases, the parent component runs a callback function to control the rendering of the child component (hence the name - callback pattern) but I can't decide which form I prefer.

Example

In my case, the parent component was part of our authorization logic which is way to complex to reproduce here, so I've simplified things! The idea is that the (reusable) parent does some processing, generates some props, and passes those props down to the child component.

Render Prop pattern

In this case, the parent component uses a prop called render which sets the logic to render the child component:

export const RenderPropsExample = () => (
  <RenderPropParent render={props => (
    <SubComponent {...props} />
  )} />
);

Function as a Child (FaaC)

In this case, the built-in children property of the parent element sets the logic:

export const FunctionAsChildExample = () => (
  <ChildComponent>
    {props => (
      <SubComponent {...props} />
    )}
  </ChildComponent>
);

Which is better?

As the end result is the same for both cases, is that even the right question to ask?

Personally, I like the way the FaaC pattern uses the built-in children feature of React, but I don't like the fact that I have to redefine children to be a function that returns a ReactNode, rather than just a ReactNode.

On the other hand, the Render Prop pattern doesn't have that issue - render is a custom prop so I'm free to define it however I like. But using a prop to define my component hierarchy instead of child components feels like I'm again breaking a pretty fundamental pattern in React!

What are your thoughts on this? Have I missed a way that one is superior to the other? Or is this a pointless discussion as the end result is the same? Let me know!

What's your favourite TypeScript style guide (and why)?

Moray Macdonald — Wed, 06 Sep 2023 16:08:54 +0000

I had an interesting chat with another dev about the pros and cons of different style guides yesterday and was interested to see what everyone else uses.

Personally I like how prescriptive the AirBnB style guide is (with the TS addon, I know it's not officially supported) which really helps with readability across large projects, but I know not everyone likes.

So, what's your favourite? React for the poll, and comment why!

(in alphabetical order 😉)

💖 I like AirBnB
🦄 I like Google
🤯 I like Standard
🙌 I like XO
🔥 I use some other style guide (write in)/I have my own rules

Making better images with HTML5 and React

Moray Macdonald — Sat, 11 Mar 2023 22:06:04 +0000

I love HTML5. I love its semantic elements. I love its accessibility features. Mostly, I love the fact that its designers clearly looked at all the problems that web developers were having with HTML4, and all the libraries and hacks we were using to get around them and decided "Right. We'll fix that." And for the most part they did!

One of the things that every web developer will encounter is how to show images to the user. Unfortunately, displaying images is a lot more complex than <img src="cat.jpg">, when you start considering all the different people who'll be using your site - us devs have nice big screens and fast internet connections, but a user on a narrow mobile screen with a slow connection is not going to want to wait to load your gorgeous hi-res header image. And that's before we get to my gran, who still has a beige tower PC and a web browser that's barely heard of PNG, let alone fancy things like WEBP and AVIF!

Fortunately, HTML5 is here to the rescue with its very handy <picture> element! Here's what it looks like:

<picture>
  <source
    srcset="/static/cat-1024x768.webp"
    type="image/webp"
    media="(min-width: 800px)">
  <source
    srcset="/static/cat-1024x768.jpg"
    type="image/jpeg"
    media="(min-width: 800px)">
  <source
    srcset="/static/cat-800x600.jpg"
    type="image/jpeg">
  <img
    src="/static/cat-1024x768.jpg"
    title="You should really title your images!"
    alt="You should alt text them too. Screen readers and crawlers will thank you!">
</picture>

This looks far more complex than <img src="cat.jpg">, but what the <picture> element does is actually very clever and very simple. It looks at all the possible things it can display (the <source> elements), and then picks the most appropriate one to load and display to the user using the supplied <img> element.

So for the example above, the browser will go through the following logic:

If I support WEBP images, and is my width greater than 800px? If so, pick the first <source>
If I don't support WEBP but my width is greater than 800px, I'll pick the second <source>
If I'm less than 800px wide I'll pick the last <source>
If I'm really old and don't support HTML5, I'll just render the <img> tag and use whatever is in its src attribute.

This gives us a HUGE amount of flexibility to show the most appropriate images for whatever browser our users are using, so after you've finished reading this article, have a look at the documentation - there's some great stuff you can do with pixel density selectors and more!

The most important element in the <picture> is still the <img> element - in fact, it's required otherwise old browsers can't render anything! That <img> controls how the final image is displayed - so that's what you should stick your CSS classes, titles and alt text to.

So that's how the HTML works, but how can we make that work in React? Very simply, as it turns out! In most of my web projects I create a component like the one below. Please note that it doesn't expose all the features of <picture>, only the ones I most commonly use:

function Picture({
  alt,
  className,
  fallback,
  sources,
  title,
}) {
  // I don't like typing out the <source> elements in full
  // so I just pass in the key properties
  const sourceElements = sources ? sources.map(s => {
    if (s.width) return (<source srcset={s.src} type={s.mime} media={`(min-width: ${s.width}px)`}/>)
    return (<source srcset={s.srcset} type={s.mime} />);
  }) : null;

  return (
    <picture>
      {sourceElements}
      <img src={fallback} className={className} title={title} alt={alt} />
    </picture>
  );
}

And to produce the example I showed at the start I use it like so:

import imageJpg from '../img/cat-1024x768.jpg';
import imageSmallJpg from '../img/cat-800x600.jpg';
import imageWebp from '../img/cat-1024x768.webp';

function HowToUseIt() {
  return (
    <Picture
      title="You should really title your images!"
      alt="You should alt text them too. Don't be lazy!"
      fallback={imageJpg}
      sources={[
        { src: imageWebp, mime: 'image/webp', width: 800 },
        { src: imageJpg, mime: 'image/jpg', width: 800 },
        { src: imageSmallJpg, mime: 'image/jpg' }
      ]}
    />
  );
}

Easy to read and easy to use! Drop it into your next project and hopefully watch your Lighthouse scores increase...

Thanks for reading! Let me know if you found it useful, and if you've got any improvements to make to my little component 😄