DEV Community: Fredrik Bergqvist

API Considerations for Beginners

Fredrik Bergqvist — Fri, 05 Sep 2025 00:00:00 +0000

When you’re starting out designing an API, there are a few things you’ll want to think about early on. Some of these will save you time down the road, others will help you avoid common mistakes that lead to bugs, confusion, or security holes. Here are the main points I keep in mind.

Versioning

Think about how you want to handle versioning from the start. Even if you don’t expect to support multiple versions right away, it’s often a good idea to include a version prefix in your paths, such as /v1/. That way, if you ever need to introduce breaking changes, you won’t have to redesign your whole URL structure.

Documentation

Take the time to document your API. Swagger (OpenAPI) is the most common way and comes with several benefits:

It’s easy to import into tools like Postman.
You can generate frontend methods, complete with TypeScript types and helpers.
- Kubb.dev has many plugins for automatic generation.
- I’ve also used swagger-typescript-api to generate types and TanStack Query hooks.
Swagger includes an SDK generator: swagger.io/tools/swagger-codegen.

On top of that, it’s worth keeping a simple README file with instructions on how to set up, build, and run your API server. It’s easy to forget these details, even for your own projects.

Caching

Caching can give you a big performance boost, but how you do it depends on the size and reliability of your system.

For small apps where it doesn’t matter if data has to be re-fetched on a restart, in-memory caching is usually enough. For bigger systems, or anything running multiple instances, you’ll want something more robust like Redis or Memcached so your caches stay in sync.

Use correct HTTP methods and responses

Using the right HTTP methods and returning the right status codes makes your API predictable and easier to use. Here’s the basic breakdown:

GET to fetch an entity → 200 OK
POST to create an entity → 201 Created with a Location header pointing to the new resource’s URL
PUT to replace an entity → 200 OK or 204 No Content
PATCH to update specific attributes on an entity → 200 OK or 204 No Content
DELETE to remove an entity → 200 OK or 204 No Content

You should also decide whether you want to return the full model after an update, or just 204 No Content. Either way is fine — the important thing is to be consistent.

Be careful with your error handling. Don’t return a generic 500 if the problem is really that the resource wasn’t found — that should be a 404. Similarly, use 409 Conflict when two updates clash, and return 400 Bad Request for validation errors.

Finally, pick a consistent error response format and stick with it. A simple structure like:

{
  "code": "invalid_input",
  "message": "Email is not valid",
  "details": {}
}

goes a long way toward making your API easier to consume.

Security

Always use HTTPS. This is the baseline for protecting data in transit.

If your API will be called from browsers, set up CORS to restrict which domains are allowed. Keep in mind that CORS is only a browser-level safeguard — other clients can still make requests — so you should always enforce security on the server too.

Authentication is another must. At the simplest level, you can require an API key. That’s easy to implement, but not very secure and only suitable for low-value data. For anything more important, go with JWTs or OAuth , which give you more control over permissions, expiry, and token management.

When it comes to error handling, don’t leak sensitive details. Stack traces and debug output don’t belong in responses. Always sanitize and validate inputs on the server, no matter how much you “trust” the client.

And finally, consider adding rate limiting or throttling. This prevents brute-force attacks and stops clients from overwhelming your service.

Monitoring and observability

If your API is critical, you’ll want visibility into how it’s behaving. Logging is the first step — make sure you record enough to debug issues later. But don’t stop there: set up alerts for spikes in errors or traffic, and keep an eye on key metrics like latency, error rates, and request volume. This will help you catch issues before users report them.

Listings

When your API returns lists of entities, you should almost always implement pagination. Dumping thousands of records in one response is wasteful and slow.

Sometimes, you don’t even need the full model. For example, if you’re filling a dropdown menu, you probably only need an id and a name. In these cases, consider adding lightweight listing endpoints that only return the fields needed. This makes responses faster and easier to work with.

Updating several items at once

Sometimes users want to perform bulk actions, like selecting multiple items and archiving them. There are a couple of ways to handle this.

For small updates, you can just use PATCH and only update the relevant property. The server should always apply the change against the latest version of the data.

For larger operations, a dedicated batch endpoint is often better. That way you can update multiple records in a single call, keeping everything consistent and reducing round trips.

Whichever approach you use, make sure the client has fresh data. A common pattern is to refetch whenever the browser tab regains focus, so users don’t accidentally update stale state.

Avoiding overwriting updates (concurrency)

A common issue in APIs is two people editing the same resource at the same time. Without safeguards, whoever saves last overwrites the other person’s changes.

One simple approach is to include a lastUpdated timestamp (or a version number) in each model. The client includes this value in its update request, and the server checks it against the database. If it doesn’t match, you know the resource has changed since the client last fetched it, and you can reject the update.

