DEV Community: Muhamad Ilyas Mustafa

Understanding the "Infer" Keyword in String Literal Types

Muhamad Ilyas Mustafa — Sun, 07 Jan 2024 03:26:28 +0000

When working with string literal types in TypeScript, the use of the infer keyword can lead to some intriguing behaviors. Let's delve into an example to explore its nuances:

type Test<T> = T extends `${infer A}${infer B}${infer C}`
  ? `${A}-${B}-${C}`
  : never;
type Test1 = Test<"a">; // never
type Test2 = Test<"ab">; // a-b-
type Test3 = Test<"abcd">; // a-b-cd

Observations:

The first result is never because the string literal type is only one character long, and our type requires at least three characters.
The second result, a-b-, may seem unexpected. The infer keyword is greedy, attempting to match as many characters as possible. In this case, it matches a to A, b to B, and the remaining empty string to C. As we can only have one empty string in the template literal type, the result is a-b-. This behavior becomes clearer with a four-character example:

type Test4Char<T> = T extends `${infer A}${infer B}${infer C}${infer D}`
  ? `${A}-${B}-${C}-${D}`
  : never;
type Test1 = Test4Char<"a">; // never (B, C, and D are empty strings, and only one is allowed)
type Test2 = Test4Char<"ab">; // never (C & D are empty strings, and only one is allowed)
type Test3 = Test4Char<"abc">; // a-b-c- (D is empty string)
type Test4 = Test4Char<"abcd">; // a-b-c-d

The third result, a-b-cd, demonstrates that C matches cd, storing the remaining string in C.

With this understanding, let's leverage this knowledge to create some intriguing types:

// Get the last character of a string
type LastChar<T extends string> = T extends `${infer A}${infer Last}`
  ? Last extends ""
    ? A
    : LastChar<Last>
  : never;
type TestL1 = LastChar<"abcd">; // 'd'

// Reverse a string
type Reverse<T extends string> = T extends `${infer A}${infer B}`
  ? `${Reverse<B>}${A}`
  : T;
type TestR1 = Reverse<"reverse">; // esrever

// Convert camel case to kebab case
type CamelToKebab<T> = T extends `${infer A}${infer B}`
  ? `${A extends Capitalize<A> ? `-${Lowercase<A>}` : A}${CamelToKebab<B>}`
  : T;

type TestC1 = CamelToKebab<"fooBarBaz">; // foo-bar-baz
type TestC2 = CamelToKebab<"fooBar">; // foo-bar
type TestC3 = CamelToKebab<"foo">; // foo

That's all for now. Happy typing!

Brief Explanation of Javascript Module Bundler

Muhamad Ilyas Mustafa — Tue, 25 Jul 2023 03:25:14 +0000

The Javascript ecosystem is a wild-wild world. Every time humans breathe, a javascript library is released to the world. Of course, this is an exaggeration, but you can almost literally type random English words and add “JS” behind them, most likely You will find a javascript library with that term. That shows how popular Javascript is.

On the one hand, this means Javascript has a vast ecosystem. Every problem that you face, you can easily find the answer, or at least you can ask easily. But on the other hand, it is so huge, that no mortal can understand all of them. This is becoming a huge headache especially when you are comparing similar libraries.

This also applies to Javascript Module Bundler, as so many bundlers out there, with their own configuration, with their own term. Not many of us touch bundler configuration regularly (including me), and it can be quite intimidating to set up your own bundle configuration from scratch. Here is my brief understanding of the Javascript Module Bundler.

What is Module Bundler

The art of modular programming is splitting your application code into small independent interchangeable units called modules. It is extremely useful, by following this paradigm, as the codebase grows, we can just create separate functions, and/or files rather than adding more lines of code into an already crowded file.

Take a look at the code below



<html>
    <head></head>
    <body>
        <script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.7.0/jquery.min.js" integrity="sha512-3gJwYpMe3QewGELv8k/BX9vcqhryRdzRMxVfq6ngyWXwo03GFEzjsUm8Q7RZcHPHksttq7/GFoxjCVUjkjvPdw==" crossorigin="anonymous" referrerpolicy="no-referrer"></script>
        <script type="text/javascript" src="./components/a.js"></script>
        <script type="text/javascript" src="./components/b.js"></script>
        <script type="text/javascript" src="./main.js"></script>

    </body>
