Create Next App

{ "title": "Stories by Wei Herr Teng on Medium", "description": "Stories by Wei Herr Teng on Medium", "link": "https://medium.com/@tengweiherr?source=rss-2d2d00a2592a------2", "image": "https://cdn-images-1.medium.com/fit/c/150/150/1*nG6y3XK2WX-gSQkCg9YVtQ.jpeg", "category": [], "items": [ { "id": "https://medium.com/p/ddf89d9ed04e", "title": "A/B Testing with NextJS middleware in favour of Core Web Vitals", "link": "https://tengweiherr.medium.com/a-b-testing-with-nextjs-middleware-in-favour-of-core-web-vitals-ddf89d9ed04e?source=rss-2d2d00a2592a------2", "author": "Wei Herr Teng", "published": 1680108479000, "created": 1680108479000, "category": [ "core-web-vitals", "web-performance", "a-b-testing", "nextjs", "firebase-remote-config" ], "content": "

Consuming your feature flags on Firebase remote config through NextJS middleware — with the best performance.

💡 This article demonstrates how to do A/B testing with Firebase Remote Config through NextJS edge middleware. See Vercel’s examples for more feature flag tool demos including similar approach for Split here.

Problems of A/B testing on web

A/B testing is a statistical technique used to test new features or different versions of an application on a select group of users before making them available to all users. On the webapp I am currently working with in my company, we use feature flagging tools like Split and Firebase Remote Config to enable product owners or managers to control feature flags remotely. Currently, we have 13 feature flags active in production, which are fetched in 17 different places on our React SPA. This negatively affects our website’s performance and user experience. This is also one of the reasons we are migrating to NextJS framework.

Client-side A/B testing

Client-side A/B testing is expensive as it results in delays and negatively impacts core web vitals scores such as LCP, FCP, and CLS. This is due to HTTP requests being sent to fetch feature flag treatments on client-side and dynamically modify the DOM.

Server-side A/B testing

Migrating to NextJS allows server-side A/B testing, but it still requires fetching treatment for each request. This approach can reduce CLS, but doesn’t improve LCP or FCP. It can also cause other issues such as inconsistent responses from the same URL and less effective CDN caching.

Although it is possible to avoid fetching the feature flag on every visit by utilising cookies and local storage, it is still necessary to perform server-side rendering on each request as the page content may vary depending on the feature flag. Either method ends up losing benefits like caching. Is there a way where we can leverage NextJS static site generation (SSG) and caching while still carrying out dynamic content generation? This is where NextJS edge middleware comes into play.

What is NextJS middleware?

Middleware allows you to run code before a request is completed, then based on the incoming request, you can modify the response by rewriting, redirecting, modifying the request or response headers, or responding directly.

NextJS middleware, a feature under edge runtime, can:

Redirect incoming requests to a different URL
Rewrite the response, displaying a given URL or rewriting it to a page or API
Set request headers
Set response headers
Set response cookies

A/B testing through NextJS middleware and SSG

This article demonstrates how to do A/B testing with Firebase Remote Config through middleware. To improve performance, we can use A/B testing with NextJS middleware:

Lower latency: NextJS middleware runs at the edge, resulting in faster execution times. Learn more.
Avoid multiple attempts at the same URL: We can set the treatment in the response cookie and read it on each request to prevent duplicates.
Faster response times: We use static site generation (SSG) to build and cache static page variants during build time. Based on the treatment, we can rewrite the request URL and bring users to the respective static page.

High level overview

To perform A/B testing on the about page with three variants (A as default, B, and C), we follow these steps:

Create the three variant pages in our codebase.
Build the app to generate static pages for each variant (/about, /about/A, /about/B).
When a client visits the about page, the middleware intercepts the request and checks if the key firebase-remote-config.about_variant exists in the cookie. You can decide the name of the key on your own.
If the key does not exist, we know it is a new visitor.
The middleware calls an API route to send HTTP request to retrieve the configs using Firebase Admin SDK.
Run rolling dice function to randomly select a variant.
Set the variant in the cookie and update the request URL accordingly (e.g., /about/C).
Rewrite the URL using NextResponse.rewrite to display the default URL of the about page.
Return the response.

Flow diagram

⚠️ We cannot do fetch configs from Firebase Admin SDK directly on middleware due to the incompatibility of Firebase Admin SDK in Edge runtime. Also, we cannot use Firebase Remote Config SDK as they don’t allow fetching in server. However, it should be straight-forward if we are fetching feature flag treatment from Split as they provide API to fetch in server.

Preview link: https://nextjs-middleware-ab-testing-git-ssg-tengweiherr.vercel.app/about

For the complete code, check out my repo here.

Result

\"\" — Result of **NextJs middleware + SSG**

By comparing the results, we can see that using NextJS middleware reduces the execution times for duplicate visits by about 90%. However, the execution time for the first visit is still unacceptably high.

Further improved: NextJS middleware + SSG + Prefetching

To reduce the execution times of the first visit, we can prefetch the configurations at pre-build time. This approach is inspired by the Split example from Vercel and the blog post How to start A/B testing your Next.js site from Kontent.ai.

High level overview

Similar to NextJS middleware + SSG, we create three variant pages in our codebase.
We run a script during pre-build time to fetch the configurations from Firebase.
We write the configurations to a JSON file and store it in a directory.
Proceed to build the app to generate static pages for each variant (/about, /about/A, /about/B).
When a client requests the about page, instead of calling API routes and sending HTTP requests to fetch data from Firebase, the middleware can directly retrieve the data from the pre-generated JSON file and assign a variant to it, as it did previously.
The remaining steps are the same as in NextJS middleware + SSG.
We can write a trigger function using Cloud Functions to watch Firebase Remote Config and send a deployment hook request to Vercel when the configuration settings are changed.

Flow diagram

Preview link: https://feature-flag-firebase-remote-config.vercel.app

For the complete code, check out my repo here.

Final result

\"\" — Result of **NextJS middleware + SSG + Prefetching**

As you can see from the result above, we managed to reduce execution times for every requests as low as possible.

Disadvantages

As importing file in codebase is static, we have to make sure the JSON file used to populate data exists in the specific path before build to avoid syntax error.
[Only for Firebase] You lose track of the fetch data on Firebase Remote Config since it’s not fetched on the client-side. Same applies to NextJS middleware + SSG approach.
[Only for Firebase] You are required to pay extra attention to the rolling dice function because it determines the variant. If there is a bug in the function, the A/B testing is rendered meaningless. However, you can track the variant using Segment events or other tracking tools.

Limitation of NextJS Middleware

A Middleware function can only be 1MB in size, including all other code that comes with it.
A middleware function can run for up to 30 seconds, but it must produce a response in 1.5 seconds. This implies that your function should respond as soon as feasible, allowing you to continue working on other tasks in the background if necessary.
Native NodeJS APIs are not supported. (such as fs) Read more at Edge Runtime APIs.
ES Modules supported only

Other use cases

Authentication and authorisation
Geolocation blocking
Redirecting or blocking on specific route
Adding custom header

Conclusion

With NextJS edge middleware, the server can intercept incoming requests and make real-time decisions based on the feature flag state. This allows for dynamic content generation while still utilising the benefits of static site generation. With some extra tweaks like prefetching, developers can further optimise the performance of their feature flagging implementation while still providing dynamic content to their users. It can be further powered and tailored to other use cases by leveraging other services like Firebase Cloud Functions or AWS Lambda.

Resources

Repo:
https://github.com/tengweiherr/feature-flag-firebase-remote-config

Link for NextJS Middleware + SSG:
https://nextjs-middleware-ab-testing-git-ssg-tengweiherr.vercel.app/about

Link for NextJS Middleware + SSG + Prefetch:
https://feature-flag-firebase-remote-config.vercel.app

Other use cases of NextJS Middleware:
vercel/examples/edge-middleware

Similar approach for Split:
vercel/examples/edge-middleware/feature-flag-split/

Article related to this approach:
https://kontent.ai/blog/how-to-start-a-b-testing-your-next-js-site/

Try it out on your own

Create your Firebase account and start a new project in Remote Config following the steps here.
Setup your first remote config and a few conditions.
At Firebase Remote Config console, go to Project Overview > Project Settings > Service accounts tab and click the button Generate new private key.
Git clone my repo here.
Create an .env.local file at root directory and paste the config generated previously at Firebase. Code example is at below.
Delete everything in src/utils/static/rc-prefetched-data.json. It will automatically populate your data here later.
Run yarn to install dependencies.
Run yarn start:dev to run locally.

File structure

Code examples

package.json

{
  ...
  \"scripts\": {
    ...
    \"prestart\": \"node ./src/utils/scripts/runner.js\", // for next start
    \"prebuild\": \"node ./src/utils/scripts/runner.js\", // for next build
    ...
  },
  ...
}

.env.local

// Get your config form Firebase Service Account
PRIVATE_KEY_ID=
PRIVATE_KEY=
CLIENT_EMAIL=
CLIENT_ID=
AUTH_URI=
TOKEN_URI=
AUTH_PROVIDER_X509_CERT_URL=
CLIENT_X509_CERT_URL=

src/utils/scripts/runner.js

const pkg = require('@next/env')
const fs = require('fs')
const path = require('path')

const { loadEnvConfig } = pkg;
loadEnvConfig(process.cwd())

const runAsync = async () => {

    // find all scripts in subfolder
    const files = fs
        .readdirSync(path.join(__dirname, 'pre-build'))
        .filter(file => file.endsWith('.js'))
        .sort()

    for (const file of files) {
       const { createStaticFile: defaultFunc } = await require(`./pre-build/${file}`)
      try {
       console.log(`SCRIPT RUNNER: Running pre-build script '${file}'`)
       await defaultFunc({ env: process.env })
      } catch (e) {
       console.error(`SCRIPT RUNNER: Failed to execute pre-build script '${file}'`)
       console.error(e)
      }
    }

}

// Self-invocation async function
;(async () => {
 await runAsync().then(()=>{
  console.log('SCRIPT RUNNER: Done running all pre-build scripts.')
 })
})().catch(err => {
 console.error(err)
 throw err
})

src/utils/scripts/pre-build/setupRemoteConfig.js

const fs = require('fs')
const path = require('path')
const admin = require('firebase-admin')
const prettier = require('prettier')

async function createStaticFile() {
    
    const fullFilePath = path.join(process.cwd(), 'src/utils/static', 'rc-prefetched-data.json')
    
    // firebase service acc
    const serviceAccount = {
        \"type\": \"service_account\",
        \"project_id\": \"testing-8c23b\",
        \"private_key_id\": process.env.PRIVATE_KEY_ID,
        \"private_key\": process.env.PRIVATE_KEY ? process.env.PRIVATE_KEY.replace(/\\\\n/gm, \"\\n\") : '',
        \"client_email\": process.env.CLIENT_EMAIL,
        \"client_id\": process.env.CLIENT_ID,
        \"auth_uri\": process.env.AUTH_URI,
        \"token_uri\": process.env.TOKEN_URI,
        \"auth_provider_x509_cert_url\": process.env.AUTH_PROVIDER_X509_CERT_URL,
        \"client_x509_cert_url\": process.env.CLIENT_X509_CERT_URL,
    }

    if(!admin.apps.length){
        admin.initializeApp({
            credential: admin.credential.cert(serviceAccount)
        });
    }
    
    const getRemoteConfig = async () => {
        let config = admin.remoteConfig();
        const template = await config.getTemplate()
        return template.parameters
       //all parameters will be under template.parameters
    }

    const res = await getRemoteConfig()

    const resArray = Object.entries(res)

    const data = resArray.map(item => {
        const [name, parameters] = item
        return {
           name: name,
           parameters: parameters
        }
     })

    const content = prettier.format(JSON.stringify(data), { parser: 'json' })

    // remove the old file
    if (fs.existsSync(fullFilePath)) {
      await fs.promises.unlink(fullFilePath)
    }

    await fs.promises.writeFile(fullFilePath, content)

}

module.exports = { createStaticFile }

src/middleware.ts

import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'
import { cryptoRandom } from './utils/helper'
import { ParameterValueType } from 'firebase-admin/lib/remote-config/remote-config-api'

interface RemoteConfigData {
  name: string
  parameters: {
    defaultValue: {
      value: string
    }
    conditionalValues?: Record
    description?: string
    valueType?: ParameterValueType | string
  }
}

interface Condition {
  weight: number
  value?: string
}

export const config = {
  matcher: '/about/:path*',
}

export async function middleware(request: NextRequest) {

  try {

    const remoteConfig = await getRemoteConfig(request,'about_variant');

    if(!remoteConfig) return

    const { name, parameters } = remoteConfig;

    // Set custom cookieValue
    const cookieKey = `firebase-remote-config.${name}`

    let cookieValue = request.cookies.get(cookieKey)?.value

    // Check if it is new visitor
    if (!cookieValue) cookieValue = getVariantByRandom(parameters)

    // Set route to the variant page 
    if(cookieValue !== 'A') request.nextUrl.pathname = `/about/${cookieValue}`

    if(cookieValue){
      // Redirect URL
      const response = NextResponse.rewrite(request.nextUrl)
      // Set custom cookie value
      response.cookies.set(cookieKey, cookieValue ? cookieValue : 'A')
      // Set custom header if needed
      response.headers.set('x-about-variant', JSON.stringify(cookieValue))

      return response
    }

    return

  } catch (error) {
    console.log(error)
  }

}

const getRemoteConfig = async (request: NextRequest, configName:string) => {

  return import(\"./utils/static/rc-prefetched-data.json\").then(async({default:prefetchedData})=>{

    let data = undefined

    // If the json file is empty
    if(!prefetchedData || prefetchedData.length === 0) {
        data = await (await fetch(`${request.nextUrl.origin}/api/fetchRemoteConfig`)).json()
        console.log('Fetching Firebase Remote Config')
    }

    data = prefetchedData.find(({ name }:RemoteConfigData)=>name === configName)

    return data

  })

}

const getVariantByRandom = (parameters:RemoteConfigData[\"parameters\"]):string => {

  let defaultValue = parameters.defaultValue

  let conditionalValues = parameters.conditionalValues

  let conditions:Array = conditionalValues 
    ? Object.entries(conditionalValues).map((item)=>{
        // Check if the value is undefined
        if(item[1] === undefined) return {weight:0, value:undefined}
        const [ name, {value} ] = item
        const res = {
          weight: parseInt(name.split('%')[0]),
          value: value
        }
        return res
      })
    : []

  // Rolling dice
  let n = cryptoRandom() * 100
  let cookieValue = defaultValue.value

  conditions.forEach(({weight,value}:Condition) => {

    if( n <= 0 ) cookieValue = defaultValue?.value

    if (n < weight) {
      if(value) cookieValue = value
    } else {
      n -= weight
    }
    
  });

  return cookieValue

}

src/pages/api/fetchRemoteConfig.ts

// export const runtime = 'edge';

import { NextApiRequest, NextApiResponse } from \"next\";
import admin from 'firebase-admin'
import { FIREBASE_SERVICE_ACCOUNT } from \"@/utils/const\";

const serviceAccount = FIREBASE_SERVICE_ACCOUNT

if(!admin.apps.length){
    admin.initializeApp({
        credential: admin.credential.cert(serviceAccount)
    });
}

const getRemoteConfig = async () => {
    let config = admin.remoteConfig();
    const template = await config.getTemplate()
    return template.parameters
   //all parameters will be under template.parameters
}

export default async function handler(req:NextApiRequest, res:NextApiResponse) {

    const fetched = await getRemoteConfig()

    const resArray = Object.entries(fetched)

    const data = resArray.map(item => {
        const [name, parameters] = item
        return {
          name: name,
          parameters: parameters
        }
     })

    res.status(200).json(data)
}

src/pages/about/index.ts (this is variant A, same goes to variant B and C)

import Head from 'next/head'
import styles from '@/styles/Home.module.css'

export default function VariantA() {
  return (
    <>
      
        Create Next App
        
        
        
      
      
        
          Variant A

        

      

    
  )
}

$\"\"$ ", "enclosures": [], "content_encoded": "

Consuming your feature flags on Firebase remote config through NextJS middleware — with the best performance.

💡 This article demonstrates how to do A/B testing with Firebase Remote Config through NextJS edge middleware. See Vercel’s examples for more feature flag tool demos including similar approach for Split here.

Problems of A/B testing on web

Client-side A/B testing

Server-side A/B testing

What is NextJS middleware?

Middleware allows you to run code before a request is completed, then based on the incoming request, you can modify the response by rewriting, redirecting, modifying the request or response headers, or responding directly.

NextJS middleware, a feature under edge runtime, can:

Redirect incoming requests to a different URL
Rewrite the response, displaying a given URL or rewriting it to a page or API
Set request headers
Set response headers
Set response cookies

A/B testing through NextJS middleware and SSG

This article demonstrates how to do A/B testing with Firebase Remote Config through middleware. To improve performance, we can use A/B testing with NextJS middleware:

Lower latency: NextJS middleware runs at the edge, resulting in faster execution times. Learn more.
Avoid multiple attempts at the same URL: We can set the treatment in the response cookie and read it on each request to prevent duplicates.
Faster response times: We use static site generation (SSG) to build and cache static page variants during build time. Based on the treatment, we can rewrite the request URL and bring users to the respective static page.

High level overview

To perform A/B testing on the about page with three variants (A as default, B, and C), we follow these steps:

Create the three variant pages in our codebase.
Build the app to generate static pages for each variant (/about, /about/A, /about/B).
When a client visits the about page, the middleware intercepts the request and checks if the key firebase-remote-config.about_variant exists in the cookie. You can decide the name of the key on your own.
If the key does not exist, we know it is a new visitor.
The middleware calls an API route to send HTTP request to retrieve the configs using Firebase Admin SDK.
Run rolling dice function to randomly select a variant.
Set the variant in the cookie and update the request URL accordingly (e.g., /about/C).
Rewrite the URL using NextResponse.rewrite to display the default URL of the about page.
Return the response.

Flow diagram

⚠️ We cannot do fetch configs from Firebase Admin SDK directly on middleware due to the incompatibility of Firebase Admin SDK in Edge runtime. Also, we cannot use Firebase Remote Config SDK as they don’t allow fetching in server. However, it should be straight-forward if we are fetching feature flag treatment from Split as they provide API to fetch in server.

Preview link: https://nextjs-middleware-ab-testing-git-ssg-tengweiherr.vercel.app/about

For the complete code, check out my repo here.

Result

\"\" — Result of **NextJs middleware + SSG**

Further improved: NextJS middleware + SSG + Prefetching

High level overview

Similar to NextJS middleware + SSG, we create three variant pages in our codebase.
We run a script during pre-build time to fetch the configurations from Firebase.
We write the configurations to a JSON file and store it in a directory.
Proceed to build the app to generate static pages for each variant (/about, /about/A, /about/B).
When a client requests the about page, instead of calling API routes and sending HTTP requests to fetch data from Firebase, the middleware can directly retrieve the data from the pre-generated JSON file and assign a variant to it, as it did previously.
The remaining steps are the same as in NextJS middleware + SSG.
We can write a trigger function using Cloud Functions to watch Firebase Remote Config and send a deployment hook request to Vercel when the configuration settings are changed.

Flow diagram

Preview link: https://feature-flag-firebase-remote-config.vercel.app

For the complete code, check out my repo here.

Final result

\"\" — Result of **NextJS middleware + SSG + Prefetching**

As you can see from the result above, we managed to reduce execution times for every requests as low as possible.

Disadvantages

As importing file in codebase is static, we have to make sure the JSON file used to populate data exists in the specific path before build to avoid syntax error.
[Only for Firebase] You lose track of the fetch data on Firebase Remote Config since it’s not fetched on the client-side. Same applies to NextJS middleware + SSG approach.
[Only for Firebase] You are required to pay extra attention to the rolling dice function because it determines the variant. If there is a bug in the function, the A/B testing is rendered meaningless. However, you can track the variant using Segment events or other tracking tools.

Limitation of NextJS Middleware

A Middleware function can only be 1MB in size, including all other code that comes with it.
A middleware function can run for up to 30 seconds, but it must produce a response in 1.5 seconds. This implies that your function should respond as soon as feasible, allowing you to continue working on other tasks in the background if necessary.
Native NodeJS APIs are not supported. (such as fs) Read more at Edge Runtime APIs.
ES Modules supported only

Other use cases

Authentication and authorisation
Geolocation blocking
Redirecting or blocking on specific route
Adding custom header

Conclusion

Resources

Repo:
https://github.com/tengweiherr/feature-flag-firebase-remote-config

Link for NextJS Middleware + SSG:
https://nextjs-middleware-ab-testing-git-ssg-tengweiherr.vercel.app/about

Link for NextJS Middleware + SSG + Prefetch:
https://feature-flag-firebase-remote-config.vercel.app

Other use cases of NextJS Middleware:
vercel/examples/edge-middleware

Similar approach for Split:
vercel/examples/edge-middleware/feature-flag-split/

Article related to this approach:
https://kontent.ai/blog/how-to-start-a-b-testing-your-next-js-site/

Try it out on your own

Create your Firebase account and start a new project in Remote Config following the steps here.
Setup your first remote config and a few conditions.
At Firebase Remote Config console, go to Project Overview > Project Settings > Service accounts tab and click the button Generate new private key.
Git clone my repo here.
Create an .env.local file at root directory and paste the config generated previously at Firebase. Code example is at below.
Delete everything in src/utils/static/rc-prefetched-data.json. It will automatically populate your data here later.
Run yarn to install dependencies.
Run yarn start:dev to run locally.

File structure

Code examples

package.json

{
  ...
  \"scripts\": {
    ...
    \"prestart\": \"node ./src/utils/scripts/runner.js\", // for next start
    \"prebuild\": \"node ./src/utils/scripts/runner.js\", // for next build
    ...
  },
  ...
}

.env.local

// Get your config form Firebase Service Account
PRIVATE_KEY_ID=
PRIVATE_KEY=
CLIENT_EMAIL=
CLIENT_ID=
AUTH_URI=
TOKEN_URI=
AUTH_PROVIDER_X509_CERT_URL=
CLIENT_X509_CERT_URL=

src/utils/scripts/runner.js

const pkg = require('@next/env')
const fs = require('fs')
const path = require('path')

const { loadEnvConfig } = pkg;
loadEnvConfig(process.cwd())

const runAsync = async () => {

    // find all scripts in subfolder
    const files = fs
        .readdirSync(path.join(__dirname, 'pre-build'))
        .filter(file => file.endsWith('.js'))
        .sort()

    for (const file of files) {
       const { createStaticFile: defaultFunc } = await require(`./pre-build/${file}`)
      try {
       console.log(`SCRIPT RUNNER: Running pre-build script '${file}'`)
       await defaultFunc({ env: process.env })
      } catch (e) {
       console.error(`SCRIPT RUNNER: Failed to execute pre-build script '${file}'`)
       console.error(e)
      }
    }

}

// Self-invocation async function
;(async () => {
 await runAsync().then(()=>{
  console.log('SCRIPT RUNNER: Done running all pre-build scripts.')
 })
})().catch(err => {
 console.error(err)
 throw err
})

src/utils/scripts/pre-build/setupRemoteConfig.js

const fs = require('fs')
const path = require('path')
const admin = require('firebase-admin')
const prettier = require('prettier')

async function createStaticFile() {
    
    const fullFilePath = path.join(process.cwd(), 'src/utils/static', 'rc-prefetched-data.json')
    
    // firebase service acc
    const serviceAccount = {
        \"type\": \"service_account\",
        \"project_id\": \"testing-8c23b\",
        \"private_key_id\": process.env.PRIVATE_KEY_ID,
        \"private_key\": process.env.PRIVATE_KEY ? process.env.PRIVATE_KEY.replace(/\\\\n/gm, \"\\n\") : '',
        \"client_email\": process.env.CLIENT_EMAIL,
        \"client_id\": process.env.CLIENT_ID,
        \"auth_uri\": process.env.AUTH_URI,
        \"token_uri\": process.env.TOKEN_URI,
        \"auth_provider_x509_cert_url\": process.env.AUTH_PROVIDER_X509_CERT_URL,
        \"client_x509_cert_url\": process.env.CLIENT_X509_CERT_URL,
    }

    if(!admin.apps.length){
        admin.initializeApp({
            credential: admin.credential.cert(serviceAccount)
        });
    }
    
    const getRemoteConfig = async () => {
        let config = admin.remoteConfig();
        const template = await config.getTemplate()
        return template.parameters
       //all parameters will be under template.parameters
    }

    const res = await getRemoteConfig()

    const resArray = Object.entries(res)

    const data = resArray.map(item => {
        const [name, parameters] = item
        return {
           name: name,
           parameters: parameters
        }
     })

    const content = prettier.format(JSON.stringify(data), { parser: 'json' })

    // remove the old file
    if (fs.existsSync(fullFilePath)) {
      await fs.promises.unlink(fullFilePath)
    }

    await fs.promises.writeFile(fullFilePath, content)

}

module.exports = { createStaticFile }

src/middleware.ts

import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'
import { cryptoRandom } from './utils/helper'
import { ParameterValueType } from 'firebase-admin/lib/remote-config/remote-config-api'

interface RemoteConfigData {
  name: string
  parameters: {
    defaultValue: {
      value: string
    }
    conditionalValues?: Record
    description?: string
    valueType?: ParameterValueType | string
  }
}

interface Condition {
  weight: number
  value?: string
}

export const config = {
  matcher: '/about/:path*',
}

export async function middleware(request: NextRequest) {

  try {

    const remoteConfig = await getRemoteConfig(request,'about_variant');

    if(!remoteConfig) return

    const { name, parameters } = remoteConfig;

    // Set custom cookieValue
    const cookieKey = `firebase-remote-config.${name}`

    let cookieValue = request.cookies.get(cookieKey)?.value

    // Check if it is new visitor
    if (!cookieValue) cookieValue = getVariantByRandom(parameters)

    // Set route to the variant page 
    if(cookieValue !== 'A') request.nextUrl.pathname = `/about/${cookieValue}`

    if(cookieValue){
      // Redirect URL
      const response = NextResponse.rewrite(request.nextUrl)
      // Set custom cookie value
      response.cookies.set(cookieKey, cookieValue ? cookieValue : 'A')
      // Set custom header if needed
      response.headers.set('x-about-variant', JSON.stringify(cookieValue))

      return response
    }

    return

  } catch (error) {
    console.log(error)
  }

}

const getRemoteConfig = async (request: NextRequest, configName:string) => {

  return import(\"./utils/static/rc-prefetched-data.json\").then(async({default:prefetchedData})=>{

    let data = undefined

    // If the json file is empty
    if(!prefetchedData || prefetchedData.length === 0) {
        data = await (await fetch(`${request.nextUrl.origin}/api/fetchRemoteConfig`)).json()
        console.log('Fetching Firebase Remote Config')
    }

    data = prefetchedData.find(({ name }:RemoteConfigData)=>name === configName)

    return data

  })

}