Another approach is to use ETags with the If-Match header. This is built into HTTP and works much the same way: the ETag identifies the version of the resource, and if it doesn’t match on update, the server returns 412 Precondition Failed.

For business-critical actions like payments, you should also consider supporting an Idempotency-Key header. This ensures retries don’t cause duplicate side effects if the client resends the same request after a timeout or network issue.

Testing

Even a little bit of testing can go a long way. Start with integration tests that just check status codes. This is enough to make sure all your endpoints respond correctly and helps you catch routing or method errors early.

For more important endpoints, add contract tests that validate not just the status but the shape and content of the response. That way, if someone changes a field name or removes a property, you catch it before clients break. If you have multiple services talking to each other, consumer-driven contract testing tools like Pact can be very helpful.

Automate tests where it makes sense. Even a small set of tests running in your CI pipeline can prevent regressions. Tools like Postman are great for exploration and manual checks, but don’t stop there — add unit tests and automated integration tests to round out your strategy.

Wrapping up

Designing APIs is partly about following conventions and partly about thinking ahead. By choosing consistent HTTP methods, handling concurrency, validating input, and writing at least some tests, you’ll avoid many of the pitfalls that trip up beginners.

You don’t need to over-engineer everything on day one, but if you keep these practices in mind, you’ll end up with an API that’s easier to maintain, safer to use, and friendlier to clients.

The curious case of the paragraph with the bad CLS

Fredrik Bergqvist — Tue, 03 Dec 2024 12:02:00 +0000

I recently migrated my personal website from Next.js to 11ty, it was a great experience, which I will write more about in a later blog post.

There was just one issue. The PageSpeed performance score actually went down. 😨

Link to PageSpeed.web.dev

Mobile performance was looking great, a 4 x 100 score, but desktop performance was hurting. The problem also only occurred on the blog post list page, not on the individual blog post pages, and only when the page width was greater than 960 pixels, when the max with of the content was set to a fixed value and margin auto.

After some digging, the culprit seemed to be a paragraph at the end of the blog post list, containing a link to older posts.

This is a version of the start page with the paragraph: Click for some bad CLS and the version without: Click for no bad CLS

When fiddling with it, I found that any block element (or even inline-block), would cause the issue, but using a span would not trigger it.

Now, I do understand that this, in reality, is a non issue, and really only proves the point that blindly following performance scores is not always the best way to go.

But I am still curious about why this is happening. If you have any insights, please let me know.

To be continued... (I hope)

Minified React error in production with Vite.js

Fredrik Bergqvist — Thu, 03 Nov 2022 16:02:24 +0000

At work I inherited a really old website running on React.

The code was good but by old i mean really old; last commit was 3 years ago and most of the code was 5-6 years old…

So I converted it to TypeScript and ripped out the old babel/webpack build system and installed Vite to handle all the builds.

Everything went pretty smoothly and I got the site up and running with no errors in development mode.

When going to production is when things went sideways. Some pages crashed with the following error:

error: Minified React error #130; visit https://reactjs.org/docs/error-decoder.html?invariant=130&args[]=object&args[]= for the full message or use the non-minified dev environment for full errors and additional helpful warnings.
    at vc (vendor.93c27df6.js:23)
    at d (vendor.93c27df6.js:23)
    at vendor.93c27df6.js:23
    at vendor.93c27df6.js:23
    at Ts (vendor.93c27df6.js:23)
    at ul (vendor.93c27df6.js:23)
    at ic (vendor.93c27df6.js:23)
    at tc (vendor.93c27df6.js:23)
    at ql (vendor.93c27df6.js:23)
    at zl (vendor.93c27df6.js:23)

Some quick googling led me to a GitHub issue showing me that I was not the only one experiencing this bug.

Package problem number one

It seems that esbuild is checking for __esModule at runtime and rollup (which is used internally in Vite) is not.

So it will happen to any library that has an entry point with: module.exports = require("./module");

Since a file exported this way does not include the ‘magic string’ __esModule as checked by generate-exports.js it’s not converted correctly.

In my case I had two librarys acting up; react-datetime which was imported locally like this: import DateTime from "react-datetime"; which worked fine in Vite dev but not production.

Props to ntkoopman for the explanation.

Solution

User Haikyuu suggested using the following solution which is what I used in the end.

import DT from "react-datetime";
// @ts-ignore
const DateTime = DT.default ? DT.default : DT;
Package problem number two
The second package with this issue was react-dropzone which in turn used the real culprit; attr-accept

Since the project used an old version (4.x.x, latest version is at the time of writing 14.x.x) and I got other issues upgrading to the latest version I could rule out a PR from me fixing it.

Solution number two

Instead I used patch-package and postinstall to create a patch-file with the fix.

//from
import accepts from 'attr-accept';