</html>

In the past, it is really painful to manage projects. As you can see above, when we want to add a new file, we also need to update the HTML script. This also applies when we want to update the dependency, remove files, etc. We also have to be mindful about many things (i.e. the order of the script, naming collision), and as the code grows bigger, it becomes tedious to manage all of this. This is one of the cases in which a module bundler might be helpful.

Module bundler is a development tool that processes your code into one bundle of code. It traverses your code from the provided entry point(s), builds a dependency graph, and produces the output files based on the configuration. So essentially just transform your application code into another form.

There are at least two processes involved which are dependency resolution and packing. Dependency resolution is a process to create a relationship graph between each module/file called a dependency graph. The dependency graph is useful to identify the module retrieval order and to eliminate unreachable modules/files. Packing is a process of bundling everything based on the created dependency graph and the specified configuration into something that is executable by the browser. In the above case, out of all files in the above codebase, the module bundler produces only one file. And then later we can just insert main.js into the HTML.



<html>
    <head></head>
    <body>
        <script type="text/javascript" src="./main.js"></script>
    </body>
</html>

One of the questions that might come to mind after seeing the above codes is “How do we debug this code in the browser if all the codes merged into one?”. The answer is a source map. A source map is a type of file that can help tools (i.e. browser) to reconstruct a minified code. Along with the executable code, a module bundler can also produce a source map. With a source map, we can debug the code in the browser like the code's original structure. Of course, we can disable it, if we don’t want our user to be able to read our code.

Things to pay attention

As we discussed earlier, Javascript has a lot of module bundlers. Each module bundler has its own unique configuration and terms. But they have a pattern and here are several configurations that you need to pay attention to.

Entry Point(s)

The entry point(s) indicates where the bundler should start traversing your code to create a dependency graph. You can specify one or multiple entry points. This is extremely useful when you are building a library, for example, a component library, as it doesn’t have a specific entry point.



// webpack.config.js

module.exports = {

  entry: './path/to/my/entry/file.js',

};

// rollup.config.js

export default {

  input: {

    a: 'src/main-a.js',

    'b/index': 'src/main-b.js'

  }

};

Output

Output specifies where and how the bundled code should be placed after being processed. Naming, file splitting, and format are some examples that can be determined here.



// webpack.config.js

module.exports = {

    ...

  output: {

    path: path.resolve(__dirname, 'dist'),

    filename: 'my-first-webpack.bundle.js',

  },

};

// rollup.config.js

...

export default {

    ...,

    output: [

        {

            file: 'bundle.js',

            format: 'es'

        },

        {

            file: 'bundle.min.js',

            format: 'es',

            plugins: [terser()]

        }

    ]

};

Plugin System

The great thing about module bundlers is a plugin system. A module bundler's main function is just well bundling. If we want to have some advanced functionality like a dev server, transform SCSS into CSS, polyfill new javascript functionality, uglifying code, etc., we need to add that functionality by inserting the appropriate plugin into the module bundler’s plugin system.



// webpack.config.js

...

module.exports = {

  ...,

  module: {

    rules: [

      {

        test: /.(js|jsx)$/,

        use: 'babel-loader',

      },

    ],

  },

  plugins: [

    new webpack.ProgressPlugin(),

    new HtmlWebpackPlugin({ template: './src/index.html' }),

  ],

};

// rollup.config.js

...

export default {

  ...,

  plugins: [graphql()]

};

Quirk

Anything else is bundle-specific and advances features. Some bundlers are very opinionated (i.e. parcel, vite), and the others are like a blank canvas, you need to configure it yourselves (i.e. webpack). The best way to learn this is to read the official documentation.

Closing Thoughts

Nowadays, module bundler is very essential for application development. Understanding basic behavior is encouraged, but no need to understand everything. Of course, it is good to understand deeply, but for starters, just start coding and ask along the way.

If you have any comments or feedback, feel free to leave a comment below. Will be happy to discuss this with you all. Cheers!

Creating Undo-Redo System Using Command Pattern in React

