DEV Community: Dennis Persson

Open/Closed Principle (OCP)

Let's continue with the Open/Closed principle, after all, it's the next letter in SOLID. OCP is as well as SRP one of the easier principle to understand, at least its definition.

// Open/Closed Principle
Software entities (classes, modules, functions, etc.) should
be open for extension, but closed for modification

In words for dummies who recently have started with React, the sentence can be translated to:

Write hooks/component which you never will have a reason to 
touch again, only re-use them in other hooks/components

Think back at what was said for the single responsibility principle earlier in this article; in React, your are expected to write small components and compose them together. Let's look at why that is helpful.

import { useState } from 'react'
import { getUser, updateUser } from 'somewhere'

const useUser = ({ userType }) => {
  const [user, setUser] = useState()

  useEffect(() => {
    const userInfo = getUser()
    setUser(userInfo)
  }, [])

  const updateEmail = (newEmail) => {
    if (user && userType === 'admin') {
      updateUser({ ...user, email: newEmail })
    } else {
      console.error('Cannot update email')
    }
  }

  return { user, updateEmail }
}

The hook above fetches a user and returns it. If the type of the user is an admin, the user is allowed to update its email. A regular user is not allowed to do update its email.

The above code would definitely not get you fired. It would annoy the backend guy in your team though, the dude who reads design pattern books as bedtime stories for his toddlers. Let's call him Pete.

What would Pete complain about? He would ask you to rewrite the component as shown below. To lift out the admin functionalities to it's own useAdmin hook, and leave the useUser hook with no other features than those that should be available for regular users.

import { useState } from 'react'
import { getUser, updateUser } from 'somewhere'

// useUser does now only return the user, 
// without any function to update its email.
const useUser = () => {
  const [user, setUser] = useState()

  useEffect(() => {
    const userInfo = getUser()
    setUser(userInfo)
  }, [])

  return { user }
}

// A new hook, useAdmin, extends useUser hook,
// with the additional feature to update its email.
const useAdmin = () => {
  const { user } = useUser()

  const updateEmail = (newEmail) => {
    if (user) {
      updateUser({ ...user, email: newEmail })
    } else {
      console.error('Cannot update email')
    }
  }

  return { user, updateEmail }
}

Why did Pete ask for this update? Because that disrespectful picky prick Pete would rather want you to spend time rewriting that hook now, and come back with a new code review tomorrow, instead of potentially having to update the code with a tiny new if statement in the future, if there ever would be another type of user.

Well, that's the negative way to put it... The optimistic way, is that with this new useAdmin hook, you don't have to change anything in the useUser hook when you intend to implement features that affects admin users only, or when you add new types of users.

When new user types are added, or when useAdmin hook is updated, there's no need to mess with the useUser hook or update any of its tests. Meaning, you don't have to accidentally ship a bug to regular users when you add a new user type, e.g. a fake user. Instead, you just add a new userFakeUser hook and your boss won't call you in at 9 pm on a Friday because customers experience problems with fake data being shown for their bank account on a salary weekend.

Pete's son knows to be careful about spaghetti code developers

Why Use OCP in React?

It's arguable how many hooks and components a React project should have. Each one of them comes with a cost of renderings. React isn't a Java where 22 design patterns leads to 422 classes for a simple TODO list implementation. That's the beauty of the Wild West Web (www).

However, open/closed principle is clearly a handful pattern to use in React as well. The example with the hooks above was minimal, the hooks didn't do very much. With more substantive hooks and larger projects this principle becomes highly important.

It might cost you some extra hooks, and take slightly longer to implement, but your hooks will become more extendable, meaning that you can re-use them more often. You will have to rewrite the tests less often, making the hooks more solid. And most important, you won't create bugs in old code if you never touch it.

God knows not to touch things which aren't broken

React Anti-Patterns and Best Practices - Do's and Don'ts

Dennis Persson ・ Feb 5 '23

#javascript #webdev #programming #beginners

Liskov Substitution Principle (LSP)

Aaah, the name... Who the hedge is Liskov? And who will substitute her? And the definition, doesn't it even make sense?

If S subtypes T, what holds for T holds for S

This principle is clearly about inheritance, which isn't naturally practiced as much in React or JavaScript as in most of the backend languages. JavaScript didn't even have classes until ES6, that was introduced around 2015/2016 as syntactical sugar to prototype based inheritance.

With that in mind, the use cases of this principle really depends on what your code looks like. A principle similar to Liskov's that would make sense in React, could be:

If a hook/component accepts some props, all hooks and components 
which extends that hook/component must accept all the props the 
hook/component it extends accepts. The same goes for return values.

To illustrate an example of this, we can look at two storage hooks, useLocalStorage and useLocalAndRemoteStorage.

import { useState } from 'react'
import { 
  getFromLocalStorage, saveToLocalStorage, getFromRemoteStorage 
} from 'somewhere'

// useLocalStorage gets data from local storage.
// When new data is stored, it calls saveToStorage callback.
const useLocalStorage = ({ onDataSaved }) => {
  const [data, setData] = useState()

  useEffect(() => {
    const storageData = getFromLocalStorage()
    setData(storageData)
  }, [])

  const saveToStorage = (newData) => {
    saveToLocalStorage(newData)
    onDataSaved(newData)
  }

  return { data, saveToStorage }
}

// useLocalAndRemoteStorage gets data from local and remote storage.
// I doesn't have callback to trigger when data is stored.
const useLocalAndRemoteStorage = () => {
  const [localData, setLocalData] = useState()
  const [remoteData, setRemoteData] = useState()

  useEffect(() => {
    const storageData = getFromLocalStorage()
    setLocalData(storageData)
  }, [])

  useEffect(() => {
    const storageData = getFromRemoteStorage()
    setRemoteData(storageData)
  }, [])

  const saveToStorage = (newData) => {
    saveToLocalStorage(newData)
  }

  return { localData, remoteData, saveToStorage }
}

With the hooks above, useLocalAndRemoteStorage can be seen as a subtype of useLocalStorage, since it does the same thing as useLocalStorage (saves to local storage), but also has extended the capability of the useLocalStorage by saving data to an additional place.

The two hooks have some shared props and return values, but useLocalAndRemoteStorage is missing the onDataSaved callback prop which useLocalStorage accepts. The name of the return properties are also named differently, local data is named as data in useLocalStorage but named as localData in useLocalAndRemoteStorage.

If you would ask Liskov, this would have broken her principle. She would be quite furious actually when she would try to update her web application to also persist data server side, just to realize that she cannot simply replace useLocalStorage with useLocalAndRemoteStorage hook, just because some lazy fingered developer never implemented the onDataSaved callback for the useLocalAndRemoteStorage hook.

Liskov would bitterly update the hook to support that. Meanwhile, she would also update the name of the local data in the useLocalStorage hook to match the name of the local data in useLocalAndRemoteStorage.

import { useState } from 'react'
import { 
  getFromLocalStorage, saveToLocalStorage, getFromRemoteStorage 
} from 'somewhere'

// Liskov has renamed data state variable to localData
// to match the interface (variable name) of useLocalAndRemoteStorage.
const useLocalStorage = ({ onDataSaved }) => {
  const [localData, setLocalData] = useState()

  useEffect(() => {
    const storageData = getFromLocalStorage()
    setLocalData(storageData)
  }, [])

  const saveToStorage = (newData) => {
    saveToLocalStorage(newData)
    onDataSaved(newData)
  }

  // This hook does now return "localData" instead of "data".
  return { localData, saveToStorage }
}

// Liskov also added onDataSaved callback to this hook,
// to match the props interface of useLocalStorage.
const useLocalAndRemoteStorage = ({ onDataSaved }) => {
  const [localData, setLocalData] = useState()
  const [remoteData, setRemoteData] = useState()

  useEffect(() => {
    const storageData = getFromLocalStorage()
    setLocalData(storageData)
  }, [])

  useEffect(() => {
    const storageData = getFromRemoteStorage()
    setRemoteData(storageData)
  }, [])

  const saveToStorage = (newData) => {
    saveToLocalStorage(newData)
    onDataSaved(newData)
  }

  return { localData, remoteData, saveToStorage }
}

By having common interfaces (ingoing props, outgoing return values) to hooks, they can become very easy to exchange. And if we should follow the Liskov substitution principle, hooks and components which inherits another hook/component should be possible to substitute with the hook or component it inherits.