//to
import A from "attr-accept";
const accepts = A.default ? A.default : A;

I how this can help if someone is stuck, and I hope it will be fixed soon because it is kind of a blocker for using Vite.js in production

CSS modules in next.js

Fredrik Bergqvist — Sat, 13 Nov 2021 16:46:34 +0000

On bergqvist.it I used styled jsx for styling my components. I preferred that to other css-in-js frameworks (like JSS) because of it actually using CSS syntax instead of JavaScript objects.

    // styled jsx example with good old CSS
    <style jsx>{`
      .label { color: red; font-style: italic; }
      .article { padding: 0; }
    `}
    </style>

    //JSS example with CSS as a JS object
    const useStyles = createUseStyles({
      label: {
        color: 'red'
        fontStyle: 'italic'
      },
      article: {
        padding: 0
      }
    })

I like Styled jsx but it has had an issue with FOUC in the last few versions of Next.js though, and with Next 12 I decided to try something new and migrate to CSS Modules instead.

What is CSS Modules?

A CSS Module is a CSS file in which all class names and animation names are scoped locally by default.

So the benefit are the same as css-in-js-frameworks but pure css (or in my case scss) files are used instead of keeping the styling in the javascript files.

Why CSS Modules?

I may be old school, but I actually prefer to keep the CSS and JavaScript separated for each other. I can see the benefits of keeping them tightly coupled and can agree that simple, self-contained components probably benefit from this approach, but it gets messy when the component has many styles with media queries.

I also want to use SASS, which is fully supported with CSS Modules in Next.js.

Migrating from styled jsx to CSS Modules

Since Styled jsx use regular CSS it’s actually just a matter of creating the <component>.module.scss-file, importing it into the component and changing the classes

    //styled jsx
    export default function MyComponent(){
      return (<div className={"article"}>
        <span className={"label"}>...</span>
        <style jsx>{`
          .label { color: red; font-style: italic; }
          .article { padding: 0; }
        `}</style>
      </div>)
    }

    //CSS Modules
    import styles from "./MyComponent.module.scss";

    export default function MyComponent(){
      return (<div className={styles.article}>
        <span className={styles.label}>...</span>
      </div>)
    }

Using multiple modules in one component

For reusability you might want to use a css module in more than one component

    import styles from "./MyComponent.module.scss";
    import * as secondaryStyles from "./secondary.module.scss";

    export default function MyComponent(){
      return (<div className={styles.article}>
        <span className={secondaryStyles.label}>...</span>
      </div>)
    }

If you are using TypeScript this approach probably cause an error: TS2339: Property 'label' does not exist on type 'typeof import("*.module.scss")'.

The error can be can be mitigated by adding a typings.d.ts -file to the root of your project with the following content

    // typings.d.ts
    declare module "*.module.scss" {
      interface IClassNames {
        [className: string]: string;
      }
      const classNames: IClassNames;
      export = classNames;
    }

Composition

Instead of importing several different modules it’s possible to compose new classes from existing classes.

    // secondary.module.scss
    .label { 
      color: red; 
      font-style: italic; 
    }

    // MyComponent.module.scss
    .article { 
      padding: 0; 
    }
    .label {
      composes: label from "./secondary.module.scss";
    }

    // MyComponent.tsx
    import styles from "./MyComponent.module.scss";

    export default function MyComponent(){
      return (<div className={styles.article}>
        <span className={styles.label}>...</span>
      </div>)
    }

Global styles

As I already had a global css-file that I imported into my _app.tsx, I really did not have to do anything to get my global classes working.

If you want to add a global class in a component file you can add it by using :global() on the class.

    :global(.label) { 
      color: red; 
      font-style: italic; 
    }

Parting words

I’m quite happy with CSS Modules, the site no longer gets FOUC and it looks great with JavaScript disabled as well!

Hope this could be of any help to someone looking into CSS Modules.

Tips and tricks for testing with Jest

Fredrik Bergqvist — Mon, 29 Jun 2020 12:36:49 +0000

Writing tests can be daunting when starting out, it’s hard to know exactly what to test and then learning the API for your test tool.

I wanted to share some small tips that can be useful when starting out.

expect.objectContaining()

In some cases you are only interested in the value of one or just a few properties in an object. To check for a specific property you can use expect.objectContaining to check if the object contains a property with the expected value.

In the code below we’re checking if a report dialog function has been called with the users name and email.

The actual object is much larger but we don’t really care about the other properties, in this case the user information is the moving parts in the object.

expect(showReportDialog).toHaveBeenCalledWith(
  expect.objectContaining({
    user: {
      name,
      email,
    }
  })
);

expect.anything()

Callback functions or randomly generated values can sometimes be a hassle to handle in tests since they might change, but it is possible to ignore specific properties or arguments using expect.anything.

