Forem: David Kohen

Decision Tables in TypeScript: An Underrated Pattern for Cleaner Code

David Kohen — Fri, 06 Sep 2024 12:47:23 +0000

When building complex software systems, developers often resort to lengthy if-else or switch statements to handle decision-making logic.

While these approaches can work, they quickly become unmanageable as the number of conditions grows. This is where decision tables come in.

A powerful yet underused pattern that simplifies complex decision-making in a clean, maintainable fashion.

In this article, we'll explore what decision tables are, why you should use them, and how to implement them in TypeScript to handle complex logic with ease.

What is a decision table?

A decision table is a structured way to map various combinations of input conditions to corresponding actions or outcomes. Think of it as a table where each row represents a unique combination of input variables, and the corresponding column defines the output or action. This allows you to visualize all possible scenarios in one place, making it easier to manage and understand.

For example, let's say you're building an e-commerce platform and need to send different email templates to users based on their customer status, purchase history, available promotions, and preferred language.

With 3 boolean variables (isGoldCustomer, isFirstPurchase, isPromoAvailable) and one enum variable (emailLanguage), there are 24 possible combinations to handle.

But instead of writing 24 if-else or switch cases, a decision table provides a cleaner solution.

Why Use Decision Tables?

Decision tables offer several advantages over traditional conditional logic:

Improved Readability: A single table captures all possible combinations, making it easier to understand at a glance.
Easier Maintenance: Modifying logic becomes as simple as updating a single row in the table rather than combing through lines of nested conditions.
Scalability: Decision tables can handle more complex decision-making scenarios without becoming unmanageable.

Let's dive into how to implement a decision table in TypeScript.

How to implement a decision table in TypeScript

The easiest way to implement a decision table in TypeScript is to use an array of objects. Each object represents a row in the decision table.
Then you can use the array's find method to find the row that matches the input variables and return the corresponding output value.

type TEmailLanguage = 'en' | 'es' | 'fr';

interface IDecisionTableRow {
  //These are the input values that determine the output value
  isGoldCustomer: boolean;
  isFirstPurchase: boolean;
  isPromoAvailable: boolean;
  emailLanguage: TEmailLanguage;

  // The last property is the output value
  template: string;
};

const DECISION_TABLE: IDecisionTableRow[] = [
  {
    isGoldCustomer: true,
    isFirstPurchase: true,
    isPromoAvailable: true,
    emailLanguage: 'en',
    template: 'welcome_en.html',
  },
  {
    isGoldCustomer: true,
    isFirstPurchase: true,
    isPromoAvailable: true,
    emailLanguage: 'es',
    template: 'welcome_es.html',
  },
  {
    isGoldCustomer: true,
    isFirstPurchase: true,
    isPromoAvailable: true,
    emailLanguage: 'fr',
    template: 'welcome_fr.html',
  },
  // more rows...
];

const getTemplate = (
  isGoldCustomer: boolean,
  isFirstPurchase: boolean,
  isPromoAvailable: boolean,
  emailLanguage: EmailLanguage
): string => {
  const row = decisionTable.find(
    (row) =>
      row.emailLanguage === emailLanguage &&
      row.isGoldCustomer === isGoldCustomer &&
      row.isFirstPurchase === isFirstPurchase &&
      row.isPromoAvailable === isPromoAvailable 
  );

  if (!row) {
    throw new Error('No matching row in decision table');
  }

  return row.template;
};

In this example, we have an array of objects called DECISION_TABLE that represents the decision table.
Each object has 4 properties that represent the input variables and 1 property that represents the output value.

The getTemplate function takes the input variables as arguments and uses the find method to find the row in the decision table that matches the input variables.

If no row is found, the function throws an error.

And that's it! You now have a clean, maintainable way to handle complex logic that depends on multiple input variables.

Additional Considerations

Rule Prioritization: If multiple rules match the input conditions, you may need to define a priority mechanism to determine the correct output.
Default Values: Consider providing a default output in case no matching rule is found.
Data Validation: Implement validation to ensure that input values are valid and within expected ranges.

Conclusion

Decision tables offer a powerful and effective approach to managing complex decision-making logic in TypeScript. By providing a clear and structured representation of rules, they enhance code readability, maintainability, and scalability. By adopting decision tables in your projects, you can improve the overall quality and efficiency of your codebase.

So next time you find yourself writing a bunch of if-else statements or switch statements to handle a complex logic, consider using a decision table instead.

Happy coding!

Implementing useEffect from scratch | Exploring React in Depth

David Kohen — Wed, 03 Jan 2024 07:50:52 +0000

Whether we like it or not, React is one of the most popular JavaScript frameworks around.

And it plays a significant role in the everyday lives of many front-end web developers.

And being as popular as it is, you can imagine how many job positions require advanced knowledge of React and how it works.

Today we are going to be taking a look at how to implement one of React's most commonly used hooks, the useEffect hook from scratch.

Fair warning, this tutorial is only for people who are already familiar with React and how its basic elements behave.

Understanding the task at hand

To implement our own useEffect hook, we are going to need to take a look at all of the features that the real useEffect has and tackle them one by one.

And these are the features that we need to implement:

A basic custom hook that accepts 2 arguments.

The first argument is an effect callback that accepts no arguments and returns either void or a cleanup function.

The second argument is the optional array of dependencies.

The effect callback is always called on the first render.

If the dependency array isn't provided, then the callback is triggered on all renders.

If a dependency array is provided, then the effect callback is only called when one or more of the dependencies change.

Finally, if a cleanup function is returned by the effect callback, it is called when the dependencies change before calling the effect callback and when the component unmounts.

This may sound like a lot, but practically it boils down to a few lines of code.

The only part that we cannot implement is calling the cleanup function when the component unmounts since React uses its internal engine to keep track of when components unmount and we don't have access to those internal methods.