Liskov gets disappointed when developers don't follow her principles

Why Use LSP in React?

Even though inheritance isn't very prominent in React, it's definitely used behind the scenes. Web applications can often have several similar looking components. Texts, titles, links, icon links and so on are all similar types of components and can benefit of being inherited.

An IconLink component may or may not be wrapping a Link component. Either way, they would benefit from being implemented with the same interface (using the same props). In that way, it's trivial to replace a Link component with an IconLink component anywhere in the application at any time, without having to edit any additional code.

The same goes for hooks. A web application fetches data from servers. They might use local storage as well or a state management system. Those can preferably share props to make them interchangeable.

An application might fetch users, tasks, products or any other data from backend servers. Functions like that might as well share interfaces, making it easier to re-use code and tests.

The 20 Most Common Use Cases for JavaScript Arrays

Dennis Persson ・ Oct 22 '23

Interface Segregation Principle (ISP)

Another bit more clear principle, is the Interface Segregation Principle. The definition is quite short.

No code should be forced to depend on methods it does not use

As its name tells, it has to do with interfaces, basically meaning that functions and classes should only implement interfaces it explicitly use. That is easiest achieved by keeping interfaces neat and letting classes pick a few of them to implement instead of being forced to implement one big interface with several methods it doesn't care about.

For instance, a class representing a person who owns a website should be implementing two interfaces, one interface called Person describing the details about the person, and another interface for the Website with metadata about the Website it owns.

interface Person {
  firstname: string
  familyName: string
  age: number
}

interface Website {
  domain: string
  type: string
}

If one instead, would create a single interface Website, including both information about the owner and the website, that would disobey the interface segregation principle.

interface Website {
  ownerFirstname: string
  ownerFamilyName: number
  domain: string
  type: string
}

You may wonder, what is the problem with the interface above? The problem with it is that it makes the interface less usable. Think about it, what would you do if the company wasn't a human, instead a company. A company doesn't really have a family name. Would you then modify the interface to make it usable for both a human and a company? Or would you create a new interface CompanyOwnedWebsite?

You would then end up with an interface with many optional attributes, or respectively, two interfaces called PersonWebsite and CompanyWebsite. Neither of these solutions are optimal.

// Alternative 1

// This interface has the problem that it includes 
// optional attributes, even though the attributes 
// are mandatory for some consumers of the interface.
interface Website {
  companyName?: string
  ownerFirstname?: string
  ownerFamilyName?: number
  domain: string
  type: string
}

// Alternative 2

// This is the original Website interface renamed for a person.
// Which means, we had to update old code and tests and 
// potentially introduce some bugs.
interface PersonWebsite {
  ownerFirstname: string
  ownerFamilyName: number
  domain: string
  type: string
}

// This is a new interface to work for a company.
interface CompanyOwnedWebsite {
  companyName: string
  domain: string
  type: string
}

The solution which would follow the ISP, would look like this.

interface Person {
  firstname: string
  familyName: string
  age: number
}

interface Company {
  companyName: string
}

interface Website {
  domain: string
  type: string
}

With the proper interfaces above, a class representing a company website could implement the interfaces Company and Website, but would not need to consider the firstname and familyName properties from the Person interface.

Is ISP Used in React?

So, this principle obviously applies to interfaces, meaning that it should only be relevant if you are writing React code using TypeScript, shouldn't it?

Of course not! Not typing interfaces doesn't mean they aren't there. There are there all over the place, it's just that you don't type them explicitly.

In React, each component and hook has two main interfaces, it's input and its output.

// The input interface to a hook is its props.
const useMyHook = ({ prop1, prop2 }) => {

  // ...

  // The output interface of a hook is its return values.
  return { value1, value2, callback1 }
}

With TypeScript, you normally type the input interface, but the output interface is often skipped, since it is optional.

// Input interface.
interface MyHookProps { 
  prop1: string
  prop2: number
}

// Output interface.
interface MyHookOutput { 
  value1: string
  value2: number
  callback1: () => void
}

const useMyHook = ({ prop1, prop2 }: MyHookProps): MyHookOutput => {

  // ...

  return { value1, value2, callback1 }
}

If the hook wouldn't use prop2 for anything, then it should not be a part of its props. For a single prop, it would be easy to remove it from the props list and interface. But what if prop2 would be of an object type, for instance the improper Website interface example from the previous chapter?

interface Website {
  companyName?: string
  ownerFirstname?: string
  ownerFamilyName?: number
  domain: string
  type: string
}

interface MyHookProps { 
  prop1: string
  website: Website
}

const useMyCompanyWebsite = ({ prop1, website }: MyHookProps) => {

  // This hook uses domain, type and companyName,
  // but not ownerFirstname or ownerFamilyName.

  return { value1, value2, callback1 }
}

Now we have a useMyCompanyWebsite hook, which has a website prop. If parts of the Website interface is used in the hook, we cannot simple remove the whole website prop. We have to keep the website prop, and thereby also keep the interface props for ownerFirstname and ownerFamiliyName. Which also means, that this hook intended for a company could be used by a human owned website owner, even though this hook likely wouldn't work appropriately for that usage.

Why Use ISP in React?

We have now seen what ISP means, and how it applies to React, even without the usage of TypeScript. Just by looking at the trivial examples above, we have seen some of the problems with not following the ISP as well.

In more complex projects, readability is of the greatest matter. One of the purpose of the interface segregation principle is to avoid cluttering, the existence of unnecessary code which only are there to disrupt readability. And not to forget about, testability. Should you care about the test coverage of props you are not actually using?

Implementing large interfaces also forces you to make props optional. Leading to more if statements to check presences and potential misusages of functions because it appears on the interface that the function would handle such properties.

Answers to Common Next.js Questions

Dennis Persson ・ May 5 '24

#nextjs #react #webdev #javascript

Dependency Inversion Principle (DIP)

The last principle, the DIP, includes some terms which are quite misunderstood out there. The confusions are much about what the difference is between dependency inversion, dependency injection and inversion of control. So let's just declare those first.

Dependency Inversion

Dependency Inversion Principle (DIP) says that high-level modules should not import anything from low-level modules, both should depend on abstractions. What this means, is that any high level module, which naturally could be dependent on implementation details of modules it uses, shouldn't have that dependency.

The high and low-level modules, should be written in a way so they both can be used without knowing any details about the other module's internal implementation. Each module should be replaceable with an alternative implementation of it as long as the interface to it stays the same.

Inversion of Control

Inversion of Control (IoC) is a principle used to address the dependency inversion problem. It states that dependencies of a module should be provided by an external entity or framework. That way, the module itself only has to use the dependency, it never has to create the dependency or manage it in any way.

Dependency Injection

Dependency injection (DI) is one common way to implement IoC. It provides dependencies to modules by injecting them through constructors or setter methods. In that way, the module can use a dependency without being responsible of creating it, which would live up to the IoC principle. Worth to mention, is that dependency injection isn't the only way to achieve inversion of control.

Is DIP Used in React?

With the terms clarified, and knowing that the DIP principle is about dependency inversion, we can look at how that definition looks again.

High-level modules should not import anything from low-level modules.
Both should depend on abstractions

How does that apply to React? React isn't a library which normally is associated with dependency injection, so how can we then solve the problem of dependency inversion?

The most common solution to this problem spells hooks. Hooks cannot be counted as dependency injection, because they are hardcoded into components and it's not possible to replace a hook with another without changing the implementation of the component. The same hook will be there, using the same instance of the hook until a developer updates the code.

But remember, dependency injection is not the only way to achieve dependency inversion. Hooks, could be seen as an external dependency to a React component, with an interface (its props) which abstracts away the code within the hook. In that way, a hook kind of implements the principle of dependency inversion, since the component depends on an abstract interface without needing to know any details about the hook.

Another more intuitive implementations of DIP in React which actually uses dependency injection are the usage of HOCs and contexts. Look at the withAuth HOC below.

const withAuth = (Component) => {
  return (props) => {
    const { user } = useContext(AuthContext)

    if (!user) {
      return <LoginComponent>
    }

    return <Component {...props} user={user} />
  }
}