function loadScript(scriptUrl:string, callback:() => unknown) { ... }

When testing the above function we ’re not interested in the callback function and only wants to check if loadScript have been called with the correct script.

it("should call loadScript", () => {
  someFunctionUsingLoadScript();

  expect(loadScript).toHaveBeenCalledWith(
    "script.js",
    expect.anything()
  );
}

expect.anything does not match null or undefined values

expect.any()

Another way to match more broadly is expect.any(constructor) where you can accept any match based on the constructor being passed to it.

expect(someFn).toHaveBeenCalledWith({
  someNumber: expect.any(Number),
  someBoolean: expect.any(Boolean),
  someString: expect.any(String)
});

expect.assertions()

When doing asynchronous tests it can be helpful to make sure that all assertions have been run when the test ends.

The expect.assertions(Number) ensures that the correct number of assertions have been made.

test('prepareState prepares a valid state', () => {
  expect.assertions(1);
  prepareState((state) => {
    expect(validateState(state)).toBeTruthy();
  })
  return waitOnState();
})

test.each

For some unit tests you may want run the same test code with multiple values. A great way to do this is using the test.each function to avoid duplicating code.

Inside a template string we define all values, separated by line breaks, we want to use in the test. The first line is used as the variable name in the test code.

test.each`
  someId
  ${undefined}
  ${null}
  ${""}
`("$someId should reject promise", async ({ someId}) => {
  expect.assertions(1);
  await expect(someFn(someId))
    .rejects.toEqual(errorMessage);
});

Multiple input variables can be added separated by the pipe (|) character.

test.each`
  someId | anotherValue
  ${undefined} | ${a}
  ${null} | ${b}
  ${""} | ${c}
`("$someId with $anotherValue should reject promise", async ({ someId, anotherValue }) => {
  expect.assertions(1);
  await expect(someFn(someId, anotherValue))
    .rejects.toEqual(errorMessage);
});

Note: it is also possible to define the values as arrays, read more in the official documentation.

jest.requireActual

This is just a reminder never to forget adding jest.requireActual when mocking libraries. If you do forget, it can lead to weirdness that may take several hours to solve (talking from personal experience here 😁).

So what does it do?

When mocking a library you may only want to mock a specific function of the library and keep the rest of the library intact.

jest.mock("@material-ui/core", () => ({
  ...jest.requireActual("@material-ui/core"),
  useMediaQuery: jest.fn()
}));

So in the code above we create a new mock object, using jest.requireActual to spread all the functions of the library and only mock useMediaQuery in this case.

Extending the theme in Material UI with TypeScript

Fredrik Bergqvist — Fri, 26 Jun 2020 21:46:07 +0000

When we started using Material UI (version 3) the support for extending the built-in theme was pretty lacking. The theme interface did not handle any additional color settings such as "success" or "warn" and trying to extend the theme did not work since parts of interfaces can't be overwritten.

So instead of extending the theme we used a separate object with corresponding interface to handle the extra colors that we needed. Not ideal but as the colors only were used in a few places we could afford to wait for the support in MUI to get better.

Flash forward a year and the support is here so extend the theme we did!
The documentation tells us to use module augmentation to merge our theme with the built-in theme by creating a index.d.ts file and adding our properties in that.

The official way of doing it

So if I want to extend the typography object to accept a secondaryFontFamily I would have to do something like this:

declare module "@material-ui/core/styles/createTypography" {
  interface TypographyOptions {
    secondaryFontFamily: string;
  }
  interface Typography {
    secondaryFontFamily: string;
  }
}

And then creating a custom theme factory function to create the theme.

import { createMuiTheme} from '@material-ui/core/styles';

export const createMyTheme():CustomTheme => createMuiTheme({
  palette: createPalette({}),
  typography: {
    secondaryFontFamily: "Georgia"
  }
});

This works well but still uses the Theme interface which makes it harder to know what has been extended.

Our project setup

We package our code in different NPM packages and use Lerna to handle the development environment.

That means that the theme is used over several packages and when we implemented the solution above we quickly realized that we had to add the index.d.ts file in every project, making it very cumbersome to add new attributes in the future.

Back to the drawing board.

A different solution

So we need an interface for our customised theme that we can share with our packages.

import React from "react";
export interface CustomTypography extends Typography {
  secondaryFontFamily: string;
}
export interface CustomTheme extends Theme {
  typography: CustomTypography;
}

export const createMyTheme():CustomTheme => createMuiTheme({
  palette: createPalette({}),
  typography: {
    secondaryFontFamily: "Georgia"
  }
});

That will unfortunately result in the following error:

TypeScript does not allow interfaces to be merged and since CustomTheme extends Theme it seemed that we are out of luck.

Then I discovered Omit.

TypeScript Omit to the rescue!

Omit<T,K> is an utility type that constructs a type by picking all properties from T and then removing K.

So by using Omit we can create our own utility type Modify. (Props to Qwerty )

type Modify<T, R> = Omit<T, keyof R> & R;

Which will merge two interfaces, removing any members on T that exists in R and then adding R to the resulting type.

So using Modify we can do this instead:

import { Theme } from "@material-ui/core";
import { Typography } from "@material-ui/core/styles/createTypography";

export type CustomTypography = Modify<
  Typography,
  {
    secondaryFontFamily: string;
  }
>;

export type CustomTheme = Modify<
  Theme,
  {
    typography: CustomTypography;
  }
>;


export const createMyTheme():CustomTheme => {
  const baseTheme = createMuiTheme({
    palette: createPalette({})
  });

  return {
    ...baseTheme,
    typography: {
      secondaryFontFamily: "Georgia"
    }
  }
});