Muhamad Ilyas Mustafa — Tue, 18 Jul 2023 04:45:27 +0000

Supposed you want to learn React by following React's official documentation. And then you come across the Tic Tac Toe tutorial, you find it interesting and then you want to add some functionality to put it into your portfolio. (btw, If you haven't done it, please do it first, it is a good exercise for learning state management)

One of your ideas may be to add an undo-redo system. The first intuition is just to save all of the states as snapshots and add a pointer so that you can easily go back and forth between snapshots.

As you can see above, we have a history variable that contains the history of the application's states and we also have currentMove to track which application state we are currently in.

This is an okayish approach in this case because of the small scope. Unfortunately, this approach doesn't scale well. Imagine you are building a Photoshop, it is not feasible to save all of the states' snapshots as it might cause memory overhead. This is one of the cases that the Command Pattern comes in handy.

Command Pattern

The command pattern is a design pattern in object-oriented programming that enables an application to perform an action by encapsulating the necessary information to do the action in the form of an object. Encapsulating the necessary information enables an application to trigger an action whenever they want.

The Command Pattern consists of three main components: the invoker, the receiver, and the command. The invoker is responsible for invoking the command and is often triggered by a user action. The receiver is the controller of the action that will ultimately perform the action specified by the command. The command itself encapsulates the action to be taken, along with any necessary information.

To learn more about this pattern you can read here and here.

Exploring Command Pattern by Creating Simple Undo-Redo Functionality

In this section, we will focus on building a simple text formatter as you can see below.

The styling of the text in the middle can be changed by clicking the action buttons below. The 3 main style modifiers are bold, italic, and underline. The other two buttons are for undo-redo the style changes.

To implement this using the command pattern, we need to create a base class for the command.

export abstract class Command<T> {
  utils: T;
  constructor(utils: T) {
    this.utils = utils;
  }
  abstract execute(): void;
  abstract undo(): void;
  abstract getInfo(): string;
}

This base command list all of the method that must be implemented by each command. If we wanted the command to be applied, then we need to trigger execute. We can also revert the action by calling undo. And to make it more intuitive, we can also show the command information by calling getInfo. As for utils, it is used to interact with the outer world.

Let's try implementing bold command.

export interface CommandUtils {
  styles: CSSProperties;
  setStyles: Dispatch<React.SetStateAction<CSSProperties>>;
}

export class BoldCommand<T extends CommandUtils> extends Command<T> {
  prevFontWeight?: CSSProperties["fontWeight"];
  constructor(utils: T) {
    super(utils);
    this.prevFontWeight = utils.styles.fontWeight;
  }

  getNextStyle() {
    if (
      this.prevFontWeight === "bold" ||
      (typeof this.prevFontWeight === "number" && this.prevFontWeight >= 700)
    ) {
      return "normal";
    }
    return "bold";
  }

  execute() {
    const nextFontStyle = this.getNextStyle();
    this.utils.setStyles((prevStyles) => ({
      ...prevStyles,
      fontWeight: nextFontStyle,
    }));
  }

  undo() {
    this.utils.setStyles((prevStyles) => ({
      ...prevStyles,
      fontWeight: this.prevFontWeight,
    }));
  }

  getInfo() {
    return "Bold Command : Change into " + this.getNextStyle();
  }
}

As you can see, it is pretty straight forward. When we instantiate the BoldCommand, we store the previous state. And if we decided to execute the command, we call getNextStyle to get the next style and apply it to the "outer" world by calling setStyles from utils. To revert the changes, we just need to call undo to apply previous stored state into the current styling.

The ItalicCommand and UnderlineCommand are quite similar with the code above. You can see it here or you can do it yourselves as an exercise.

The next that we need is the "receiver", the one that manage the action. In React, we can implement this in many way, but in this article, we will create a custom hook as you can see below