Getting started

Let's prepare the basic types and the hook function signature using TypeScript:

type TCleanupCallback = () => void;
type TEffectCallback = () => TCleanupCallback | void;
type TDependencyList = readonly unknown[];

const useCustomEffect = (
  effect: TEffectCallback,
  deps?: TDependencyList
): void => {};

As you can see, we have defined the types for the effect callback, the cleanup callback, and the dependency list.

Now let's start with the first feature, calling the effect callback on the first render.

We need a flag to keep track of whether or not the component has been rendered for the first time.

We could use the useState hook to keep track of our flag, but that wil cause a re-render of the component when the flag is updated and that's not what we want so we need a different solution.

Luckily, in React we can use the useRef hook to keep track of values between renders without causing a re-render when the ref is updated, so let's use that:

const useCustomEffect = (
  effect: TEffectCallback,
  deps?: TDependencyList
): void => {
  const isFirstRender = useRef(true);

  if (isFirstRender.current) {
    isFirstRender.current = false;
    effect();
    return;
  }
};

It's a good start, but we still have a long way to go.

Let's move on to the next feature, calling the effect callback on all renders if no dependency array is provided.

if (!deps) {
  effect();
  return;
}

This is a pretty straightforward check, if there are no dependencies, we call the effect callback and return.

Now the next feature is a bit more complicated, we need to call the effect callback only when one or more of the dependencies change.

This means that we need to keep track of the previous dependencies and compare them to the current dependencies.

const checkDependenciesChanged = (
  prevDeps: TDependencyList,
  deps: TDependencyList
): boolean => {
  if (prevDeps.length !== deps.length) {
    console.warn(
      "The length of the dependencies array must remain constistent between renders."
    );
  }

  return deps.some((dep, index) => {
    return !Object.is(dep, prevDeps[index]);
  });
};

const useCustomEffect = (
  effect: TEffectCallback,
  deps?: TDependencyList
): void => {
  const prevDeps = useRef(deps);
  const isFirstRender = useRef(true);

  if (isFirstRender.current) {
    isFirstRender.current = false;
    effect();
    return;
  }

  if (!deps) {
    effect();
    return;
  }

  const isDepsChanged = checkDependenciesChanged(prevDeps.current!, deps);

  if (isDepsChanged) {
    effect();
  }

  prevDeps.current = deps;
};

export default useCustomEffect;

As you can see, we have added a helper function that checks if the dependencies have changed and a ref to keep track of the previous dependencies.

Similar to the real useEffect hook, we log a warning if the length of the dependency array changes.

And we also use the Object.is function to compare the dependencies like the original useEffect hook to efficiently compare the dependencies whether they are primitive types or reference types.

Now we can check if the dependencies have changed and call the effect callback if they have.

The last feature that we need to implement is calling the cleanup function when the dependencies change, but before calling the effect callback.

This means that we need to store the cleanup callback from the previous render and call it before the effect if the dependencies change.

So let's put it all together and look at the finished result.

const useCustomEffect = (
  effect: TEffectCallback,
  deps?: TDependencyList
): void => {
  const prevDeps = useRef(deps);
  const isFirstRender = useRef(true);
  const cleanup = useRef<TCleanupCallback | null>(null);

  if (isFirstRender.current) {
    isFirstRender.current = false;
    cleanup.current = effect() || null;
    return;
  }

  if (!deps) {
    cleanup.current?.();
    cleanup.current = effect();
    return;
  }

  const isDepsChanged = checkDependenciesChanged(prevDeps.current!, deps);

  if (isDepsChanged) {
    cleanup.current?.();
    cleanup.current = effect() || null;
  }

  prevDeps.current = deps;
};

And just like that, we have created our very own useEffect hook.

I hope that this tutorial helps you understand how React and its ecosystem work.

As always, any suggestions or feedback would be highly appreciated.

Until next time...

Signals In React | Catching up with the latest trends

David Kohen — Sat, 23 Dec 2023 18:19:34 +0000

It's intriguing to see that almost every JavaScript client framework has now implemented signals.

A pattern that was once deemed old and primitive has become the flagship feature of so many frameworks.

But it seems that the React team is still against the idea as they:
"don’t think it’s a great way to write UI code" as mentioned here:
// Detect dark theme var iframe = document.getElementById('tweet-1626590880126889984-505'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1626590880126889984&theme=dark" }

But this doesn't mean all hope is lost.
After exploring the @preact/signals-react package I've found that there are some incredible possibilities when it comes to using signals in React.

All of the drawbacks of using React state are gone!!

No more prop drilling or prev-callbacks and it even allows direct mutation of the signal value.

Unfortunately, though, that library doesn't integrate well with React's state-based ecosystem and even somehow managed to break React's internal rendering queues("Which I discovered a bit too late").

So I thought that I might have a go at building a signal-based state manager for React.

So after tons of experimentation and testing, I think it is finally ready to be shared.

Here is a very basic example:

import { createSignal } from 'react-use-signals';

export const counterSignal = createSignal(0);

export const handleIncrement = () => {
  counterSignal.value += 1;
};

const Counter = () => {
  const count = counterSignal.useStateAdapter();

  return (
    <div>
      <p>Count: {count.value}</p>
      <button onClick={handleIncrement}>Increment</button>
    </div>
  );
};

And there are plenty more where that came from!!

There are more examples of how to use signals as a store, optimized rendering, selectors, and more.

Feel free to check it out on NPM:
https://www.npmjs.com/package/react-use-signals

And if you're looking for a detailed article on how they work:
https://medium.com/@personal.david.kohen/the-quest-for-signals-in-react-usestate-on-steroids-71eb9fc87c14

Any suggestions or feedback would be highly appreciated.