And use it in our app like this:


const MyApp = () => {
const myTheme = createMyTheme();
  return (
    <ThemeProvider<CustomTheme> theme={myTheme}>
      <CssBaseline />
        <SomeComponent />
    </ThemeProvider>
  );
};

I hope this can help get someone with the same problem some ideas and if you have solved the problem in another way, please let me know.

Mocking redux useSelector-hook

Fredrik Bergqvist — Thu, 19 Mar 2020 22:54:57 +0000

Update
There is an official way of using RTL with redux as some people pointed out in the comments but I never got it to work.
It may be me being incompetent or something in my project that causes issues so my solution to only mock useSelector may still be of use. 🙄

Recently I finally made the switch from Enzyme to React testing library (RTL) which also means that instead of rendering components using shallow like Enzyme proposes, with React testing library the whole component and its child components is rendered, much like Enzymes mount.

The switch to RTL coupled with using hooks instead of HOCs when using Redux got me writing a lot of new component tests but I did run in to some problem when I tried to use the useSelector-hook from Redux multiple times expecting different responses.

The component that I wanted to test as a search component that made calls similar to this:

const MySearchComponent = () => {
  const { query, rows } = useSelector((state) => 
    state.config);

  const {
      items,
      hasMore
    } = useSelector((state) => state.search);

  return (...)
}

useSelector takes a callback function that takes the state as an argument and returns a slice of the state.

So my first approach when trying to test the component was to send two different responses.

jest.mock("react-redux", () => ({
  ...jest.requireActual("react-redux"),
  useSelector: jest.fn()
    .mockReturnValueOnce(mockConfigState)
    .mockReturnValueOnce(mockSearchState)
}));

describe("MySearchComponent", () => {
  afterEach(() => {
    useSelector.mockClear();
  });
  it("should render", () => {
    const { getByTestId } = render(<MySearchComponent />);
    expect(...)
  });
});

Which worked fine until I realised that a child component also calls useSelector and therefore crashed. 😱

I knew I needed something that would support all possible selectors that I needed but still could be modified on a test by test basis.
I had a mock state ready, but not the method to alter and inject it.
Until I ran across jest.fn().mockImplementation...

The solution to my problems

useSelector takes a callback as its argument and all I had to do was to call that callback with a compatible state that would satisfy all my components needs and they would do the rest as implemented.

jest.mock("react-redux", () => ({
  ...jest.requireActual("react-redux"),
  useSelector: jest.fn()
}));

describe("MySearchComponent", () => {
  beforeEach(() => {
    useSelector.mockImplementation(callback => {
      return callback(mockAppState);
    });
  });
  afterEach(() => {
    useSelector.mockClear();
  });
  it("should render a query", () => {
    const { getByTestId } = render(<MySearchComponent />);
    expect(getByTestId("query_testId").textContent)
      .toEqual(mockAppState.config.query)
  });
  it("should not render if query is empty", () => {
      const localMockState = {
        ...mockAppState,
        config: {
          ...mockShoppingState.config,
          query: ""
        }
      };
      useSelector.mockImplementation(callback => {
        return callback(localState);
      });
    const { queryByTestId } = render(<MySearchComponent />);
    expect(queryByTestId("query_testId")).toBeNull();
  });
});

So in the code above I mock useSelector from the react-redux npm package and replaces it with a function that executes any given callback function with my mocked state as an argument. This is done before every test.

In the second test I create a second mocked state that I want to use for just that test so I override useSelector to make sure it uses my updated state instead of the default mock state.

Parting words

I hope this helped someone to learn a little bit more about how to test their code and what can be achieved with jest and tools like RTL (which is great, try it!)

All typos my own and please leave a comment if you have a question or something does not make sense.

How to add an RSS-feed to your Next.js site

Fredrik Bergqvist — Mon, 02 Dec 2019 12:15:52 +0000