function useHistoryManager<T>() {
  const [forwardHistory, setForwardHistory] = useState<Command<T>[]>([]);
  const [backHistory, setBackHistory] = useState<Command<T>[]>([]);

  const executeCommand = async (command: Command<T>) => {
    // clear forward history
    setForwardHistory([]);
    await command.execute();
    setBackHistory((prev) => [...prev, command]);
  };
  const redo = async () => {
    if (!forwardHistory.length) return;
    const topRedoCommand = forwardHistory[forwardHistory.length - 1];
    await topRedoCommand.execute();
    setForwardHistory((prev) => prev.slice(0, -1));
    setBackHistory((prev) => [...prev, topRedoCommand]);
  };
  const undo = async () => {
    if (!backHistory.length) return;
    const topUndoCommand = backHistory[backHistory.length - 1];
    await topUndoCommand.undo();
    setBackHistory((prev) => prev.slice(0, -1));
    setForwardHistory((prev) => [...prev, topUndoCommand]);
  };

  const histories = useMemo(() => {
    const formattedBackHistory = backHistory.map((command, index) => ({
      type: "undo",
      command,
      message: command.getInfo(),
    }));
    const formattedForwardHistory = [...forwardHistory]
      .reverse()
      .map((command, index) => ({
        type: "redo",
        command,
        message: command.getInfo(),
      }));
    return [...formattedBackHistory, ...formattedForwardHistory];
  }, [backHistory.length, forwardHistory.length]);

  return {
    executeCommand,
    redo,
    undo,
    histories,
  };
}

useHistoryManager manages actions by storing action commands into two places, forwardHistory and backHistory. backHistory stores all of the actions that have already been done. forwardHistory stores all of the actions that could be done. If we want to introduce new action, we need to call it using executeCommand.

The last thing that we need to set up is the "invoker". To do this, we can just call our custom context and execute the command based on the API that we already made.

export default function App() {
  const [styles, setStyles] = useState<CSSProperties>({});
  const utils = { styles, setStyles };
  const { executeCommand, redo, undo, histories } =
    useHistoryManager<CommandUtils>();

  const setTextToItalic = async () => {
    const italicCommand = new ItalicCommand(utils);
    await executeCommand(italicCommand);
  };

  const setTextToBold = async () => {
    const boldCommand = new BoldCommand(utils);
    await executeCommand(boldCommand);
  };

  const setTextToUnderline = async () => {
    const underlineCommand = new UnderlineCommand(utils);
    await executeCommand(underlineCommand);
  };

  return (
    <div className={appStyles.container}>
      <div className={appStyles.editor}>
        <p className={appStyles.mainText} style={styles}>
          Hello from react!
        </p>
        <div className={appStyles.actions}>
          <button
            className={appStyles.button}
            onClick={setTextToItalic}
            title="italic"
          >
            <img src="/assets/format_italic.svg" alt="italic" />
          </button>
          <button
            className={appStyles.button}
            onClick={setTextToBold}
            title="bold"
          >
            <img src="/assets/format_bold.svg" alt="bold" />
          </button>
          <button
            className={appStyles.button}
            onClick={setTextToUnderline}
            title="underline"
          >
            <img src="/assets/format_underline.svg" alt="underline" />
          </button>
          <button className={appStyles.button} onClick={undo} title="undo">
            <img src="/assets/undo.svg" alt="undo" />
          </button>
          <button className={appStyles.button} onClick={redo} title="redo">
            <img src="/assets/redo.svg" alt="redo" />
          </button>
        </div>
      </div>
      <div className={appStyles.history}>
        <h2 className={appStyles.historyHeader}>History</h2>
        <ol className={appStyles.historyContent}>
          <li className={`${appStyles.historyItem}`}>
            <button>Initial</button>
          </li>
          {histories.map((history, index) => (
            <li
              className={`${appStyles.historyItem} ${
                history.type === "undo" ? appStyles.undo : appStyles.redo
              }`}
              key={index + history.type + history.message}
            >
              <button>{history.message}</button>
            </li>
          ))}
        </ol>
      </div>
    </div>
  );
}

Hooray!, we can create undo-redo using the command pattern. If you want to see this live in action, click here.

Conclusion

With the command pattern, we can simplify action information into a series of objects that can be triggered at a convenient time. But the usage of command pattern is very limited, as this pattern requires a lot of boilerplates that in many cases we don't necessarily need them.

All of the codes above can be found on this repository. If you have any comments or feedback, feel free to leave a comment below. Will be happy to discuss this with you all. Cheers!