const getVariantByRandom = (parameters:RemoteConfigData[\"parameters\"]):string => {

  let defaultValue = parameters.defaultValue

  let conditionalValues = parameters.conditionalValues

  let conditions:Array = conditionalValues 
    ? Object.entries(conditionalValues).map((item)=>{
        // Check if the value is undefined
        if(item[1] === undefined) return {weight:0, value:undefined}
        const [ name, {value} ] = item
        const res = {
          weight: parseInt(name.split('%')[0]),
          value: value
        }
        return res
      })
    : []

  // Rolling dice
  let n = cryptoRandom() * 100
  let cookieValue = defaultValue.value

  conditions.forEach(({weight,value}:Condition) => {

    if( n <= 0 ) cookieValue = defaultValue?.value

    if (n < weight) {
      if(value) cookieValue = value
    } else {
      n -= weight
    }
    
  });

  return cookieValue

}

src/pages/api/fetchRemoteConfig.ts

// export const runtime = 'edge';

import { NextApiRequest, NextApiResponse } from \"next\";
import admin from 'firebase-admin'
import { FIREBASE_SERVICE_ACCOUNT } from \"@/utils/const\";

const serviceAccount = FIREBASE_SERVICE_ACCOUNT

if(!admin.apps.length){
    admin.initializeApp({
        credential: admin.credential.cert(serviceAccount)
    });
}

const getRemoteConfig = async () => {
    let config = admin.remoteConfig();
    const template = await config.getTemplate()
    return template.parameters
   //all parameters will be under template.parameters
}

export default async function handler(req:NextApiRequest, res:NextApiResponse) {

    const fetched = await getRemoteConfig()

    const resArray = Object.entries(fetched)

    const data = resArray.map(item => {
        const [name, parameters] = item
        return {
          name: name,
          parameters: parameters
        }
     })

    res.status(200).json(data)
}

src/pages/about/index.ts (this is variant A, same goes to variant B and C)

import Head from 'next/head'
import styles from '@/styles/Home.module.css'

export default function VariantA() {
  return (
    <>
      
        Create Next App
        
        
        
      
      
        
          Variant A

        

      

    
  )
}

$\"\"$ ", "media": {} }, { "id": "https://medium.com/p/3f36d1909950", "title": "MobX with React functional components — better than Redux?", "link": "https://tengweiherr.medium.com/mobx-with-react-functional-components-better-than-redux-3f36d1909950?source=rss-2d2d00a2592a------2", "author": "Wei Herr Teng", "published": 1675687096000, "created": 1675687096000, "category": [ "redux", "javascript", "mobx", "react", "typescript" ], "content": "

MobX with React functional components setup — better than Redux?

Recommended MobX setup with React functional components

\"\" — Photo by Ferenc Almasi on Unsplash

Background
Core concept
— State
— Action
— Derivations
How it works
MobX file structure in React with functional components
APIs
— observable & makeObservable
— makeAutoObservable
— observer
— action
— runInAction
— ⚠️ Handling promises
— computed
— autorun
— reaction
— when
— ⚠️ Tips on autorun, reaction and when
Summary: MobX’s equivalent React hooks and class component
Debugging
— trace
Conclusion

Background

Coming from a background of Redux user, I used to believe Redux was the best option for global state management. You might notice that in most of the online tutorial, the state management library to be chosen in React project is always Redux. As a software engineering beginner tutored by YouTube, I was surprised by how clean and straight forward MobX is when I was working on a MobX project. Comparing to Redux, MobX is much cleaner, simpler yet still as powerful as Redux. It is even more optimal in performance comparing to Redux. However, there is not much discussion about MobX, especially with functional React on the internet. After digging deep into MobX library and implementing it in React, I would like to share my preferred practice with MobX + React functional components, along with code examples in TypeScript.

This article will focus on the MobX concept, basic usage with React functional components and my recommended setup with functional React. Please be informed that I will explain them with my own understanding, and will only cover the APIs that I often use. For detailed explanation and more advanced APIs, you can visit MobX for more information.

Core concept

Boilerplate-free, optimal rendering, un-opinionated (Any UI framework works)

Anything that can be derived from the application state, should be. Automatically. — from MobX documentation

State

Annotated as observable
Properties you want to observe or change over time
Accept any primitive or non-primitive data: objects, arrays, classes, maps, sets etc
Equivalent to useState’s state variable

Action

Annotated as action, runInAction
Function that changes the observable state
Equivalent to useState’s setter function

Derivations

Anything that can be derived from the observable state without any further interaction
They are tracked functions, which will be updated automatically when its corresponding observable state is modified
Equivalent to useEffect (kind of)

There are 2 types of Derivations:

Computed values

Annotated as computed
Value that can be derived from the observable state
Producing variable only

2. Reactions

Annotated as autorun, reaction, when
Side effects that need to happen automatically when the observable state changes
UI re-rendering, HTTP requests, printing consoles

How it works

\"\" — *Data flow presentation from* *MobX documentation*

Uni-directional data flow where:

Actions to trigger the update of the observable state
State updated notifies derivations to be updated
Triggers Derivations

Its optimal performance is due to:

Computed values are updated lazily. Any computed value that is not actively in use will not be updated until it is needed for a side effect (I/O). If a view is no longer in use it will be garbage collected automatically.

MobX file structure in React with functional components

I will be showing an example of setting up an simple price calculator.

The file structure:

\"\" — MobX + functional React setup file structure

First we run yarn add mobx mobx-react-lite in terminal to install MobX in React.

We make use of classes in JavaScript to setup MobX store. We create our calculator store with a class object called CalculatorStore for all the logics regarding to it. Here we declare variables price and amount, functions increasePrice() and increaseAmount() to update the states, and a getter function total() to calculate the total price. As usual, there is always a constructor in a class, and here we call makeAutoObservable(this) in the constructor, which will translate our variables and functions to MobX instances. In this case price and amount will be annotated as observable, increasePrice() and increaseAmount() will be annotated as action, while getter function total() will be annotated as computed.

/utils/store/timer-store.ts

import { makeAutoObservable } from \"mobx\"

export class CalculatorStore {

    price = 0

    amount = 1

    constructor() {
        makeAutoObservable(this)
    }

    increasePrice() {
        this.price += 1
    }

    increaseAmount() {
        this.amount += 1
    }

    get total() {
        return this.price * this.amount
    }

}

Next, we create an index.ts within the store folder to import all the stores, initiate them and export them in one file. It might seem redundant for one store, but in real world project we will have a lot of stores created. It is much cleaner than exporting all the stores with their respective file.

/utils/store/index.ts

import { CalculatorStore } from \"./calculator-store\";

const calculatorStore = new CalculatorStore()

export { calculatorStore }

Eventually this is our component Calculator.tsx. To use MobX with functional React, we can wrap our component with an observer HoC. observer is provided by a separate React bindings package of MobX called mobx-react-lite. We pass in calculator store as a prop to access the store we have initiated in the /utils/store/index.ts.

Timer.tsx

import { useEffect } from \"react\"
import { autorun } from \"mobx\"
import { observer } from \"mobx-react-lite\"
import { CalculatorStore } from \"../utils/store/calculator-store\"

type CalculatorProps = {
    calculatorStore: CalculatorStore
}

const Calculator = ({calculatorStore}:CalculatorProps) => {

    // Effect that triggers upon observable changes.
    useEffect(() => {
        const disposer = autorun(() => {
            if(calculatorStore.total) console.log(\"the total is updated: \" + calculatorStore.total)
        })
        return () => disposer()
    },[])

    return (
        
            Price: {calculatorStore.price}

            

            Amount: {calculatorStore.amount}

              
      
            Total: {calculatorStore.total}
      
        

    )

}
export default observer(Calculator)

The result:

\"\" — Simple price calculator on browser

That’s it! It is definitely a faster and less boilerplate setup comparing to Redux. Let’s break it down and explain along with the respective MobX API.

APIs

observable & makeObservable

observable defines a trackable field that stores the state
makeObservable make the object passed in become observable
These 2 APIs are used together to provide reactive component with observable states
Equivalent to useState’s state variable

import { makeObservable, observable } from \"mobx\"

export class CalculatorStore {

    price = 0

    amount = 1

    constructor() {
        makeObservable(this, {
            price: observable,
            amount: observable,
        })
    }

}

makeAutoObservable

makeAutoObservable is a shortcut to translate the class fields to MobX instances
It infers all the properties by default, such as:

All own properties become observable
All getters become computed
All setters become action

import { makeAutoObservable } from \"mobx\"

export class CalculatorStore {

    price = 0

    amount = 1

    constructor() {
        makeAutoObservable(this)
    }

    increasePrice() {
        this.price += 1
    }

    increaseAmount() {
        this.amount += 1
    }

    get total() {
        return this.price * this.amount
    }

}

observer

observer is a HoC which can be used to wrap a react component so that it will automatically detect that rendering depends on observable states inside

import { observer } from \"mobx-react-lite\"
import { CalculatorStore } from \"../utils/store/calculator-store\"

type CalculatorProps = {
    calculatorStore: CalculatorStore
}

const Calculator = ({calculatorStore}:CalculatorProps) => {
    return (
        
            Price: {calculatorStore.price}

            

            Amount: {calculatorStore.amount}

              
      
            Total: {calculatorStore.total}
      
        

    )
}
export default observer(Calculator)

action

action is a function which modifies the observable state
You still can update the state without declaring it as action , but it is recommended to do so. With this practice, MobX can automatically apply transactions for effortless optimal performance
When handling promises, the handlers that update state should be actions or should be annotated as action (We will discuss later)
Equivalent to useState’s setter function

export class DateStore {
    date: any

    constructor() {
        makeAutoObservable(this)
        autorun(()=>{
         this.setDate(new Date())
        })
    }

    setDate(date:Date) {
        this.date = date
    }
  
}

runInAction

runInAction creates an one-time action that is immediately invoked
It wraps a function
Most suitable when you just need to update the state once, so you don’t need to create an action separately just to do it once
We have to use runInAction to allow making changes outside of an action

export class DateStore {
    date: any

    constructor() {
        makeAutoObservable(this)
        runInAction(()=>{
            this.date = new Date()
        })
    }

}

⚠️ Handling promises

When handling promises, even if the function that makes the promise handling itself is already an action, since it runs after the original action finished, the promise handling part should be annotated as action again. It can be done by:

Separating them in different class fields, as they will be annotated as action by makeAutoObservable automatically

export class TodoStore {

    todos:any

    abortController?: AbortController

    constructor() {
        makeAutoObservable(this)
    }

    abortRequest() {
        if(this.abortController) this.abortController.abort()
    }

    fetchRequest(){
        runInAction(() => {
            this.abortController = new AbortController();
        })
        if(this.abortController){
            const signal = this.abortController.signal
            fetch('',{signal})
             .then(this.fetchSuccess, this.fetchFailure)
        }
    }

    fetchSuccess = todos => {
        this.todos = todos.json()
    }

    fetchFailure = error => {
        if (!this.abortController.signal.aborted) console.log(error)
    }
}

2. Using runInAction

export class TodoStore {

    todos:any

    abortController?: AbortController

    constructor() {
        makeAutoObservable(this)
    }

    abortRequest() {
        if(this.abortController) this.abortController.abort()
    }

    fetchRequest(){
        runInAction(() => {
            this.abortController = new AbortController();
        })
        if(this.abortController){
            const signal = this.abortController.signal
            fetch('',{signal})
             .then(response => response.json())
             .then(result => {
                runInAction(() => {
                  this.todos = result
                })
              })
             .catch(error => {
                 if (!this.abortController.signal.aborted) console.log(error)
              })
        }
    }

}

In the component, fetch it in useEffect() and return the cleanup function abortRequest() when the component unmounts.

useEffect(() => {
    todoStore.fetchRequest()
    return () => todoStore.abortRequest()
},[])

computed

computed is a JS get function that will derive new facts from the state and cache its output (highly optimised)
Only recomputes if one of the underlying observables has changed
No parameters accepted and must return a value

We can use the calculator example earlier but with some changes to explain how computed works.

calculator-store.ts

export class CalculatorStore {

    price = 0

    amount = 1

    constructor() {
        makeAutoObservable(this)
    }

    increasePrice(price:number) {
        this.price += price
    }

    increaseAmount() {
        this.amount += 1
    }

    get total() {
        return this.price * this.amount
    }

}

Calculator.tsx

type CalculatorProps = {
    calculatorStore: CalculatorStore
}

const Calculator = ({calculatorStore}:CalculatorProps) => {

    const [input, setInput] = useState(0)

    // Effect that triggers upon observable changes.
    useEffect(()=>{
        const disposer = autorun(() => {
            if(calculatorStore.total) console.log(\"the total is updated: \" + calculatorStore.total)
        })
        return () => disposer()
    },[])

    return (
        
            Price: {calculatorStore.price}

            setInput(parseInt(e.target.value))}/>
            

            Amount: {calculatorStore.amount}

             

            Total: {calculatorStore.total}
   
        

    )
}
export default observer(Calculator)

Please take note on this part of codes. What it does is to print the statement to console when computed is called. We will explain about autorun later.

useEffect(()=>{
    const disposer = autorun(() => {
        if(calculatorStore.total) console.log(\"the total is updated: \" + calculatorStore.total)
    })
    return () => disposer()
},[])

So in this case when we click the button with Increase Amount, the total is still 0, of course, because price is still 0. At the same time it won’t print anything in console, although the observable amount underlying is updated! This is because the result of total is the same.

\"\" — After clicking **Increase Amount** button 5 times

But if we set 50 in the price input and click Increase Price, the total is now updated to 250. Yes it is a simple math, but now it prints a statement in the console, which means the total() is now called! This is because the result of total now is different from previous result.

\"\" — After setting 50 in price input and clicking **Increase Price** button

So in short, computed watches the observables underlying. It will only recompute when it is initialised, and when its output is different.

autorun

autorun reads & subscribes the observable state
It runs the first time & every time the observable state underlying changes
It only responds to changes in observable state or things annotated observable or computed
To integrate it in React functional component, we need to make use of useEffect() to initialise it when the component mounts
Equivalent to useEffect with dependency

type CalculatorProps = {
    calculatorStore: CalculatorStore
}

const Calculator = ({calculatorStore}:CalculatorProps) => {

  const [input, setInput] = useState(0)

    // Effect that triggers upon observable changes.
    useEffect(() => {
        const disposer = autorun(() => {
            if(calculatorStore.total) console.log(\"the total is updated: \" + calculatorStore.total)
        })
        return () => disposer()
    },[])

    return (
        
            Price: {calculatorStore.price}

            setInput(parseInt(e.target.value))}/>
            

            Amount: {calculatorStore.amount}

             

            Total: {calculatorStore.total}
   
        

    )
}
export default observer(Calculator)

reaction

It takes two functions as parameters:

Data function: It returns the data that is used as input for the second, effect function
Effect function: Only reacts to data that was accessed in the data function

reaction(
  () => value, 
  (value, previousValue, reaction) => { sideEffect }
  , options?
)

The result of the data function has to change in order for the effect function to be triggered
It works almost like autorun but it don't run when initialised, instead only run after the data function returns a new value for the first time
Like autorun, we also need to make use of useEffect() to initialise it when the component mounts

useEffect(()=>{
  const disposer = reaction(
      () => calculatorStore.total,
      total => {
        if (total > 100) console.log(\"Total exceeds 100\")
        else console.log(\"Total less than 100\")
      }
    )
  return () => disposer()
},[])

when

It takes two functions as parameters as well:

Predicate function: It observes and run until it returns true
Effect function: To be executed when predicate is true

when(predicate: () => boolean, effect?: () => void, options?)
//or...
when(predicate: () => boolean, options?): Promise

It will be disposed automatically when the predicate function returns true and the effect function executed
Really useful for disposing autorun and reaction earlier if you don’t need them anymore instead of waiting until the component unmount

useEffect(() => {

    const disposer = autorun(() => {
        if(calculatorStore.total) console.log(\"the total is updated: \" + calculatorStore.total)
    })

    when(
        () => calculatorStore.total > 100,
        () => disposer()
    )

},[])

⚠️ Tips on autorun, reaction and when

autorun, reaction and when will keep waiting forever for new changes to happen in the observables they use. Hence, they are designed to return a disposer function that can be used to stop them and unsubscribe from any observables they used. To avoid memory leaks, it is strongly recommended to always assign them to a variable called disposer and call this variable to stop them from waiting.

Also always return autorun, reaction orwhen in useEffect(). This ensures that the reaction is only created once, and removed when the component is unmounted.

Assign reactions to disposer, and call them to stop them from waiting

const disposer = autorun(() => {
    ...
})

disposer()

2. Return reactions in useEffect React hook

useEffect(() => {

    const disposer = autorun(() => {
        ...
    })

    return () => disposer()

},[])

3. Implement of when

useEffect(() => {

    const disposer = autorun(() => {
        ...
    })

    when(
        () => yourCondition,
        () => disposer()
    )

},[])

Summary: MobX’s equivalent React hooks and class component

Debugging

trace

calling trace() inside tracked functions like computed and autorun to verify what observables MobX are tracking. The tracing will be printed in the console.

get total() {
    trace()
    return this.price * this.amount
}

// Output: 
// [mobx.trace] 'CalculatorStore@1.total' tracing enabled
// [mobx.trace] 'CalculatorStore@1.total' is invalidated due to a change in: 'CalculatorStore@1.price'

We can trace reaction by using trace() outside of the function:

const disposer = reaction(
...
)
trace(disposer)

Conclusion

I believe these APIs will cover most of the use cases. You can see how easy and clean setup it is comparing to Redux or even with Redux Toolkit. Unlike Redux, we don’t need extra hooks like useSelector and useDispatch to manage the states, a lot of boilerplate to create store and reducer, extra tweak to work with TypeScript and etc. To deal with async tasks like HTTP requests, MobX has much simpler way to do it unlike Redux implementing with its middleware tool such as redux-thunk.

However, what it all comes down to is personal preference. There is no right or wrong on choosing your tool, as long as they works :) Please leave a comment if you have better ideas and give a thumbs-up if you find this article helpful!

$\"\"$ ", "enclosures": [], "content_encoded": "

MobX with React functional components setup — better than Redux?

Recommended MobX setup with React functional components

\"\" — Photo by Ferenc Almasi on Unsplash

Background
Core concept
— State
— Action
— Derivations
How it works
MobX file structure in React with functional components
APIs
— observable & makeObservable
— makeAutoObservable
— observer
— action
— runInAction
— ⚠️ Handling promises
— computed
— autorun
— reaction
— when
— ⚠️ Tips on autorun, reaction and when
Summary: MobX’s equivalent React hooks and class component
Debugging
— trace
Conclusion

Background

Core concept

Boilerplate-free, optimal rendering, un-opinionated (Any UI framework works)

Anything that can be derived from the application state, should be. Automatically. — from MobX documentation

State

Annotated as observable
Properties you want to observe or change over time
Accept any primitive or non-primitive data: objects, arrays, classes, maps, sets etc
Equivalent to useState’s state variable

Action

Annotated as action, runInAction
Function that changes the observable state
Equivalent to useState’s setter function

Derivations

Anything that can be derived from the observable state without any further interaction
They are tracked functions, which will be updated automatically when its corresponding observable state is modified
Equivalent to useEffect (kind of)

There are 2 types of Derivations:

Computed values

Annotated as computed
Value that can be derived from the observable state
Producing variable only

2. Reactions

Annotated as autorun, reaction, when
Side effects that need to happen automatically when the observable state changes
UI re-rendering, HTTP requests, printing consoles

How it works

\"\" — *Data flow presentation from* *MobX documentation*

Uni-directional data flow where:

Actions to trigger the update of the observable state
State updated notifies derivations to be updated
Triggers Derivations

Its optimal performance is due to:

Computed values are updated lazily. Any computed value that is not actively in use will not be updated until it is needed for a side effect (I/O). If a view is no longer in use it will be garbage collected automatically.

MobX file structure in React with functional components

I will be showing an example of setting up an simple price calculator.

The file structure:

\"\" — MobX + functional React setup file structure

First we run yarn add mobx mobx-react-lite in terminal to install MobX in React.

/utils/store/timer-store.ts

import { makeAutoObservable } from \"mobx\"

export class CalculatorStore {

    price = 0

    amount = 1

    constructor() {
        makeAutoObservable(this)
    }

    increasePrice() {
        this.price += 1
    }

    increaseAmount() {
        this.amount += 1
    }

    get total() {
        return this.price * this.amount
    }

}

/utils/store/index.ts

import { CalculatorStore } from \"./calculator-store\";

const calculatorStore = new CalculatorStore()

export { calculatorStore }

Timer.tsx

import { useEffect } from \"react\"
import { autorun } from \"mobx\"
import { observer } from \"mobx-react-lite\"
import { CalculatorStore } from \"../utils/store/calculator-store\"

type CalculatorProps = {
    calculatorStore: CalculatorStore
}

const Calculator = ({calculatorStore}:CalculatorProps) => {

    // Effect that triggers upon observable changes.
    useEffect(() => {
        const disposer = autorun(() => {
            if(calculatorStore.total) console.log(\"the total is updated: \" + calculatorStore.total)
        })
        return () => disposer()
    },[])

    return (
        
            Price: {calculatorStore.price}

            

            Amount: {calculatorStore.amount}

              
      
            Total: {calculatorStore.total}
      
        

    )

}
export default observer(Calculator)

The result:

\"\" — Simple price calculator on browser

That’s it! It is definitely a faster and less boilerplate setup comparing to Redux. Let’s break it down and explain along with the respective MobX API.

APIs

observable & makeObservable

observable defines a trackable field that stores the state
makeObservable make the object passed in become observable
These 2 APIs are used together to provide reactive component with observable states
Equivalent to useState’s state variable

import { makeObservable, observable } from \"mobx\"

export class CalculatorStore {

    price = 0

    amount = 1

    constructor() {
        makeObservable(this, {
            price: observable,
            amount: observable,
        })
    }

}

makeAutoObservable

makeAutoObservable is a shortcut to translate the class fields to MobX instances
It infers all the properties by default, such as:

All own properties become observable
All getters become computed
All setters become action

import { makeAutoObservable } from \"mobx\"

export class CalculatorStore {

    price = 0

    amount = 1

    constructor() {
        makeAutoObservable(this)
    }

    increasePrice() {
        this.price += 1
    }

    increaseAmount() {
        this.amount += 1
    }

    get total() {
        return this.price * this.amount
    }

}

observer

observer is a HoC which can be used to wrap a react component so that it will automatically detect that rendering depends on observable states inside

import { observer } from \"mobx-react-lite\"
import { CalculatorStore } from \"../utils/store/calculator-store\"

type CalculatorProps = {
    calculatorStore: CalculatorStore
}

const Calculator = ({calculatorStore}:CalculatorProps) => {
    return (
        
            Price: {calculatorStore.price}

            

            Amount: {calculatorStore.amount}

              
      
            Total: {calculatorStore.total}
      
        

    )
}
export default observer(Calculator)

action

action is a function which modifies the observable state
You still can update the state without declaring it as action , but it is recommended to do so. With this practice, MobX can automatically apply transactions for effortless optimal performance
When handling promises, the handlers that update state should be actions or should be annotated as action (We will discuss later)
Equivalent to useState’s setter function

export class DateStore {
    date: any

    constructor() {
        makeAutoObservable(this)
        autorun(()=>{
         this.setDate(new Date())
        })
    }

    setDate(date:Date) {
        this.date = date
    }
  
}

runInAction

runInAction creates an one-time action that is immediately invoked
It wraps a function
Most suitable when you just need to update the state once, so you don’t need to create an action separately just to do it once
We have to use runInAction to allow making changes outside of an action

export class DateStore {
    date: any

    constructor() {
        makeAutoObservable(this)
        runInAction(()=>{
            this.date = new Date()
        })
    }

}

⚠️ Handling promises

Separating them in different class fields, as they will be annotated as action by makeAutoObservable automatically

export class TodoStore {

    todos:any

    abortController?: AbortController

    constructor() {
        makeAutoObservable(this)
    }

    abortRequest() {
        if(this.abortController) this.abortController.abort()
    }

    fetchRequest(){
        runInAction(() => {
            this.abortController = new AbortController();
        })
        if(this.abortController){
            const signal = this.abortController.signal
            fetch('',{signal})
             .then(this.fetchSuccess, this.fetchFailure)
        }
    }

    fetchSuccess = todos => {
        this.todos = todos.json()
    }

    fetchFailure = error => {
        if (!this.abortController.signal.aborted) console.log(error)
    }
}

2. Using runInAction

export class TodoStore {

    todos:any

    abortController?: AbortController

    constructor() {
        makeAutoObservable(this)
    }

    abortRequest() {
        if(this.abortController) this.abortController.abort()
    }

    fetchRequest(){
        runInAction(() => {
            this.abortController = new AbortController();
        })
        if(this.abortController){
            const signal = this.abortController.signal
            fetch('',{signal})
             .then(response => response.json())
             .then(result => {
                runInAction(() => {
                  this.todos = result
                })
              })
             .catch(error => {
                 if (!this.abortController.signal.aborted) console.log(error)
              })
        }
    }

}

In the component, fetch it in useEffect() and return the cleanup function abortRequest() when the component unmounts.

useEffect(() => {
    todoStore.fetchRequest()
    return () => todoStore.abortRequest()
},[])

computed

computed is a JS get function that will derive new facts from the state and cache its output (highly optimised)
Only recomputes if one of the underlying observables has changed
No parameters accepted and must return a value

We can use the calculator example earlier but with some changes to explain how computed works.

calculator-store.ts

export class CalculatorStore {

    price = 0

    amount = 1

    constructor() {
        makeAutoObservable(this)
    }

    increasePrice(price:number) {
        this.price += price
    }

    increaseAmount() {
        this.amount += 1
    }

    get total() {
        return this.price * this.amount
    }

}

Calculator.tsx

type CalculatorProps = {
    calculatorStore: CalculatorStore
}

const Calculator = ({calculatorStore}:CalculatorProps) => {

    const [input, setInput] = useState(0)

    // Effect that triggers upon observable changes.
    useEffect(()=>{
        const disposer = autorun(() => {
            if(calculatorStore.total) console.log(\"the total is updated: \" + calculatorStore.total)
        })
        return () => disposer()
    },[])

    return (
        
            Price: {calculatorStore.price}

            setInput(parseInt(e.target.value))}/>
            

            Amount: {calculatorStore.amount}

             

            Total: {calculatorStore.total}
   
        

    )
}
export default observer(Calculator)

Please take note on this part of codes. What it does is to print the statement to console when computed is called. We will explain about autorun later.

useEffect(()=>{
    const disposer = autorun(() => {
        if(calculatorStore.total) console.log(\"the total is updated: \" + calculatorStore.total)
    })
    return () => disposer()
},[])

\"\" — After clicking **Increase Amount** button 5 times

\"\" — After setting 50 in price input and clicking **Increase Price** button

So in short, computed watches the observables underlying. It will only recompute when it is initialised, and when its output is different.

autorun

autorun reads & subscribes the observable state
It runs the first time & every time the observable state underlying changes
It only responds to changes in observable state or things annotated observable or computed
To integrate it in React functional component, we need to make use of useEffect() to initialise it when the component mounts
Equivalent to useEffect with dependency

type CalculatorProps = {
    calculatorStore: CalculatorStore
}

const Calculator = ({calculatorStore}:CalculatorProps) => {

  const [input, setInput] = useState(0)

    // Effect that triggers upon observable changes.
    useEffect(() => {
        const disposer = autorun(() => {
            if(calculatorStore.total) console.log(\"the total is updated: \" + calculatorStore.total)
        })
        return () => disposer()
    },[])

    return (
        
            Price: {calculatorStore.price}

            setInput(parseInt(e.target.value))}/>
            

            Amount: {calculatorStore.amount}

             

            Total: {calculatorStore.total}
   
        

    )
}
export default observer(Calculator)

reaction

It takes two functions as parameters:

Data function: It returns the data that is used as input for the second, effect function
Effect function: Only reacts to data that was accessed in the data function

reaction(
  () => value, 
  (value, previousValue, reaction) => { sideEffect }
  , options?
)

The result of the data function has to change in order for the effect function to be triggered
It works almost like autorun but it don't run when initialised, instead only run after the data function returns a new value for the first time
Like autorun, we also need to make use of useEffect() to initialise it when the component mounts

useEffect(()=>{
  const disposer = reaction(
      () => calculatorStore.total,
      total => {
        if (total > 100) console.log(\"Total exceeds 100\")
        else console.log(\"Total less than 100\")
      }
    )
  return () => disposer()
},[])

when

It takes two functions as parameters as well:

Predicate function: It observes and run until it returns true
Effect function: To be executed when predicate is true

when(predicate: () => boolean, effect?: () => void, options?)
//or...
when(predicate: () => boolean, options?): Promise

It will be disposed automatically when the predicate function returns true and the effect function executed
Really useful for disposing autorun and reaction earlier if you don’t need them anymore instead of waiting until the component unmount

useEffect(() => {

    const disposer = autorun(() => {
        if(calculatorStore.total) console.log(\"the total is updated: \" + calculatorStore.total)
    })

    when(
        () => calculatorStore.total > 100,
        () => disposer()
    )

},[])

⚠️ Tips on autorun, reaction and when

Also always return autorun, reaction orwhen in useEffect(). This ensures that the reaction is only created once, and removed when the component is unmounted.

Assign reactions to disposer, and call them to stop them from waiting

const disposer = autorun(() => {
    ...
})

disposer()

2. Return reactions in useEffect React hook

useEffect(() => {

    const disposer = autorun(() => {
        ...
    })

    return () => disposer()

},[])

3. Implement of when

useEffect(() => {

    const disposer = autorun(() => {
        ...
    })

    when(
        () => yourCondition,
        () => disposer()
    )

},[])

Summary: MobX’s equivalent React hooks and class component

Debugging

trace

calling trace() inside tracked functions like computed and autorun to verify what observables MobX are tracking. The tracing will be printed in the console.

get total() {
    trace()
    return this.price * this.amount
}

// Output: 
// [mobx.trace] 'CalculatorStore@1.total' tracing enabled
// [mobx.trace] 'CalculatorStore@1.total' is invalidated due to a change in: 'CalculatorStore@1.price'

We can trace reaction by using trace() outside of the function:

const disposer = reaction(
...
)
trace(disposer)

Conclusion

$\"\"$ ", "media": {} }, { "id": "https://medium.com/p/6808d9d2c069", "title": "Best practices of HTTP requests using redux-thunk (Redux Toolkit + TypeScript)", "link": "https://tengweiherr.medium.com/async-api-requests-with-redux-toolkit-6808d9d2c069?source=rss-2d2d00a2592a------2", "author": "Wei Herr Teng", "published": 1665158493000, "created": 1665158493000, "category": [ "react", "api", "redux-thunk", "redux", "redux-toolkit" ], "content": "

Examples and explanation on HTTP CRUD requests using createAsyncThunk middleware

Problem Statement

I used to make API calls separately after getting the updated state from the Redux reducer before finding this cleaner way to do it. After doing some research on it and its alternative solutions, I decided to write down the things I have learned. I welcome any comments you may have.

Background: Redux and its usage

Redux is a library for managing global states that can be accessed and updated across the entire React application. Redux makes it easier comparing to traditional React data passing pattern which is passing data as parameters to child components. Redux helps to avoid props drilling (the data is being passed through too much layers) but it is not always the best choice to manage states in our application. In fact, I will only apply Redux on certain states that will be accessed in many layers. I will remain the rest with React useState hook and passing them into child components if they are only needed for 1 or 2 layers. Please check this articles to find out when to use Redux and when not to

Why react-thunk middleware?

Redux only supports synchronous tasks. Redux reducer only focuses on managing states in the application itself, and never contains “side effect” which is task that happens other than changing the state. Sometimes we will need to perform an HTTP request to server to update the database at the same time. To perform this “side effect” task, we will need the help from thunk middleware.

Things that thunk middleware can do:

HTTP requests
Accessing AsyncStorage / AsyncLocalStorage
Async timer

Thunk middleware lies between action dispatched and reducers in the Redux data flow:

Action dispatched — Middleware — Reducer — Store — Component re-renders

Thunk middleware can access the action object dispatched and do something about it before it reaching the reducer.

Solution: Examples and explanation

In this article, we will be looking at the examples on how I design and execute the asynchronous tasks such as HTTP requests using Redux Toolkit and TypeScript. (Redux-thunk is automatically set up in Redux Toolkit’s configureStore function). Before I start, I will assume you are already familiar with React, Redux, Redux Toolkit, TypeScript and how HTTP request and API integration works. I will skip the setup part and dive into the react-thunk functions directly.

We first create a seperate file and write our thunk functions using createAsyncThunk.

createAsyncThunk takes 3 parameters which are action type value(string), payloadCreator callback function and options object. The type will auto-generates pending, fulfilled and rejected action type constants to represent the lifecycle of the async request. The payloadCreator will return the promise return value of the async request. payloadCreator takes optional parameters which are arg any value like userID passing into the function and thunkAPI object containing signal AbortController Signal and rejectWithValue customising your own value when the async request failed. More about createAsyncThunk

2. We then export the thunk functions and include them in our slice using extraReducers. The extraReducers is like our normal reducers but with enhancement. As case reducers specified with extraReducers are meant to reference external actions like API calls, they will not generate action creator function like reducers. More about extraReducers and reducers

Make sure you are using builder callbacks and passing thunk functions to builder.addCase() so it infers action types correctly. But when we add all the cases for each async task, there will be a big chunk of repeated codes. Since we always do the same thing when the async task is pending or rejected, we can group them using builder.addMatcher() so it looks cleaner.

Please make sure that all calls to builder.addCase must come before any calls to builder.addMatcher. In this case, builder.addMatcher will execute the repeated task when each action is pending, fulfilled and rejected respectively, after the specific builder.addcase method. More about builder methods

3. Lastly we import and add our thunks in our components.

Please refer to the redux documentation on how to type the useSelector and useDispatch hooks if you feel confused on the useAppSelector and useAppDispatch.

Alternative async request solutions:

Other middleware like Redux Saga
createListenerMiddleware (able to be removed dynamically in runtime and run callbacks in response to dispatched action)
RTK Query

Alternative state management solutions:

React useState hook (Not available for global state)
React useReducer hook (Good for complex logic but still not available for global state)
React Context API useContext (Avoid this if the global state to apply is complex or changing frequently)

Just an entry-level software engineer’s learning diary :) Please leave a comment if you have better ideas and give a thumbs-up if you find this article helpful!

$\"\"$ ", "enclosures": [], "content_encoded": "

Examples and explanation on HTTP CRUD requests using createAsyncThunk middleware

Problem Statement

Background: Redux and its usage

Why react-thunk middleware?

Things that thunk middleware can do:

HTTP requests
Accessing AsyncStorage / AsyncLocalStorage
Async timer

Thunk middleware lies between action dispatched and reducers in the Redux data flow:

Action dispatched — Middleware — Reducer — Store — Component re-renders

Thunk middleware can access the action object dispatched and do something about it before it reaching the reducer.

Solution: Examples and explanation

We first create a seperate file and write our thunk functions using createAsyncThunk.

3. Lastly we import and add our thunks in our components.

Please refer to the redux documentation on how to type the useSelector and useDispatch hooks if you feel confused on the useAppSelector and useAppDispatch.

Alternative async request solutions:

Other middleware like Redux Saga
createListenerMiddleware (able to be removed dynamically in runtime and run callbacks in response to dispatched action)
RTK Query

Alternative state management solutions:

React useState hook (Not available for global state)
React useReducer hook (Good for complex logic but still not available for global state)
React Context API useContext (Avoid this if the global state to apply is complex or changing frequently)

Just an entry-level software engineer’s learning diary :) Please leave a comment if you have better ideas and give a thumbs-up if you find this article helpful!

$\"\"$ ", "media": {} } ] }

Consuming your feature flags on Firebase remote config through NextJS middleware — with the best performance.

Problems of A/B testing on web

Client-side A/B testing

Server-side A/B testing

What is NextJS middleware?

A/B testing through NextJS middleware and SSG

High level overview

Flow diagram

Result

Further improved: NextJS middleware + SSG + Prefetching

High level overview

Flow diagram

Final result

Disadvantages

Limitation of NextJS Middleware

Other use cases

Conclusion

Resources

Try it out on your own

File structure

Code examples

Variant A

Consuming your feature flags on Firebase remote config through NextJS middleware — with the best performance.

Problems of A/B testing on web

Client-side A/B testing

Server-side A/B testing

What is NextJS middleware?

A/B testing through NextJS middleware and SSG

High level overview

Flow diagram

Result

Further improved: NextJS middleware + SSG + Prefetching

High level overview

Flow diagram

Final result

Disadvantages

Limitation of NextJS Middleware

Other use cases

Conclusion

Resources

Try it out on your own

File structure

Code examples

Variant A

MobX with React functional components setup — better than Redux?

Recommended MobX setup with React functional components

Table of contents

Background

Core concept

State

Action

Derivations

How it works

MobX file structure in React with functional components

APIs

observable & makeObservable

makeAutoObservable

observer

action

runInAction

⚠️ Handling promises

computed

autorun

reaction

when

⚠️ Tips on autorun, reaction and when

Summary: MobX’s equivalent React hooks and class component

Debugging

trace

Conclusion

MobX with React functional components setup — better than Redux?

Recommended MobX setup with React functional components

Table of contents

Background

Core concept

State

Action

Derivations

How it works

MobX file structure in React with functional components

My tech blog

Where I document what I've learn and share them to others.