I love RSS-feeds (and still curse Google for cancelling Google Reader) and use them as my main news source for things I find interesting so with this article I would like to help people to add RSS-feeds to their blogs.

If you read my article about how to add a sitemap.xml to your next.js site you will recognise much of the code, it's pretty much the same base but with slightly different XML-markup.

Creating the page

First off we need a page that can return the XML. I suggest you name it "rss", "feed" or something similar.

In getInitialProps we get our blog posts and set the "Content-Type"-header to "text/xml" so the browser knows that should expect XML instead of HTML.
We then generate the XML and passes it on to the browser using res.write.

export default class Rss extends React.Component {
  static async getInitialProps({ res }: NextPageContext) {
    if (!res) {
      return;
    }
    const blogPosts = getRssBlogPosts();
    res.setHeader("Content-Type", "text/xml");
    res.write(getRssXml(blogPosts));
    res.end();
  }
}

Generating the base XML for the feed

For the base XML document you will need to add some basic information like the title of the log, a short description, link to your website and the language of the content.
Title, link and description are mandatory elements in the RSS specification but add as many optional elements as you find useful.

const getRssXml = (blogPosts: IBlogPost[]) => {
  const { rssItemsXml, latestPostDate } = blogPostsRssXml(blogPosts);
  return `<?xml version="1.0" ?>
  <rss version="2.0">
    <channel>
        <title>Blog by Fredrik Bergqvist</title>
        <link>https://www.bergqvist.it</link>
        <description>${shortSiteDescription}</description>
        <language>en</language>
        <lastBuildDate>${latestPostDate}</lastBuildDate>
        ${rssItemsXml}
    </channel>
  </rss>`;
};

Adding XML for the blog items

With the basic stuff out of the way all we need to go is generate some XML for the blog posts and figure out when the blog was updated.

The item element should at least contain a link to the blog post, the date when it was published and the text. You can either opt to put a short description and force the user to come visit your page or put the whole post in the XML.

If you have HTML-markup in your text you need to enclose it within a <![CDATA[${post.text}]]>-tag or HTML encode the text.

const blogPostsRssXml = (blogPosts: IBlogPost[]) => {
  let latestPostDate: string = "";
  let rssItemsXml = "";
  blogPosts.forEach(post => {
    const postDate = Date.parse(post.createdAt);
    if (!latestPostDate || postDate > Date.parse(latestPostDate)) {
      latestPostDate = post.createdAt;
    }
    rssItemsXml += `
      <item>
        <title>${post.title}</title>
        <link>
          ${post.href}
        </link>

        <pubDate>${post.createdAt}</pubDate>
        <description>
        <![CDATA[${post.text}]]>
        </description>
    </item>`;
  });
  return {
    rssItemsXml,
    latestPostDate
  };
};

Finishing up

The last thing you need to do is to add a link to your feed somewhere in the head of your document.

<link 
  rel="alternate" 
  type="application/rss+xml" 
  title="RSS for blog posts" 
  href="https://www.bergqvist.it/rss" />

This will make it easier for browsers and plugins to auto discover your feed.

The code is available as a gist on github and please leave a comment with any feedback.

Adding a dynamic sitemap.xml to a next.js site

Fredrik Bergqvist — Fri, 22 Nov 2019 13:52:07 +0000

While building my blog with Next.js I naturally wanted to support sitemaps because it can supposedly help out the search engines. For my small blog it will not make any difference but for larger sites it's more important. Google has this to say.

Using a sitemap doesn't guarantee that all the items in your sitemap will be crawled and indexed, as Google processes rely on complex algorithms to schedule crawling. However, in most cases, your site will benefit from having a sitemap, and you'll never be penalized for having one.

Page for the sitemap

The first thing we need to do is to create a sitemap.xml.ts page in the "page"-folder. This will expose a https://yourdomain.com/sitemap.xml url that you can submit to search engines. if you want to you can omit the .xml part and only use /sitemap, Google search console will accept the url anyway.

We want to make sure that we set the Content-Type header to text/xml and to write our xml output to the response stream.

export default class Sitemap extends React.Component {
  static async getInitialProps({ res }: any) {
    const blogPosts = getBlogPosts();
    res.setHeader("Content-Type", "text/xml");
    res.write(sitemapXml(blogPosts));
    res.end();
  }
}

Generating the base xml

For the site map we want to list all pages on the site, apart from the blog posts we have to add all additional pages that we want the search engines to find.

I have an about page that I add manually together with the index page but if you have many pages I suggest you create an array and add them in a more automated way.

I won't go into the inner workings of all the properties of a sitemap but I want to mention the <priority>-tag that lets you set a value between 0 and 1 indicating how important you think the page is.
<lastmod> is used to indicate when the page was changed.