const Profile = () => { // Profile component... }

// Use the withAuth HOC to inject user to Profile component.
const ProfileWithAuth = withAuth(Profile)

The withAuth HOC shown above provides a user to the Profile component using dependency injection. The interesting thing about this example is that it not only shows one usage of dependency injection, it actually contains two dependency injections.

The injection of the user to the Profile component isn't the only injection in this example. The withAuth hook does in fact also get the user by dependency injection, through the useContext hook. Somewhere in the code, someone has declared a provider which injects the user into the context. That user instance can even be changed in runtime by updating the user in the context.

Why Use DIP in React?

Even though dependency injection isn't a pattern commonly associated with React, it is actually there with HOCs and contexts. And hooks, which has taken a lot of market share from both HOCs and contexts, does also confirm well with the dependency inversion principle.

DIP is therefore already built into the React library itself and should of course be utilized. It's both easy to use and provides advantages such as loose coupling between modules, hook and component reusability and testability. It also makes it easier to implement other design patterns such as the Single Responsibility Principle.

What I would discourage from, is trying to implement smart solutions and overusing the pattern when there really is much simpler solutions available. I have seen suggestions on the web and in books to use React contexts for the sole purpose of implementing dependency injection. Something like below.

const User = () => { 
  const { role } = useContext(RoleContext)

  return <div>{`User has role ${role}`}</div>
}

const AdminUser = ({ children }) => {
  return (
    <RoleContext.Provider value={{ role: 'admin' }}>
      {children}
    </RoleContext.Provider>
  )
}

const NormalUser = ({ children }) => {
  return (
    <RoleContext.Provider value={{ role: 'normal' }}>
      {children}
    </RoleContext.Provider>
  )
}

Although the above example does inject a role into the User component, it's purely overkill to use a context for it. React contexts should be used when appropriate, when the context itself serves a purpose. In this very case, a simple prop would have been a better solution.

const User = ({ role }) => { 
  return <div>{`User has role ${role}`}</div>
}

const AdminUser = () => <User role='admin' />

const NormalUser = () => <User role='normal' />

I'm a former teacher writing articles about software development and everything around it. My ambition is to provide people all around the world with free education and humorous reading.

Dennis PerssonFollow

Answers to Common Next.js Questions

Dennis Persson — Sun, 05 May 2024 14:25:46 +0000

Web development went from server rendered applications to single page applications rendered fully on the client, and then it all got complicated. Next.js have now cleared away the old perspective of client and servers and provided us with a high performance framework which is a big black box containing both client and server. But don't worry, I'll here provide a FAQ with common questions about Next.js and its Server Components.

At least we get to use JavaScript for the server code

How To Read URL Params in a Client Component?
How To Read URL Params in a Page File?
How To Read URL Params in a Next.js Layout File?
How To Read URL Params in a Server Component?
Why Doesn't searchParams Exist in Next.js Layout Files?
How Can I Skip the Root Layout for Some Pages in Next.js?
How To Set Metadata Tags in App Router?
How To Set Metadata Dynamically for an App Router Page?
Can I Set Metadata in a Layout File?
Can I Use Contexts with App Router?
How To Use React Context in Server Components?
Is it Possible to Render a Client Component in a Server Component?
Can I Pass Props from a Server Component to a Client Component?
Can I Use Server Components in Client Components?
Can I Pass Props from a Client Component to a Server Component?
Can I Use Server Actions in Server Components?
Can I Use Server Actions in Client Components?
Are Server Actions Stable in Next.js?

How To Make a Hero Image in Next.js 13 and 14

Dennis Persson ・ Nov 12 '23

#nextjs #react #css #webdev

1. How To Read URL Params in a Client Component?

If you need to read the pathname or query params from the URL in a Client Component, you can use the usePathname or useSearchParams to do so.

'use client'

import { usePathname, useSearchParams } from 'next/navigation'

const ClientComponent({ children, href }) {
  const pathname = usePathname()
  const searchParams = useSearchParams()
  const search = searchParams.get('search')

  return (
    <div>Next.js usePathname and useSearchParams example</div>
    <div>{pathname}</div>
    <div>{search}</div>
  )
}

export default ClientComponent

If you need to navigate programatically in a Client Component, you can use useRouter. For normal navigation, please use the built in Link component Next.js has.

'use client'

import { useRouter } from 'next/navigation'

const ClientComponent({ children }) {
  const router = useRouter()

  const handleClick = () => {
    router.push('someUrl')
  }

  return (
    <div onClick={handleClick}>Click me</div>
  )
}

export default ClientComponent

2. How To Read URL Params in a Page File?

Params are automatically passed as props to the page component. You can simply use the provided prop.

const PageComponent({ params, searchParams }) {
  const { slug } = params

  return <div>Next.js URL params in page.tsx file</div>
}

export default PageComponent

3. How To Read URL Params in a Next.js Layout File?

If you need to read URL params in a layout component file, you have two options. First option is to create a Client Component inside the layout and read the params in the Client Component instead.

This may sound like a bad option if you use Next.js with the expectations to mostly use Server Components, but it actually is completely natural. The rest of your layout file, can still be rendered as a Server Component, it's just the Client Component itself which will need to be rendered on the client.

For instance, if you would use URL params to filter articles on a blog with the help of chips components, then only the component containing the chips would need to be a Client Component, the rest of the header could remain a Server Component.

On the website above, the red rectangle can be a Server Component, while the blue rectangle which depends on URL params can be a Client Component

The other option, might be the lesser good alternative. This is to add a middleware to your application which reads the URL params and passes it on to your layout component. This will give you flexibility to access the URL params, on the cost of disabling static rendering and client-side caching of your Server Components.

The 20 Most Common Use Cases for JavaScript Arrays

Dennis Persson ・ Oct 22 '23

#javascript #webdev #programming #beginners

4. How To Read URL Params in a Server Component?

In a arbitrary Server Component, which is neither a layout component or page component, you can get the URL params by passing them down as props from other components.

Important to remember is that Server Components which aren't page file components aren't normally refreshed during navigation, the components as a whole are serialized and sent to the client and only updates in rare cases. For that reason, you must be careful when using information from the URL in Server Components. The URL params will get outdated upon navigation.

5. Why Doesn't searchParams Exist in Next.js Layout Files?

searchParams are only available in page files for a reason. Page files will always re-render when you navigate between two pages. Since the component re-renders when the URL changes, we can for sure know that the URL params passed to the component are up to date.

The purpose of layout components, is to avoid unnecessary renderings and to contain static parts of the UI which aren't updated when the user navigates between pages. A layout component does therefore only re-render when the user navigates to another part of the screen where that component isn't visible. In the code, that means to navigate between two pages which don't share a common layout file as ancestor in the file tree.

Effectively, this means that the URL will change more often than layout files renders, and if we were to read URL params in a layout component, the component wouldn't get to know when the URL params updated. Remember that the layout file is a Server Component, it is rendered to HTML when it is first fetched and then cached on client so it never has to re-render.

To learn more, read the section above about how to read URL params in a Next.js layout file.

6. How Can I Skip the Root Layout for Some Pages in Next.js?

A Next.js project can have many layout files, technically each page can have its own. The top level layout file which wraps your whole application is called Root Layout.

Layout files allow you to re-use a component as a wrapper component for several pages. Most commonly, each Next.js applications has a Root Layout file which includes the applications main menu, such as a header menu or hero image.

While doing that, you will soon run into a question; can you skip the Root Layout for specific pages? And the answer is, yes you can. Next.js has a feature called Route Groups which allows you to have multiple Root Layouts. This means that different parts of your application can have different layouts, which also makes it possible to skip having any components at all in the layout for certain pages.

One thing to note here is that navigation between route groups will trigger a full page load. That is a natural consequence of replacing the top level Server Component in the application. It basically means, you render a completely new part of your application which is independent from the rest of all pages.

Why Server Components - A Brief History of Web

Dennis Persson ・ Jul 9 '23

#react #nextjs #webdev #javascript

7. How To Set Metadata Tags in App Router?

Next.js makes it very easy for you to set metadata for your app and pages. The only thing you have to do is to export a metadata object from any layout or page file in your application to set the metadata for that layout/page and down.

import type { Metadata } from 'next'

export const metadata: Metadata = {
  title: 'Next.js Metadata Example',
  description: 'Example of metadata in Next.js',
}

export default function MyPage() { ... }

If you need dynamic data, see the question below.

8. How To Set Metadata Dynamically for an App Router Page?

For most SEO optimized applications, setting static metadata isn't enough, since data will be unique to almost every page and even be loaded at runtime from a server. To set metadata dynamically in a Next.js page, use the provided generateMetadata function.

import type { Metadata } from 'next'

export async function generateMetadata(): Promise<Metadata> {
  const data = await fetch('someUrl').then((res) => res.json())

  return {
    title: 'Next.js Dynamic Metadata Example',
    description: data.pageDescription,
  }
}

export default function MyPage() { ... }

Good to know is that the fetch function in Next.js by default caches duplicated requests. This is a general behavior, it isn't specific to metadata. Even requests in Server Components are cached when fetch is used. Although, it can be opted out from and even disabled automatically when certain Next.js features are used.

9. Can I Set Metadata in a Layout File?

Yes, you can set metadata in a layout file, both static and dynamically. Please see the questions about setting metadata above.

10. Can I Use Contexts with App Router?

It is possible to use React Contexts with the App Router in Next.js. You can preferably place the contexts in the root layout to make it available to all Client Components. The context will not be available to use in Server Components, and it will not mess up the render behavior of Server Components.

You can read about how it works in this article.

Do Contexts in Next.js 13 Make the Whole App Render on the Client?

Dennis Persson ・ Jul 30 '23

#nextjs #react #webdev #javascript

11. How To Use React Context in Server Components?

In Next.js, you can only use React contexts in Client Components. Server Components will not be affected by contexts in Client Components and it cannot read the context. See "Do Contexts in Next.js 13 Make the Whole App Render on the Client?" for more information.

However, dependent on your need, you might be fine with not having a context in your Server Component. By default, Next.js caches data retrieved in requests sent with the fetch function, meaning that you don't have to worry about duplicated request. If multiple Server Components need to fetch the same data, you can rely on the cache as an alternative to a sharing data through a context.

12. Is it Possible to Render a Client Component in a Server Component?

It's completely normal to render Client Components in Server Components. All props which are passed to the Client Component must be serializable though. Data which isn't serializable must be handled from within the Client Component instead.

13. Can I Pass Props from a Server Component to a Client Component?

Yes it is possible to pass props from a Server Component to a Client Component. As mentioned in the previous question, the data must be serializable.

14. Can I Use Server Components in Client Components?

It is possible to user Server Components in a Client Component, but with limitations. You cannot import Server Components in Client Components as usual, they will not be Server Components when doing so. What you will have to do, is to pass the Server Component as a prop or child to the Client Component.

Note specifically, because this tricks many developers. Next.js claim that components are Server Components by default, and that you have to use the "use client" directive to make it a Client Component. That is not the whole truth, because when you import any component in a Client Component, the imported component will be a Client Component, not a Server Component.

As mentioned above, you have to pass the Server Component as a prop if it should be treated as a Server Component. Next.js don't complain if you import what you think are Server Components into Client Components, they are simply just treated as Client Components without any warnings. So if you think you are using a lot of Server Components, you may actually not have that many at all.

How To Use MVVM in React Using Hooks and TypeScript

Dennis Persson ・ Apr 16 '23

I'm a former teacher writing articles about software development and everything around it. My ambition is to provide people all around the world with free education and humorous reading.

15. Can I Pass Props from a Client Component to a Server Component?

No, it isn't possible to pass props from a Client Component to a Server Component. Server Components are rendered into HTML on server already before Client Components are rendered.

16. Can I Use Server Actions in Server Components?

Yes of course, they are made for that. See this example in the docs.

17. Can I Use Server Actions in Client Components?

Yes, but with a caveat. You cannot use server actions directly in your Client Component. What you can do, is can write the server action in a separate file, and use it in a Client Component, like shown in the docs.

However, if you try to use server actions directly in a component like it is done in a Server Component, then you would get this error.

It is not allowed to define inline "use server" annotated Server Actions in Client Components. │ To use Server Actions in a Client Component, you can either export them from a separate file with "use server" at the top, or pass them down through props from a Server Component.

As you can read there, you have one more option. You can define the server action in a Server Component and pass it as a prop to the Client Component if you would want that.

18. Are Server Actions Stable in Next.js?

In Next.js 14 server actions are considered stable. One thing to note though, Next.js is built upon React features which are still marked as experimental.

Server actions were experimental back in Next.js 13, so if in version 13, you will be asked to add server actions as an experimental feature in next.config.js

to use server actions, please enable the feature flag in your next.js config.

This is what you would need to add to next.config.js. Although I rather recommend to upgrade to Next.js 14.

experimental: {
  serverActions: true,
},

Dennis PerssonFollow

33 Christmas Animations to Easily Add to Your Website

Dennis Persson — Sun, 10 Dec 2023 15:11:37 +0000

Yes, it's already that time of year. Whether you love or hate Christmas, a small Christmas CSS animation can bring a big smile to your website visitors.

In this list, you will find 33 Christmas animation and interactive art which easily can be added you your website. Most of them are CSS only, others requires a small amount of JavaScript.

CSS Snowflakes!

Let's start out with snowflakes. Decorate your webpage with animated snowflakes. Easy to add, delightful to look at.

Snow Globes

Can you make a snow globe with pure CSS? Yes, here we have three stunning snow globes made with only CSS.

CSS Santa Claus

What would Christmas be without Santa Claus himself? The tricky thing is too choose which CSS Santa to go for!

If We Only Had Five VS Code Extensions

Dennis Persson ・ May 28 '23

#webdev #productivity #programming #discuss

Christmas Decorations in CSS

Why not adding some small decorative Christmas inspired CSS art? My favorite is definitely the Disney-like Christmas tree, which reasonably requires a good amount of JavaScript. If you don't want to use JavaScript, you have a quite similar mesmerizing CSS only Christmas tree animation in another link.

Interactive Christmas Animations

Here are some interactive Christmas animation. They naturally include a bit of JavaScript since they are interactive, but some manage to get away very easily with almost no JavaScript at all.

CSS Candy Canes

Wanting something sweet for Christmas? Try these CSS loading and progress bars in candy cane colors!

CSS Snowman

Do you know why it is better to add a snowman to your website than building one outside? Because it never melts. Unless your servers overheats...

List of Free Image Tools Every Frontend Developer Needs

Dennis Persson ・ Jul 31 '22

#webdev #ux #css #productivity

Other Christmas Art

Couldn't decide what CSS art to use to decorate your website with for Christmas? Here's a few more links which may come handy.

Bonus - Christmas Games

It's Christmas after all, you should get some extra gifts. For you today, I have found two Christmas games you can play!

Dennis PerssonFollow

I'm a former teacher writing articles about software development and everything around it. My ambition is to provide people all around the world with free education and humorous reading.

React Hook: useElementDimensions

Dennis Persson — Sun, 03 Dec 2023 15:14:20 +0000

CSS is great, but sometimes it is not enough. Sometimes you need to know the size of CSS elements in the JavaScript code, or to know where it is on the screen. In that case the useElementDimensions is perfect hook to use. This article describes what the hook is, how to implement it and shows some use cases of it.

Actually, we will look at two hooks in this article, both useStaticElementDimensions and useElementDimensions. We will start with the static hook, which has limited use cases but serves as a good example of why we need the more advanced hook.

useStaticElementDimensions Hook

Below you can see a JavaScript implementation of a useStaticElementDimensions hook. The hook is also available to test at CodeSandbox. The example on CodeSandbox is written in TypeScript, so if you're using it in a TypeScript project you should head over there, or get it from GitHub.

import { useCallback, useState } from 'react'

const useStaticElementDimensions = () => {
  const [dimensions, setDimensions] = useState(null)

  const ref = useCallback((node) => {
    if (!!node) {
      const domRect = node.getBoundingClientRect()
      setDimensions(domRectToDimensions(domRect))
    }
  }, [])

  return { dimensions, ref }
}

export default useStaticElementDimensions

The hooks is simple to use, but not straight forward to understand. So we will go through it in detail.

The hooks takes no arguments, but it returns an object with two properties. One of the return values is a reference ref, which we will pass to the DOM node we want to measure the size and position of. When doing that, the dimensions object returned from the hook will contain the bounding client rect which has the following attributes in its type definition:

height: number;
width: number;
x: number;
y: number;
bottom: number;
left: number;
right: number;
top: number;

This means that we with this hook will be able to detect where on the screen the node is, and also its width and height. So usage of the hook would look something like this.

const SomeComponent = () => {
  const { dimensions, ref } = useStaticElementDimensions()
  const { height, width, x, y } = dimensions ?? {}

  return <SomeNode ref={ref}>Example</SomeNode>
}

React Anti-Patterns and Best Practices - Do's and Don'ts

Dennis Persson ・ Feb 5 '23

#webdev #productivity #programming #discuss

At this point, you may wonder, why did the hook return a useCallback function as ref when it could have used a useRef reference instead? The answer is about update frequency.

This useStaticElementDimensions hook is based on callback refs, more specifically at the old React docs of how to measure DOM nodes. As you can read there, the regular ref retrieved from useRef function doesn’t notify about changes to the ref value, meaning we will only be informed about what value the node has when the component containing the referenced node mounts.

If the referenced node would be added later, using either conditional rendering or if a component is lazy loaded, the regular useRef reference wouldn't let us know that the node value has changed.

By using a callbackRef function rather than a normal ref, the reference will instead be bound to the actual node's mount and umount events. So, with the useCallback Ref, the hook does its job, but there's a bunch of use cases which isn't handled, which is probably why the example isn't included in the React docs anymore.

Don't worry Napoleon, we have another hook

useElementDimensions Hook

So, now we have seen a hook which we could use to check the measurements of a DOM node with JavaScript. The hook does work, but it has some flaws.

First of all, it only measures the dimensions of the node when the node mounts, meaning it will not update when the element or viewport is updated. It's just a snapshot of the element, which can be used for static components which aren't dynamically rendered, thereby the name useStaticElementDimensions.

Websites are rarely static though. Sizes of DOM elements are often preserved, but positions are definitely not static. When the user scrolls on the page, or resizes the browser window, the position of the elements changes, and the static hook above doesn't consider that.

This is why we need a more sophisticated hook for this job, the useElementDimensions hook. The useElementDimensions hook works with browser scroll and resize events, and it also handles a special case where we manually need to refresh the dimensions.

You can see the updated hook below. Once again, a TypeScript version of the hook is available on GitHub and CodeSandbox.

import useEventListener from 'hooks/useEventListener'
import { useCallback, useRef, useState } from 'react'

const useElementDimensions = () => {
  const ref = useRef(null)
  const [dimensions, setDimensions] = useState(null)

  const refresh = useCallback(() => {
    const domRect = ref.current?.getBoundingClientRect()

    if (domRect) {
      setDimensions(domRect)
    }
  }, [])

  useEventListener('resize', refresh);
  useEventListener('scroll', refresh, true);

  return { dimensions, ref, refresh }
}

export default useElementDimensions

The imported useEventListener looks like this.

import { useEffect } from 'react'

const useEventListener = (event, listener, useCapture) => {
  useEffect(() => {
    if (listener) {
      listener()
      window.addEventListener(event, listener, useCapture)

      return () => window.removeEventListener(event, listener, useCapture)
    }

    return () => {}
  }, [event, listener, useCapture])
}

As you can see, this hook is more advanced. The helper hook, useEventListener, should be easy to understand. It's a wrapper around a useEffect which subscribes and unsubscribes to events. In this case, the useElementDimensionsHook listens on the 'resize' and 'scroll' events specifically.

useEventListener('resize', refresh);
useEventListener('scroll', refresh, true);

If We Only Had Five VS Code Extensions

Dennis Persson ・ May 28 '23

You may also notice, that in this hook, we have ditched the callback ref and are now using a regular useRef reference. The useEventListener does invoke the listener when the effect runs, which means that the refresh function in the useElementDimensions hook will update the dimensions according to the current value of the node ref. That will re-trigger every time the component mounts, so there is no need for a callback ref.

The dimensions, are still stored in a useState though. This is because useRef values doesn't trigger components to re-render. So if we wouldn't use useState, the components using this hook wouldn't be notified about the change.

The useState, together with the resize and scroll listener hook useEventListener and the refresh function it triggers, is enough to keep the dimension return value up to date in most use cases. The user can resize the browser and scroll however it wants, and the hook will always provide the latest size and position of the node.

However, as I mentioned before, there are some special cases to handle, and that's why the hook exposes the refresh function as a return value. For example, if the dimensions returned from the function would be used to move or resize the node it references, the dimensions would become outdated. And since neither a scroll event or browser resize has occurred, the dimensions won't be updated.

If you find cases like that you can use the refresh function to manually update the dimensions. Although, more likely, you are doing some shady things and should watch out for infinite loops and nasty bugs. So in reality, you may be more safe by keeping the refresh function internal to the hook.

How To Use MVVM in React Using Hooks and TypeScript

Dennis Persson ・ Apr 16 '23

#webdev #ux #css #productivity

Cautions and Improvements

As just mentioned, you should be careful to use the refresh function manually outside the hook. You may end up in too many rerenders or strange behaviors. Only use the exposed refresh function if you know why you are doing so.

Furthermore, you should now about the implications of using the useElementDimensions hook. Listening on scroll positions is a slow operation. Generally, it is better to use the Intersection Observer API to check if nodes are visible on screen and for similar use cases, whenever it is possible.

Additionally, you may want to add a throttle or debounce to the useElementDimensions hook. Or, if you have a quite limited use case for that hook, you may instead use the callback ref based hook useStaticElementDimensions. But remember, building responsive applications has been cool for a long time now.

I can tell you, John did update all his sites to be responsive that night

Use Cases

In most cases, you would probably want to use the useElementDimensions hook. If you can be sure you won't need it, you have an option to use the less advanced useStaticElementDimensions hook.

Either way, here are a few use cases of when a hook like this may be needed.

To ensure a menu or dropdown doesn't end up outside the viewport
To implement infinite scroll solutions
For dynamic components

1. To Ensure a Menu or Dropdown Doesn't End Up Outside the Viewport

Menus such as dropdown menus and context menus are often rendered at the place the trigger button is placed. On many sites, the main menu is a hamburger menu in the top right corner of the site. Since these menus are fairly large, and often absolutely positioned, they can easily end up going out of the screen.

The same problem often occurs with dropdown menus or context menus on other places on the screen. For instance, when a dropdown menu is scrolled to be positioned at the bottom of the screen when it is being opened. In that case, the dropdown may drop out of screen and may need to open upwards instead, or at least being lift up so all of it is visible.

In these cases, a hook like useElementDimensions may be useful. A node's size and position can be compared to the window's innerWidth and innerHeight to determine if an element is inside or outside the viewport.

2. To Implement Infinite Scroll Solutions

Some more complex usage of this hook can be when a list is rendered. You are potentially implementing a infinite scroll component, which needs to recycle the list items to avoid loading too many DOM nodes into the DOM tree.

Such solutions can often involve calculating how many items which will fit within the list. This is an easy task if all elements are of the same height. That best case scenario is not always possible. Sometimes the height of elements will vary, and you may need to detect the size of the elements. That's another scenario when this hook could become useful.

3. For Dynamic Components

Components are not always static. You may render components dynamically, or even lazy load them. Or they may exist in you code but being opened with code. The useElementDimensions hook can in that case help you measuring the height and width of those components.

List of Free Image Tools Every Frontend Developer Needs

Dennis Persson ・ Jul 31 '22

Example Usage

When this hook is used, it will generally look something like this.

import useElementDimensions from "hooks/useElementDimensions";

const DynamicComponent = () => {
  const { dimensions, ref } = useElementDimensions();
  const { height, width, x, y } = dimensions ?? {};

  return (
    <>
      <div ref={ref}>Some element</div>
      <p>Height: {height}</p>
      <p>Width: {width}</p>
      <p>X: {x}</p>
      <p>Y: {y}</p>
    </>
  );
};

You can pass the ref to any DOM node. This also works for TypeScript, since the hooks uses generic types in the examples on GitHub and CodeSandbox.

Summary

useElementDimensions is a hook you can use for at least three use cases.

To ensure a menu or dropdown doesn't end up outside the viewport
To implement infinite scroll solutions
For dynamic components

The hook updates the ref upon scroll and window resize events. However, listening to such events is an expensive operation. You may want to use a throttle or a debounce, or maybe use the static variant of the hook, useStaticElementDimensions, which is based on callback refs, but isn't updated when the use scrolls or the browser window change size.

Dennis PerssonFollow

I'm a former teacher writing articles about software development and everything around it. My ambition is to provide people all around the world with free education and humorous reading.

How To Make a Hero Image in Next.js 13 and 14

Dennis Persson — Sun, 12 Nov 2023 15:48:29 +0000

I have noticed that one of my previously very popular article about how to make a hero image in Next.js is still getting a lot of attention.

Unfortunately, that article was written when Next.js still used the Page Router. After that, with their new App Router in Next.js 13, the image component was replaced with a new one. With that in mind, I have now created a new article optimized for the new Image component in Next.js 13 and 14, for all of you who have, or want to, migrate to use the Image component.

Next.js 13+ Image Component

The new image component which you can use in Next.js 13 and 14 has changed slightly from the legacy image component used in earlier versions. Both the legacy and the new one offer similar advantages, which makes it very beneficial to use instead of the regular image HTML element. Both of the components can help you with:

Resizing images for you so you don't need to use srcset manually
Automatically lazy loads images when they are scrolled into view, which of course is optional
Gives you various optimization option, such as quality, priority and custom image sizes
Supports adding a placeholder to blur images when they are loading

For the blurring, you can check my old article if you wonder more about how it works.

I bat Batman would make a great hero image

Changes in Next.js 13+ Image Component

Next.js offers a migration codemod scripts for migrating to the new image components. The codemods are not bullet-proof, so you should check what has changed in the new image component if you are planning to migrate.

Some of the changes have affected how a hero image can be implemented. Mainly, they have replaced layout property, removed the objectFit prop and removed the absolute positioned span element which was wrapping the img element in the legacy image component.

How To Create a Hero Image With Next.js 13+

The principe of how to implement a hero image is quite simple with the new Image component. I would recommend the following setup.

Start with a wrapper div with relative position, 100vw width and your desired height
Insert the Next.js image component with fill and priority props set to true, and a class style with a z-index of -1
Place whatever content you want after the image wrapper, but within the outer wrapper div

Note: You can optionally wrap the image in a wrapper div if you cannot set a style directly on your image component for some reason. In that case, the wrapper must set the CSS attribute position to "absolute" value.

Following the steps above would give you a component looking something like below. The implementation is using css modules. You can also find the code at CodeSandbox and GitHub.

// HeroImage.jsx

import Image from "next/image";
import styles from "./heroImage.module.css";

const { heroContent, heroImage, heroWrapper } = styles;

const IMAGE_URL = "https://www.perssondennis.com/images/perfect-avocado.webp";

const HeroImage = () => {
  return (
    <div className={heroWrapper}>
      <Image
        className={heroImage}
        priority
        src={IMAGE_URL}
        fill
        alt="hero image example"
      />

      <div className={heroContent}>
        <h1>Hero Image</h1>
        <p>Next.js 13 hero image example.</p>
      </div>
    </div>
  );
};

export default HeroImage;

// heroImage.module.css

.heroWrapper {
  position: relative;
  width: 100vw;
  height: 50vh;
}

.heroImage {
  object-fit: cover;
  object-position: center;
  z-index: -1;
}

.heroContent {
  display: flex;
  flex-direction: column;
  align-items: center;
}

Note that I did also set the objectFit property to "cover". You decide how you want you image to scale by choosing a suitable value for objectFit attribute.

contain value for objectFit will keep the aspect ratio, which may not be desired for a hero image
the cover value will fill up the available area in the parent element by cropping the image where it is necessary
fill option will stretch the image to fill up the parent element

When you crop the image by using "cover" as a value, you may want to set objectPosition to make sure you keep the parts of the image you want from being cropped out.

Above example could look something like this

Solution Explained

CSS is not always that intuitive, so I'll go through what we did there.

The wrapper div around everything had a relative position, what that does, is to tell that absolute positioned images within that element should be positioned relative to it. Absolute positioned elements are relative to the first parent which is explicitly positioned.

The image component Next.js provides does use an absolute position when we use the fill prop for the image component, so the relative position of the wrapper ensures that the image will grow to fill the wrapper and not the whole viewport.

We also added a negative z-index to the image. That is to ensure that the image will be placed under any other content rendered on the same area as the hero image, which means, all the other content we want to display on top of the hero image.

To the image component, we did pass a priority property. This is to disable lazy loading for hero image, since a hero image should always load as quick as possible.

Rest of code should be self explanatory. If it isn't, let me know about your questions.

React Anti-Patterns and Best Practices - Do's and Don'ts

Dennis Persson ・ Feb 5 '23

Choosing a Hero Image

If you don't have a hero image and don't want to buy one, there's a lot of free ways to get them. You can find links to some royalty free image sources in my list of useful image tools.

That article also lists a lot of useful resources to edit images, both an online Photoshop application and tools for editing, generating and converting images to other format.

Speaking of generating an image. You are probably aware of AIs which can generate images for you. While DALL-E may be the most known one, I prefer Leonardo.Ai du to its high quality and realistic images which suits very well for hero images.

Whatever image you choose, make sure to reduce the size of it to a couple of 100 kB or preferably less, dependent on how high resolution and what detail level you need for your image. You can read about the impact of image size and how to optimize an image in my article about how I improved Lighthouse Performance by adding a hero image.

How To Use MVVM in React Using Hooks and TypeScript

Dennis Persson ・ Apr 16 '23

I'm a former teacher writing articles about software development and everything around it. My ambition is to provide people all around the world with free education and humorous reading.

Summary

Next.js 13 comes with a new image component which is fairly similar to the old one
Just as the old image component, it offers image optimizations, lazy loading and blurred placeholders
The new image component can easily be used as a hero image, but remember to use relative position for the parent element
Use z-index to control that the hero image stays below other content in the hero area

Dennis PerssonFollow

The 20 Most Common Use Cases for JavaScript Arrays

Dennis Persson — Sun, 22 Oct 2023 14:07:28 +0000

Splice, slice, pop and shift. Is the array sort method stable and not in-place? It's not easy to remember all JavaScript array methods and what the difference between them are. They are all synonyms, as if they where taken directly from a thesaurus.

This array cheat sheet lists all the array methods you usually need in JavaScript, and the ones you don't need, is not here. Simple as that! To make it even easier for you, I have based the cheat sheet on common use cases.

New challenge, try to list all array methods without forgetting one of them

Immutability

Before we begin, a notice about immutability. All functions used in this article are immutable, which shortly means, that you never mutate your original array when you use these methods. Immutability is very important in modern JavaScript, at least according to this Stack Overflow guy (and the rest of the Internet).

Even though each of these methods is immutable on their own, you are not totally safe against immutability. If you include mutable data types (arrays, objects, functions) in your immutable arrays, you can still mutate the mutable data within the array. We call such arrays to be shallowly immutable, in contrast to deeply immutable arrays which only includes immutable items.

#performance #testing #discuss

Array Use Cases

Add Element to Start of Array
Add Element to End of Array
Remove an Element From Start of Array
Remove an Element From End of Array
Insert Element at Index in Array
Replace an Element at Index in Array
Remove an Element at Index in Array
Remove an Element By Value From an Array
Remove Objects By Property From an Array
Check if Array Includes an Element
Check if Array Includes Object with Property
Check if All Objects in an Array has a Property
Convert Array to an Object
Convert Array of Objects to an Object
Convert Object to an Array
Combine Two Arrays
Sort an Array
Sort an Array of Objects
Reverse an Array
Remove Duplicates From an Array

6 Use Cases for Regex in Your Daily Work

Dennis Persson ・ Nov 27 '22

1. Add Element to Start of Array

To prepend an item to the beginning of an array, use array spreading.

const arr = [1, 2, 3];
const result = [0, ...arr];
console.log(result);
// [0, 1, 2, 3]

Do not use the unshift method, that will mutate the original array.

2. Add Element to End of Array

To append an item to the end of an array, use array spreading.

const arr = [1, 2, 3];
const result = [...arr, 4];
console.log(result);
// [1, 2, 3, 4]

Do not use the push method, that will mutate the original array.

3. Remove an Element From Start of Array

To remove the first item in an array, use slice method.

const arr = [1, 2, 3];
// Keep index 1 and everything after that.
const result = arr.slice(1);
console.log(result);
// [2, 3]

Do not use the shift or splice methods, they will mutate the original array.

4. Remove an Element From End of Array

To remove the last item in an array, use slice method.

const arr = [1, 2, 3];
// Keep index 0 and everything after that, except one element at the array.
const result = arr.slice(0, -1);
console.log(result);
// [1, 2]

Do not use the pop or splice methods, they will mutate the original array.

React Anti-Patterns and Best Practices - Do's and Don'ts

Dennis Persson ・ Feb 5 '23

#webdev #ux #css #productivity

5. Insert Element at Index in Array

To add an item at a specific index of an array, use the toSpliced method.

const arr = [1, 2, 3];
// Keep index 1, delete 0 elements, add the element "one point five" and keep everything after that.
const result = arr.toSpliced(1, 0, "one point five");
console.log(result);
// [1, "one point five", 2, 3]

Do not use the splice method, that will mutate the original array.

6. Replace an Element at Index in Array

To replace an item from some index in an array, use the toSpliced or with method.

const arr = [1, 2, 3];

// Using toSpliced.
// Keep index 1, delete 1 elements, add the element "two" and keep everything after that.
const result1 = arr.toSpliced(1, 1, "two");
console.log(result1);
// [1, "two", 3]

// Using with.
// Copy the old array arr with index 1 replaced with "two".
const result2 = arr.with(1, "two");
console.log(result2);
// [1, "two", 3]

Do not use the splice method, that will mutate the original array.

7. Remove an Element at Index in Array

To remove an item from an array, use the toSpliced method.

const arr = [1, 2, 3];

// At index 1, delete 1 elements.
const result = arr.toSpliced(1, 1);
console.log(result);
// [1, 3]

Do not use the splice method, that will mutate the original array.

8. Remove an Element By Value From an Array

To remove a specific value from an array, use the filter method.

const arr = [1, 2, 3];
const result = arr.filter((element) => element !== 2);
console.log(result);
// [1, 3]

Do not use the indexOf together with splice method, that will mutate the original array.

9. Remove Objects By Property From an Array

To remove an object with a specific attribute from an array, use the filter method.

const arr = [{ num: 1 }, { num: 2 }, { num: 3 }];
const result = arr.filter((obj) => obj.num !== 2);
console.log(result);
// [{ num: 1 }, { num: 3 }]

Do not use the findIndex together with splice method, that will mutate the original array.

List of Free Image Tools Every Frontend Developer Needs

Dennis Persson ・ Jul 31 '22

10. Check if Array Includes an Element

To check if an array contains a value, use includes method.

const arr = [1, 2, 3];
const result = arr.includes(2);
console.log(result);
// true

11. Check if Array Includes Object with Property

To check if an array contains an object with a property, use some method.

const arr = [{ num: 1 }, { num: 2 }, { num: 3 }];
const result = arr.some((obj) => obj.num === 2);
console.log(result);
// true

12. Check if All Objects in an Array has a Property

To check if every object in an array has a property, use every method.

const arr1 = [{ num: 1 }, { num: 2 }, { num: 3 }];
const result1 = arr1.every((obj) => obj.num === 2);
console.log(result1);
// false

const arr2 = [{ num: 2 }, { num: 2 }, { num: 2 }];
const result2 = arr2.every((obj) => obj.num === 2);
console.log(result2);
// true

13. Convert Array to an Object

To convert an array to a custom object, use reduce method.

// A function which maps a key to a value.
const arr1 = [1, 2, 3];
const result1 = arr1.reduce((acc, cur, index) => {
  acc[`attr${index}`] = cur;
  return acc;
}, {});
console.log(result1);
// { attr0: 1, attr1: 2, attr2: 3 }

// A function which count occurrences could look like this.
const arr2 = ["a", "b", "c", "c"];
const result2 = arr2.reduce((acc, cur) => {
  if (acc[cur]) {
    acc[cur] += 1;
  } else {
    acc[cur] = 1;
  }
  return acc;
}, {});
console.log(result2);
// { a: 1, b: 1, c: 2 })

// A function which maps elements in array to boolean values can look like this.
// I.e. convert array to object keys.
const arr3 = ["a", "b", "c"];
const truthValues = ["b", "c"];
const result3 = arr3.reduce((acc, cur) => {
  acc[cur] = truthValues.includes(cur);
  return acc;
}, {});
console.log(result3);
// { a: false, b: true, c: true })

14. Convert Array of Objects to an Object

To convert an array of objects to an object, use Object.assign method and array spread syntax.

const arr = [{ attr1: 1 }, { attr2: 2 }, { attr3: 3 }];
const result = Object.assign({}, ...arr);
console.log(result);
// { attr1: 1, attr2: 2, attr3: 3 }

15. Convert Object to an Array

To create an array from an object, use Object.keys, Object.values, or Object.entries, potentially together with a map method.

const obj = { a: 1, b: 2, c: 3 };

// Array of keys.
const result1 = Object.keys(obj);
console.log(result1);
// ["a", "b", "c"]

// Array of values.
const result2 = Object.values(obj);
console.log(result2);
// [1, 2, 3]

// Array of key-value objects.
const result3 = Object.entries(obj).map(([key, value]) => ({ key, value }));
console.log(result3);
// [{ key: "a", value: 1 }, { key: "b", value: 2 }, { key: "c", value: 3 }]

In some cases, it is useful to chain some map and filter methods to modify and filter out values.

const obj = { a: 1, b: 2, c: 3 };

// Array of squared values greater than 3.
const result1 = Object.values(obj)
  .map((value) => value * value)
  .filter((value) => value > 3);
console.log(result1);
// [4, 9]

// Array of key-value objects which has a value greater than 1.
const result2 = Object.entries(obj)
  .map(([key, value]) => ({ key, value }))
  .filter((keyValueObj) => keyValueObj.value > 1);
console.log(result2);
// [{ key: "b", value: 2 }, { key: "c", value: 3 }]

How To Use MVVM in React Using Hooks and TypeScript

Dennis Persson ・ Apr 16 '23

16. Combine Two Arrays

To combine two JavaScript arrays, use concat method or the spread syntax for arrays.

const arr1 = [1, 2, 3];
const arr2 = [4, 5, 6];

// Concat method is faster.
const combinedArray1 = arr1.concat(arr2);
console.log(combinedArray1);
// [1, 2, 3, 4, 5, 6]

// Spread syntax may be more readable.
const combinedArray2 = [...arr1, ...arr2];
console.log(combinedArray2);
// [1, 2, 3, 4, 5, 6]

Do not use the push method, that will mutate the original array.

17. Sort an Array

If you want to sort an array by value, use toStorted method.

The toStorted method is stable, meaning that it keeps the order of elements which are equal to each other intact. The method is not in-place, which usually is a good thing, since it means that it won't mutate the existing array.

// To sort strings.
let arr1 = ["b", "c", "a"];
const result1 = arr1.toSorted();
console.log(result1);
// ["a", "b", "c"]

// Note: Numbers are sorted by their toString value,
// not by their numerical value!
const arr2 = [10, 1, 5];
const result2 = arr2.toSorted();
console.log(result2);
// [1, 10, 5]

// To sort numbers, use a comparator.
const arr3 = [10, 1, 5];
const result3 = arr3.toSorted((a, b) => a - b);
console.log(result3);
// [1, 5, 10]

Do not use the sort method, that will mutate the original array since it does in-place sorting.

18. Sort an Array of Objects

To sort an array by value, use toStorted method with a comparator. A comparator is a function which determines which of two values that should be sorted first.

const arr = [{ num: 3 }, { num: 1 }, { num: 2 }];

// ObjA will be sorted before objB if comparator returns a positive value.
const byNumberAttribute = (objA, objB) => objA.num - objB.num;
const result1 = arr.toSorted(byNumberAttribute);
console.log(result1);
// [{ num: 1 }, { num: 2 }, { num: 3 }]

// More generic comparator.
const byAttribute = (attr) => (objA, objB) => objA[attr] - objB[attr];
const result2 = arr.toSorted(byAttribute("num"));
console.log(result2);
// [{ num: 1 }, { num: 2 }, { num: 3 }]

// Note. The comparator function must return an integer value.
// If you need to sort other data types, return 1, 0 or -1.
const arr3 = [{ letter: "c" }, { letter: "a" }, { letter: "b" }];
const alphabetically = (objA, objB) => {
  if (objA.letter < objB.letter) {
    return -1;
  }

  if (objA.letter > objB.letter) {
    return 1;
  }

  // objA === objB
  return 0;
};
const result3 = arr3.toSorted(alphabetically);
console.log(result3);
// [{ letter: 'a' }, { letter: 'b' }, { letter: 'c' }]

Do not use the sort method, that will mutate the original array.

19. Reverse an Array

To reverse all values in an array, use toReversed method.

const arr = [1, 2, 3];
const result = arr.toReversed(2);
console.log(result);
// [3, 2, 1]

20. Remove Duplicates From an Array

To remove duplicated elements in an array, use filter method or a set.

const arr = [1, 2, 3, 2, 1];

// Using filter method.
const result1 = arr.filter((item, index) => arr.indexOf(item) === index);
console.log(result1);
// [1, 2, 3]

// Using a set.
const result2 = [...new Set(arr)];
console.log(result2);
// [1, 2, 3]

I'm a former teacher writing articles about software development and everything around it. My ambition is to provide people all around the world with free education and humorous reading.

Dennis PerssonFollow

The Art of Code Review and Why You Need It

Dennis Persson — Sun, 01 Oct 2023 14:37:58 +0000

Code reviewing is an art. Although most companies conduct code reviews, only a few of them fully harness the potential benefits that code reviews offer. In this article, we will look at what you and your team can do to fully leverage the potential they offer.

Code Review Is a Team Activity

First rule of code reviewing, code reviewing concerns the whole team. Every person is different, developers have different opinions about code and also different expectations of a code review. Critiques are also received differently from person to person, some are more sensitive than others.

To make sure the whole team agrees to how the code reviews should be handled, you can do one of two things. Either have a meeting about it to talk about expectations, or, make it less formal and start a discussion with the team when you do your first code review. If you bring it up when you present your first code review, you can be quite strict with your comments and still appear as a caring person.

When you discuss the code reviews, try to settle what you think is important. Should the code review be about finding bugs, or should you comment with improvements and opinions? If you encourage opinions, should those be mandatory to fix or can they be ignored?

Discuss and come up with an agreement every developers agrees with, but try to avoid creating explicit checklists of what to check. Using checklists, can easily turn into developers checking off each item an then thinking they are done with the code review, without really reflecting over the solution at all.

If We Only Had Five VS Code Extensions

Dennis Persson ・ May 28 '23

#webdev #productivity #programming #discuss

Why To Do Code Reviews?

From a manager's perspective, code reviews are often all about finding bugs and assure that the committed code won't hit back when testers test it. For me, as a developer, the main goal of a code review isn't to stop bugs, it's to involve more persons in the solution and to initiate discussions for alternative solutions and knowledge sharing. In the long term, that's what really going to improve the product quality and make developers write less error-prune code.

If you do code reviews correctly, they can help your team in many areas. These are just some of the benefits a code review can help you with.

Reflecting over your code before you commit
Learn and reflect about other developer's code and opinions
Teaching and helping other developers
Align the teams view on the product and its code and newly added code
Getting better knowledge of the full code base
Stop bugs from coming through
Improve the quality of the code
Improve the quality of tests
Reduced technical debt
Enhanced documentation with cleaner commits and better comments
Identify security issues
Save time by fixing issues during the code review instead of two weeks after
Building a team

The last point in the list is what many people forget, but still one of the most important points. A good team communication is essential for all kind of business and development. Code reviews are an excellent way to let the team grow together because it is likely to cause conflicts, and anyone who knows anything about team building or conflict management knows that conflicts are necessary for a team to excel.

Tea drinkers would think it's a compliment

Why You Should Not Do Code Reviews

There aren't very many reasons for not doing code reviews honestly. It does takes time, yes, but that time you will definitely get back in the long term with all the benefits it comes with.

Think about it a bit. If you founded a tech company and hired developers. Would you like anyone to push any code without a single person looking at what they pushed? Would you rely on an open source project where anyone could contribute but no one was reviewing what was committed?

If your answer to any of those questions is no, or if you want to build a better team and improve code quality, then code reviews are for you.

Complete Guide To Make You a Regex Guru

Dennis Persson ・ Jan 15 '23

#webdev #productivity #regex #programming

What To Do Before a Code Review

A code review doesn't start with a pull request, there are certain things needed to be done before that, both as the developer who commits the code and for the person who is going to review it.

As a Coder

In a divergent team, there's always that architect guy who checks whole teams code, but also several more fast-paced developers who never really look twice at code and blindly push their code using their two characters alias for "git add . && git commit -m "save" && git push".

When submitting code for a code review (or even without a code review), those hasty developers should try to be a bit more like the architect guy. Some things that always should be done before committing code are:

Keep the commit small, only a single story/task should be implemented in the commit. In that way, it's easier to review and also easier for teammates to track why a change was made when in doubt.
Don't include code unrelated to the task you are working on in your commit. If you have fixed stuff unrelated to your task, commit it in another commit before or after the task.
Does your commit include temporary code? Try to fix it before committing. If not possible, mark it with a TODO comment and plan when to follow it up.
Does your commit include a complex solution? Write comments for the parts which needs it.
Look through your code before pushing. Even if you have followed all the previous steps above without missing anything, you might find improvements for you code or other ways to implement the solution.
Test your code manually. And if you haven't written any test, write those.

First when all above has been done, you are ready to commit your code and ask for a code review. When that is done, it's time for another coffee!

You know, I've seen better developers. On their first cup...

As a Reviewer

The main work of a code review as a reviewer is obviously to review the code, but before doing that, make sure to do a few things.

Firstly, make sure that the developer is done with the development and that all tests for it have been written. Don't review partly finished work unless it isn't to help out with another pair of eyes. Partly finished code is likely to change, especially if tests haven't been written and bugs may be found.

Secondly, talk to the developer who developed the feature to understand what the commit is about. Preferably with the pull request and feature in front of you. Doing this will make it easier to understand the code and the developer's reasoning.

Lastly, you can think about how you would implement the feature before looking at the pull request. This is a great practice to practice problem solving, since you will both come up with a solution on your own and potentially see an alternative solution for the same problem. If you are lucky, you the developer of the pull request implemented the feature in another way, which will make the code review much more interesting.

Why You Should Not Be a Reactive Developer

Dennis Persson ・ Oct 9 '22

#webdev #programming #productivity #beginners

What To Do During a Code Review

When a pull request has been made, it's time to review it. This work lies mainly on the reviewer, but even the code contributor has a few things to think about.

As a Coder

As the developer of the pull request, you can often just sit and relax while the reviewer tears its hair. To make the life easier for the reviewer, make sure to be available for questions. If the reviewer and you don't know each other very well, make sure to mention you are available for questions, so that person dares to ask.

As a Reviewer

Reviewing large pull requests takes time. As a reviewer it is important to remember it is worth the time without stressing it, take a minute to look back at the section about why to do code reviews in the beginning of this article. Then embrace the opportunity to grow as a developer.

For anything larger than one-liner commits, make sure to check out the code for the pull request in your IDE. This makes it easier to follow links in the code and to search for usages of functions and variables. It also allows you to spot changes the developer should have done but have missed out, e.g. if a function is invoked at several places but the developer only have updated it at one place.

When writing comments on the review, be clear what you mean. If it is a matter of opinion, please make sure to motivate your answer. Apart from when your office's coffee machine decides to brew a "null coffee", there are few things as annoying as an opinionated review comment without an explanation sent with a confident "I'm the architect" attitude.

A little more seems about enough

Speaking about opinions. Don't be that bossy architect guy, unless your team haven't discussed the expectations of code reviews and asked for very critical reviews. If you have opinions, my personal opinion is that they shouldn't block merging if it isn't important.

To continuously interrupting work to fix arguably unimportant stuff like a function name which "could have been better" or an if statement which "could have used an if else" is really annoying and is time spent on fairly worthless matters. Not everyone cares if the attributes are sorted alphabetically. If you have strong feelings about it, make the linter complain about it.

In the end, it's up to your team to decide where the line goes. What are opinions and when will they need to be fixed? Should they block merging or do they only have to be fixed if there are more severe changes which needs to be done?

What To Do After a Code Review

When the reviewer have reviewed the pull request and it is time to hand the comments over to the contributor, it's a good time for a talk. By going through the comments together both developers get a time together for some knowledge sharing and to sort out any unclear comments and avoid misunderstandings.

As the author of the commit, this is the best opportunity to express any objections. If you think the comments make sense, make sure to not do the same mistake next time you push a pull request.

If everything looks good an you both are happy with the solution, go for a coffee together!