const sitemapXml = (blogPosts: IBlogPostListItem[]) => {
  const { postsXml, latestPost } = blogPostsXml(blogPosts);
  return `
  <?xml version="1.0" encoding="UTF-8"?>
    <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
    <url>
      <loc>https://www.bergqvist.it/</loc>
      <lastmod>${latestPost}</lastmod>
      <priority>1.00</priority>
    </url>
    <url>
      <loc>https://www.bergqvist.it/about</loc>
      <priority>0.5</priority>
    </url>
    ${blogPostsXml}
  </urlset>`;
};

Adding xml for the blog posts

As mentioned above I want to add the dynamic blog post pages to the site map as well. In the blogPostsXml-function I generate xml for all posts and keep track of when the latest post was posted.

const blogPostsXml = (blogPosts: IBlogPostListItem[]) => {
  let latestPost = 0;
  let postsXml = "";
  blogPosts.map(post => {
    const postDate = Date.parse(post.createdAt);
    if (!latestPost || postDate > latestPost) {
      latestPost = postDate;
    }
    postsXml += `
    <url>
      <loc>${post.url}</loc>
      <lastmod>${postDate}</lastmod>
      <priority>0.80</priority>
    </url>`;
  });
  return {
    postsXml,
    latestPost
  };
};

Last words

Make sure to check that you do not add any pages to the sitemap that is blocked in your robots.txt.

If you have a large site with many pages (100 or more) you can split up the sitemap into several smaller ones, for very large sites this is a must!

I hope this could help out someone and please leave a comment. A full gist of the code can be found here

SmashingConf New York 2019

Fredrik Bergqvist — Wed, 20 Nov 2019 22:00:09 +0000

A few weeks ago I had the privilege of attending SmashingConf in New York, travelling from a chilly Swedish autumn to a quite pleasant New York end of summer. I spent the weekend fighting jet lag by taking long walks and touristing so I could be fit for the first workshop I had signed up for.

TL;DR

Great conference but not technical enough for my taste.

Watch Wes Bos's talk (slides) for good javascript insights and all talks can be found here: SmashingConf NY 2019 videos.

Lightning fast performance with Scott Jehl.

Spending a whole day digging deep into performance sounded like a great way to spend a Monday so I had booked.
The venue for the workshop was located at Microsoft, just a short walk from my hotel so I had plenty of time to get a good nights sleep, eat a steady breakfast and still make the 9 o'clock start without any problems.

Scott Jehl was really easy going and the workshop covered tools to measure performance and how to mitigate issues.
I would however have liked more nitty gritty details and less time spent on using online tools.

The Move Fast & Don't Break Things-talk that Scott held on the second day of the conference was a distilled version of the workshop so check it out if you're interested.

In the evening I attended a Shopify-hosted jam session with lightning talks from Shopify, Microsoft, Forestry (about TinaCMS!) and a few others talkers.

Conference day one

The conference took place at the New world stages close to time square.
The main stage was a musical theatre which worked well but the rest of the venue was quite cramped.

Many of the talks were more of the UX/inspirational kind which can be nice, but I'm more of a hands on person so my favourites were the following.

Marcy Sutton on Garbage Pail Components is a talk about accessibility with an 80's twist (and not even the first 80's flashback this conference).

Wes Bos on Slam Dunk Your JavaScript Fundamentals is jam packed with new APIs that you might not have heard of yet, especially the Intl-object.

In the evening the SmashingConf party took place at Waylon bar where speakers and participants got to mingle. I met lots of friendly people from both sides of the pond and had a great time.

Conference day two

With a slight hangover and not enough sleep I went to see the mystery speaker dina Amin who makes wonderful stop-motion shorts with old discarded electrical devices.

Another fun talk was the Using a Modern Web to Recreate 1980s Horribly Slow & Loud Loading Screen-talk where Remy Sharp recreated the loading screens of his old 80's Sinclair Spectrum computer. All ending with a photo of the audience being transformed to the Spectrum image format and shown on the big screen

Next.js with Remy Sharp

With the conference over I still had a workshop day to look forward to so I went back to the Microsoft office to learn some next.js!

The workshop was good with all the basics of next.js covered, I had already tinkered with next.js (my homepage runs for example) so most things were familiar but luckily I had not read up on the changes in 9.1 so I did learn some new tricks.

All in all I had a great week in NYC and I met lots of great people but I would have liked if the conference and workshops were a bit more technical.

Typing React with typescript

Fredrik Bergqvist — Sat, 18 May 2019 20:22:16 +0000

TypeScript has really taken off lately in the React world and rightly so, it's a great way to keep your code documented and help you keep some errors at bay.

I have worked with TypeScript in a few projects the last few years, all involving Angular in some form but never with React so I had some new challenges in front of me when I started my current project with React and TypeScript.

Functional components

Let us start off easy with a basic functional component:

interface OwnProps {
  myProp:string;
}

const MyButton: React.FC<OwnProps> = (props) => {
  return (<button />);
}

export default MyButton as React.ComponentType<OwnProps>;

We create an interface called OwnProps where we define all props we want the component to have.

OwnProps is then used to define the component: React.FC<OwnProps> as well as when we export the component as React.ComponentType<OwnProps> to clearly signal what props are available.

In this basic example it may seem unnecessary but, as we shall see further down, when components get more complex it will save us some headache.
This approach will also help negate the following error:

error TS2604: JSX element type 'MyComponent' does not have any construct or call signatures.

Wrapping another component

In some cases you might want to wrap another component and include that components interface in your own. This is usually the case when working with base components from a library and since we use Material UI (MUI for short)as a base component library I will use that in the example.

interface OwnProps {
  buttonText:string;
}
type Props = OwnProps & ButtonProps;

const MyButton: React.FC<Props> = ({buttonText, ...rest}) => {
  return (<Button {...rest}>{buttonText}</Button>);
};

export default MyButton as React.ComponentType<Props>;

The Props type can be seen as the sum of all parts that the component will consist of. In this case we want to use ButtonProps from MUIs Button component and merge it with our own and expose both props to the consumers of the component.

This is still not very advanced but since we use MUI we also use JSS for styling so let us add that to the mix!

Using WithStyles and WithTheme

Since we use MUI we handle styling with JSS and the generated CSS classes are injected via the withStyles HOC. This caused some issues since a classes object containing the class names is injected into your props and to use classes you would need to include that object in your prop type.

Luckily we have the WithStyles type to help us!
WithStyles<typeof styles> takes a generic type argument of your style object so you don't have to worry about it keeping your types DRY.

The typescript section at Material UI explains the problems with withStyles more in detail, ready up on it if you plan to use MUI and TypeScript.

const styles: (theme: Theme) => StyleRules<string> = theme =>
  createStyles({
    root: {
      margin: theme.spacing.unit
    }
  });
interface OwnProps {
  buttonText:string;
}
type PublicProps = OwnProps & ButtonProps;
type Props = PublicProps & WithStyles<typeof styles>;
const MyButton: React.FC<Props> = ({classes, buttonText, ...rest}) => {
  return (
    <Button {...rest} className={classes.root}>
      {buttonText}
    </Button>);
};
export default withStyles(styles)(MyButton) as React.ComponentType<PublicProps>;

The addition we've done here is adding a PublicProps type and using that instead of the Props type when exporting the component. This is of course because we also want to use WithStyles but not expose it to anyone using the button.

Had we used the Props type instead of PublicProps we would get a pesky TypeScript error complaining about classes property missing.

Redux connect and compose

But what would React be without state handling? We use Redux for this so let us connect MyButton and get the buttonText prop from state instead.

const styles: (theme: Theme) => StyleRules<string> = theme =>
  createStyles({
    root: {
      margin: theme.spacing.unit
    }
  });

interface StateProps {
  buttonText:string
}
interface DispatchProps {
  dispatch: ThunkDispatch<IAppState, undefined, Action>;
}
interface OwnProps {}
type PublicProps = OwnProps & ButtonProps;
type Props = PublicProps & 
             DispatchProps & 
             StateProps & 
             WithTheme &
             WithStyles<typeof styles>;

const MyButton: React.FC<Props> = ({classes, buttonText, ...rest}) => {
  return (
    <Button {...rest} className={classes.root}>
      {buttonText}
    </Button>);
};

const mapStateToProps = (state: IAppState): StateProps => {
  return {
    buttonText: state.buttonText
  };
};

export default compose(
  withStyles(styles, { withTheme: true }),
  connect<StateProps, DispatchProps, OwnProps, IAppState>(mapStateToProps)
)(MyButton) as React.ComponentType<PublicProps>;

We have not started using hooks for our state so we go with the good old connect. Since we now use both connect and withStyles we need to use compose to merge them.

We create StateProps as return type of mapStateToProps and DispatchProps which types the dispatch function that is returned by default if we don't add a mapDispatchToProps function. In out case we use Thunk so if you use some other tool you need to use that instead.

I have also added an example of using the MUI theme in the component, this is done by adding { withTheme: true } as a second argument to withStyles.
This will inject a theme property into your props so we need to specify that in our Props type using WithTheme from MUI.

Bonus: typing the useState hook

Not really rocket science but good to know!

const [state, setState] = useState<string>("Hello world!")`

End note

TypeScript can be very frustrating when starting out with many errors that are not clear so I hope this article could be of some help or inspiration, it took us a while to settle on a TypeScript pattern that worked for us and helped us mitigate most of the errors that might occur when working with different libraries.

Feel free to leave any suggestions in the comment field.

A gist of the code examples are available at GitHub.