DEV Community: Oğuzhan Olguncu

I present you HackerDigest: TLDR Version of HackerNews

Oğuzhan Olguncu — Thu, 16 Nov 2023 12:34:49 +0000

Hey Devto!

I'm excited to share a side project I've been working on: an app that automatically summarizes recent popular stories from Hacker News using the power of OpenAI and Upstash Redis/Qstash.

Are you ever too lazy to read through an entire story, but still want to grasp the main points? That's where my summarizer comes in. It extracts the heart of the story without losing context, providing you with quick insights into the latest and most discussed topics on Hacker News.

Key Features:
Utilizes OpenAI for intelligent and context-aware summarization.
Scheduled updates every 6 hours to fetch the best articles.
Uses Upstash Redis/Qstash for data storage and queue.

Link to app: https://hackerdigest.upstash.app/
Link to repo: https://github.com/upstash/hackerdigest

Tidying up getServerSideProps(Server-Side Rendering) with Higher Order Functions

Oğuzhan Olguncu — Thu, 20 Oct 2022 20:32:19 +0000

We've all been there; once our project gets bigger, getServerSideProps starts to become a pain in the ass to manage. Because we have to deal with caching, data-fetching, auth checks, and data formatting to decrease the complexity of the client.
The size of the getServerSideProps gets considerably big.

When this happens, it reduces Developer Experience(DX) highly; for that reason, developers need to hop around to find the code they want.
You might have heard something like this when you first saw a big getServerSideProps - "Where the hell is the cache headers" or "Where do we do the auth checks".

Now, you might be thinking - These are all pretty easy to dodge if you just extract some code into meaningful functions.
And you are right. It is possible to do that, but they will make your getServerSideProps very dense and verbose.

Let's take a closer look at code here:

export async function getServerSideProps({ req, res }) {
  const userIsAuthenticated = req.auth.user.id;
  if (!userIsAuthenticated) {
    return {
      redirect: {
        permanent: false,
        destination: '/world-without-cookie',
      },
    };
  }

  /*
    Big logging section
    */

  /*
    Check if the data available in redis or memcache
    */

  /*
    If not get data from Db
    */

  /*
    Format data for the client
    */

  res.setHeader('Cache-Control', 'public, s-maxage=10, stale-while-revalidate=59');

  return {
    props: {
      time: new Date().toISOString(),
    },
  };
}

We can turn this into this:

export async function getServerSideProps({ req, res }) {
  bounceUsers(req);
  logStuff(req);
  const cacheData = getCacheData(req);
  const dbData = getDataFromDb();
  const formatData = formatDataForClient(cacheData, dbData);

  res.setHeader('Cache-Control', 'public, s-maxage=10, stale-while-revalidate=59');

  return {
    props: {
      data: formatData,
    },
  };
}

I would pick the latter in this case. But there is always room for improvement. We can still increase the readability of our code by separating it into individual higher-order functions.
Therefore, functions will be aware of only the parts they require, and developers won't have to hop around to spot the code and will be able to locate the chunk of code they need in a blink of an eye.

Let's refactor our code into a more functional way:

type Options = {
  kickUser: boolean;
};

type InjectedProps = {
  userLocation: string;
};

type GetServerSidePropsWithInjectedProps = GetServerSidePropsContext & InjectedProps;

type Callback = (
  context: GetServerSidePropsWithInjectedProps,
) => Promise<GetServerSidePropsResult<any>>;

If you are working with Typescript, you first need to add a couple of types to make it work with TS. Don't worry about InjectedProps and Options, for now, will get there in a moment.

export async function getServerSideProps({ req, res }) {
  const userIsAuthenticated = req.auth.user.id;
  if (!userIsAuthenticated) {
    return {
      redirect: {
        permanent: false,
        destination: '/world-without-cookie',
      },
    };
  }

  return {
    props: {
      time: new Date().toISOString(),
    },
  };
}

Let's first turn this into a Higher Order Function.

export const bounceUsersIfCredentialsHaveNotMet = (cb: Callback, options?: Options) => {
  return async (ctx: GetServerSidePropsWithInjectedProps) => {
    const userIsAuthenticated = ctx.req.auth.user.id;

    if (options?.kickUser && userIsAuthenticated) {
      return {
        redirect: {
          permanent: false,
          destination: '/world-without-cookie',
        },
      };
    }

    const getUserLocation = await magicalLocationFinderFunction();
    const injectedContext = {
      ...ctx,
      userLocation: getUserLocation(),
    };
    return cb?.(injectedContext) || {};
  };
};

const getServerSideHomeProps = async (context: GetServerSidePropsWithInjectedProps) => {
  return {
    props: {
      message:
        'Me cookie monster. That all there is to it. Me love to eat cookie. Sometimes eat whole, sometimes me chew it.',
    },
  };
};

export const getServerSideProps = bounceUsersIfCredentialsHaveNotMet(getServerSideHomeProps, {
  kickUser: false,
});

If you are familiar with the concept of Higher Order Functions(HOC), that shouldn't look so strange to you. In the essence all we did was to wrap our getServerSideHomeProps with bounceUsersIfCredentialsHaveNotMet.

So when we get a request, we'll first check if the user is authenticated in the way we wanted; if so, we'll check the argument we've passed kickUser. Then, if all the conditions are met, we will let the user move into the getServerSideHomeProps and pass a message to the client. And we also injected additional info into our context to see users' locations. We can easily enrich our context with this method.

Let's configure cache headers and data fetching.

type Options = Partial<{
  kickUser: boolean;
  cacheMaxAge: number;
}>;

export const bounceUsersIfCredentialsHaveNotMet = (cb: Callback, options?: Options) => {
  return async (ctx: GetServerSidePropsWithInjectedProps) => {
    const userIsAuthenticated = ctx.req.auth.user.id;

    if (options?.kickUser && !userIsAuthenticated) {
      return {
        redirect: {
          permanent: false,
          destination: '/world-without-cookie',
        },
      };
    }

    const getUserLocation = await magicalLocationFinderFunction();
    const injectedContext = {
      ...ctx,
      userLocation: getUserLocation(),
    };
    return cb?.(injectedContext) || {};
  };
};

export const setCacheHeaders = (cb: Callback, options?: Options) => {
  return async (ctx: GetServerSidePropsWithInjectedProps) => {
    ctx.res.setHeader(
      'Cache-Control',
      `public, s-maxage=${options?.cacheMaxAge}, stale-while-revalidate=59`,
    );
    return cb?.(ctx) || {};
  };
};

export const fetchData = (cb: Callback, options?: Options) => {
  return async (ctx: GetServerSidePropsWithInjectedProps) => {
    const formattedData = await getDataFromDbOrCache();
    const injectedContext = {
      ...ctx,
      formattedData,
    };
    return cb?.(injectedContext) || {};
  };
};

const getServerSideHomeProps = async (context: GetServerSidePropsWithInjectedProps) => {
  const formattedData = context.formattedData;
  return {
    props: {
      message:
        formattedData ??
        'Me cookie monster. That all there is to it. Me love to eat cookie. Sometimes eat whole, sometimes me chew it.',
    },
  };
};

export const getServerSideProps = bounceUsersIfCredentialsHaveNotMet(
  setCacheHeaders(fetchData(getServerSideHomeProps), { cacheMaxAge: 1000 }),
  {
    kickUser: false,
  },
);

As you can see this pattern can easily scale with your needs. And, through this pattern we can easily evade bloated getServerSideHomeProps.

Pros of this pattern

Can easily scale
Atomic
More declarative than regular getServerSideProps
Easier to debug
Wrappers can be easily reused

Cons of this pattern

Might be hard to understand at the first look

The pros outweigh the cons. But, still, if your needs are not as sophisticated as these, don't bother to implement this pattern into every single SSR function. Don't forget to keep it simple.

🔗Project's Gist address

You can actually mutate imports in Javascript

Oğuzhan Olguncu — Fri, 15 Jul 2022 14:25:49 +0000

Recently, I've realized that you can mutate imported objects in Javascript. Interesting right? I've always thought imported objects give us fresh copies each time they are requested/accessed - apparently not.

And mutation not only impacts the file you requested the import, but mutation also happens in all the files that particular import is being used.

E.g, you cannot expect to have the same outcome when you import a file catList and mutate it in file catListPopper, then, import the catList in the catListLooker. Because, now both catList and catListLooker share the mutated import - same reference.

Let's elaborate.

You can imagine this diagram as a backend application. An API endpoint imports an object and mutates it, then, maybe returns a JSON object as a result. Then, another file tries to
imports the cat.js, but instead of getting an array of objects with full of cats, gets an empty array as result. Why? Due to Javascript's nature, objects are not immutable by default and
imports do not restart their states after being called.

In order to understand this behaviour we need to get a level deeper. These days, we use bundlers such as Webpack or SWC to run and customize our codes. What they do is, they boil down all the code
into a single file and let them share the same/common lexical scope - so we don't have to download each file individually when we requested a website. Let's try to reproduce the scenario above.

Even though we think we work in different files, in reality we are actually working in a single file at the end. But, preventing this behaviour is actually pretty easy.

As you can see once we copied the CatList into different variable, console.log and pop(), they both reference the different objects.

var n = [
      { name: "Cat1" },
      { name: "Cat2" },
      { name: "Cat3" },
      { name: "Cat4" },
    ];
    //function that copies catlist into some other variable.
    console.log(n);
    a.pop(), a.pop(), a.pop(), a.pop();

We successfully prevented the mutation of an object.

Conclusion

It's important to keep the code as mutation free as possible to get rid of those unwanted behaviours. With a simple copy, you can save yourself from hours of working.
So, new time think twice while importing and mutating objects. Stay mutation free!

How Does "prevState" Works Under the Hood

Oğuzhan Olguncu — Tue, 22 Feb 2022 22:02:45 +0000

We have always been told to use prevState when dealing with useState but not really why we need it in the first place. Today, we will deep dive and see how it works under the hood to retrieve the latest state without the need of render cycle - render cycle refers to VDOM updates, not actual browser refresh. But before going forward, first, we need to see how the real problem occurs when the state is used instead of prevState.

const [counter, setCounter] = useState(0);
  return (
    <div className="App">
      <div>Counter: {counter}</div>
      <button
        onClick={() => {
          setCounter(counter + 1);
          setCounter(counter + 2);
          setCounter(counter + 3);
        }}
      >
        Click me to increase the counter!
      </button>
    </div>

In reality, this should increase the Counter by six each time we click, but it's only taking the last one to account.
So what's the reasoning behind this? Is this working incorrectly, or is this the intended behaviour? It turns out it's not falsy or incorrect; it is working as expected programmatically, at least.
Because for React to access the counter state, it should complete its rendering cycle. But, since we force React to read the counter state before the cycle completion, it's only referring to the last one.

Okay, let's see how it behaves when we introduce prevState.

const [counter, setCounter] = useState(0);
  return (
    <div className="App">
      <div>Counter: {counter}</div>
      <button
        onClick={() => {
          setCounter(prevState => prevState + 1);
          setCounter(prevState => prevState + 2);
          setCounter(prevState => prevState + 3);
        }}
      >
        Click me to increase the counter!
      </button>
    </div>

Now it's working as we expected. But, how? To answer this question, we'll build a simple React clone and see how it internally manages prevState.

React used to rely on this in class-based components, but now it's using closures under the hood to manage hooks states. Pretty much all of the hooks use closures to access information about previous renders.

A little recap for closures to not get lost in the following examples.

Closures

Consider the following code:

const add = () => {
  let counter = 0;
  return (x = 1) => {
    counter += x;
    return counter;
  };
};

const foo = add();

foo(5); // 5
foo(5); // 10

Closure functions always hold a reference to an inner variable to keep track of it. The inner function is only accessible within the function body, and this inner function can access counter at any time. So between function calls counter variable will always point to the latest variable state.

In the example above, if we go ahead and use a regular function, we would end up with 5 twice, but since we keep track of value inside function thanks to closure, we keep adding to the accumulated value.

Now, going back to our original example. We will build a simple React clone that utilizes closures under the hood to persist states between renders.

function Counter() {
  const [count, setCount] = React.useState(5);

  return {
    click: () => setCount(count + 1),
    _render: () => console.log('_render:', { count }),
  };
}

At first glance, you are probably saying we need an object with two functions, one to take care of useState and another one for our pseudo rendering. And definitely, a variable to persist
the state.

const MyReact = () => {
  let val = null;

  return {
    render(Component) {
      const Comp = Component();
      Comp._render();
      return Comp;
    },
    useState(initialValue) {
      val = val || initialValue;
      const setState = (nextState) => (val = nextState);
      return [val, setState];
    },
  };
};

Let's start with render(). The render() function accepts a component, and all it does is invoke the _render() and return the component for future use because we need to keep its reference. Without return Comp, we can invoke neither click nor _render because it's this function that carries the details about our component.

The useState() is pretty straight forward. It takes the default value and assigns it to val, but only val is not present. Then, we have setState() to assign new values to our state.
Finally, we return a tuple - array with 2 elements.

const MyReact = () => {
  let _val = null;

  return {
    render(Component) {
      const Comp = Component();
      Comp._render();
      return Comp;
    },
    useState(initialValue) {
      _val = _val || initialValue;
      const setState = (nextState) => (_val = nextState);
      return [_val, setState];
    },
  };
};

const React = MyReact();
function Counter() {
  const [count, setCount] = React.useState(5);

  return {
    click: () => setCount(count + 1),
    _render: () => console.log('_render:', { count }),
  };
}

let App;
App = React.render(Counter); // _render: {count: 5}
App.click();
App.click();
App.click();
App = React.render(Counter); // _render: {count: 6}

Now, if we run this piece of code, it only prints twice because we called render twice - that's pretty expected. But, we clicked three times; why did it print count 6 instead of 8.
Similar to real React our MyReact is waiting for React to render. Without render, it cannot process the upcoming state updates. Therefore relies on render.

let App;
App = React.render(Counter); // _render: {count: 5}
App.click();
App = React.render(Counter); // _render: {count: 6}
App.click();
App = React.render(Counter); // _render: {count: 7}
App.click();
App = React.render(Counter); // _render: {count: 8}

If we let it render, then it prints correctly.

So, how can we access the _val inside MyReact? You guessed it right, we need to give a callback to setCount and change the useState a bit. And, if you are worried about callback, don't, because it's something we already know and use.

useState(initialValue) {
      _val = _val || initialValue;
      const setState = (nextState) => {
        _val = typeof nextState === "function" ? nextState(_val) : nextState // Changed this line to accept callbacks
      }
      return [_val, setState];
}

const React = MyReact();
function Counter() {
  const [count, setCount] = React.useState(5);

  return {
    click: () => setCount((prevState) => prevState + 1), // Sending callback to access closure
    _render: () => console.log('_render:', { count }),
  };
}

In setCount all we do is giving an arrow function that accepts a variable and adds 1 to it.

setCount((prevState) => prevState + 1);

const setState = (incVal) => {
  _val = typeof incVal === 'function' ? incVal(_val) : incVal;
};

We no longer need to rely on render cycles, we can directly access the state closure via prevState.

let App;
App = React.render(Counter); // _render: {count: 5}
App.click();
App = React.render(Counter); // _render: {count: 6}
App.click();
App = React.render(Counter); // _render: {count: 7}
App.click();
App.click();
App.click();
App = React.render(Counter); // _render: {count: 10}

By the way, this does not mean we need render anymore. Whether you like it or not React keeps rendering, but we can always get fresh states during rendering phase instead of stales one.

Wrapping Up

Some of the concepts above might seem vague, but in due time with lots of pratice they start become more understandable.

Important takeaways:

Functional components use closures under the hood to store states.
Always rely on prevState to avoid stale states.
Learning the core concepts of the language will always help to get deeper understanding

The Mystical World of Solidity: Intro to Smart Contracts

Oğuzhan Olguncu — Mon, 27 Dec 2021 18:47:37 +0000

Have you ever wanted to program the Blockchain before but failed? If you have, don't worry. In this tutorial, our sole focus will be on Solidity.
We won't be diving into details about Metamask or how to integrate a smart contract into your web apps. Let me be frank, throwing lots of technologies or methodologies at the beginning of the learning process makes it a lot harder to digest.

So, in this tutorial, we will try to come up with some Lottery smart contract without using fancy tools - similar to a real-world lottery, you place some money and get some amount of money in return if you win.
Everybody can participate in exchange for some ethers. If in the end, you are the winner you'll have all the money in the contract.
Now, you might be asking yourself, "What the hell is ether" or "But, how do I send ether to contract".

Okay, let's start from the first one. You probably had heard ether before, but if you haven't, I will briefly explain.
Ether is the currency used in the Ethereum blockchain to incentivize miners and stake owners. And, of course, for gas prices - gas price is a transaction fee but with a fancy name.
If you try to interact with a contract or send some ether to another address - unique characters similar to our IDs - you have to pay some ethers usually in small amounts.

I know I told you we won't be using anything but Solidity. But we need an IDE/Editor to write our very first contract, and, lucky for us, there is a development environment called Remix not the library Remix. It's an IDE for Ethereum development built on top of the web where you can compile, deploy and test your smart contracts.

There are some steps in Solidity development:

Create your contract through Remix, Hardhat or Truffle
Compile your contract
Test & Deploy your contract

We will start off with the first one. Navigate to Remix follow the steps below.

Then, paste this Solidity codes and we go over each line and explain what it does.

// SPDX-License-Identifier: GPL-3.0

pragma solidity >=0.7.0 <0.9.0;

contract Lottery {
    address payable[] public players;
    address public manager;

    constructor() {
        manager = msg.sender;
    }

    receive() external payable {
        require(msg.value == 1 ether);
        players.push(payable(msg.sender));
    }

    function getBalance() public view returns (uint256) {
        require(msg.sender == manager);
        return address(this).balance;
    }

    function random() public view returns (uint256) {
        return
            uint256(
                keccak256(
                    abi.encodePacked(
                        block.difficulty,
                        block.timestamp,
                        players.length
                    )
                )
            );
    }

    function pickWinner() public {
        require(msg.sender == manager);
        require(players.length >= 3);

        uint256 r = random();

        uint256 index = r % players.length;
        players[index].transfer(getBalance());

        delete players;
    }
}

The pragma is telling the Solidity compiler to look for certain features or checks. No more different then Node or NPM version. Then, we have the contract if we are looking for
a resemblance in other languages it's safe to say contract is a class like keyword.

Then, we have our state variables. Those variables will be stored on the blockchain and persist. There are only a couple of data types, by the way.

    address payable[] public players;
    address public manager;

Data Types in Solidity

boolean
uint
int
address
address payable - address that receives ether exposes transfer and send

Now that we cleared that out. Let's continue. We've defined two variables, one for storing users who participated in the lottery and one for the manager itself.
Since users will be more than one, we defined it as an array. And, since we want all those variables to be accessible outside of the contract, we marked them as public.

By the way, there are couple of accessors.

Accessors in Solidity

public - Everyone can access
external - Only for external use and can not be invoked within the contract
internal - Only for this and derived contract can use
private - Only for this contract, not available for derived contract

Then, we have the constructor - optional function and only executed during the contract creation.
In our constructor, we specify the "manager" will be the one who created the contract. If you are asking yourself, "Where does msg.sender come from".
The msg is a built-in variable that carries some metadata about the transaction.

  constructor() {
        manager = msg.sender;
    }

MSG Variable

msg.data (bytes calldata): complete calldata
msg.sender (address): sender of the message (current call)
msg.sig (bytes4): first four bytes of the calldata (i.e. function identifier)
msg.value (uint): number of wei sent with the message

Then, we have receive() which is also special function/variable just like msg - Special Variables and Functions.
The receive() says this contract accepts ether from outside. Dead simple.

    receive() external payable {
        require(msg.value == 1 ether);
        players.push(payable(msg.sender));
    }

Next up, we have require() which, helps us make assertions. We are making sure that anyone willing to participate gotta send exactly 1 ether. But, why didn't we use if?. The reason is every contract interaction in Solidity consumes gas -transaction fee- therefore, we have to be rigorous about it.

Imagine that scenario below:

  receive() external payable {
      /*


      sprinkling some fairy dust
      bunch of operations that modifies blockchain


      */
        if(msg.value == 1 ether) {
            players.push(payable(msg.sender));
        }
    }

If you were to send 2 ether instead of 1, you wouldn't get your gas -transaction fee- back. Because, if does not revert the contract interaction, but require() do.

So, if you don't wanna spend peoples ethers for nothing always go with require() and make sure they got their ethers back if interaction fails.

Inside receive(), if conditions are met, we add a participant to players array and increase contracts balance.

Next up, we have getBalance(). First, we make sure, the caller is the owner, then access the balance of the contract. The address(this) is used to access the contract's address object.

    function getBalance() public view returns (uint256) {
        require(msg.sender == manager);
        return address(this).balance;
    }

Before we move on, we have one more thing we haven't covered yet, the view. If you are not planning to modify the state, you need to pass the view keyword to the function.
If you are curious about which actions modify the state, there they are.

State modifiers

Writing to state variables.
Emitting events.
Creating other contracts.
Sending Ether via calls.
Calling any function not marked view or pure

Next up, we have random(). A pretty generic function that returns random numbers using keccak algorithm. If your goal is to create a random number generator function in the blockchain -pseudorandom-, this is the code you eventually end up with.

    function random() public view returns (uint256) {
        return
            uint256(
                keccak256(
                    abi.encodePacked(
                        block.difficulty,
                        block.timestamp,
                        players.length
                    )
                )
            );
    }

Now, our contract's final and most important part is pickWinner(). But, before calling pickWinner(), we need to ensure that caller is the owner and at least three players participated in the lottery.
To achieve that, we use require(). Then, we use random() to generate a random number and use a modulo to find a random number between 0 and our players' length. After the number has been picked we transfer all
the money in the contract to the winner via transfer(). And for reusability, we use delete to reset the players' array.

       function pickWinner() public {
        require(msg.sender == manager);
        require(players.length >= 3);

        uint256 r = random();

        uint256 index = r % players.length;
        players[index].transfer(getBalance());

        delete players;
    }

Now that we have completed our contract it's time to compile it.

Everything is ready for the test in fake EVM(Ethereum Virtual Machine).

We've deployed our contract from an account, then made three different contract calls and sent one ether from each account. In the end, one of the accounts received the prize sum.
I purposely didn't show all the functionalities of our contract. Like, testing out getBalance() to check if the caller is the owner or pickWinner() without at least three players.
I highly recommend you to test each function by yourself to get to know Remix and Solidity.

SolidJS vs React: I've Built the Same App On Both Libraries.

Oğuzhan Olguncu — Tue, 12 Oct 2021 10:44:14 +0000

SolidJS has gained lots of popularity lately due to having a close relationship with React. It has a declarative nature like React, useState and useEffect like hooks, JSX, ContextAPI, Portals, Error Boundaries. And it gets even better; Solid is much faster in terms of execution and has a lot smaller bundle size. Because it does not carry the burden of Virtual DOM, which means SolidJS uses real DOM instead. When your state changes, SolidJS updates only the code that depends on it.

I built the same app with minimal dependencies, Axios for fetch requests and TailwindCSS for styling. Thanks to core API similarities in both libraries. Before creating this app, I haven't yet had a chance to try Solid. So, I built the app as if I'm using React. Beware, this article does not aim to teach React, or Solid only tries to point out the differences and similarities in both libraries. Let's get started.

SolidJS App Github Link
ReactJS App Github Link

React

const fetchEpisodes = async (optionalUrl?: string) =>
  axios.get<EpisodeResponse>(optionalUrl ?? 'https://rickandmortyapi.com/api/episode');

const App: FC = () => {
  const [episodes, setEpisodes] = useState<EpisodeResponse>();
  const [ref, inView] = useInView({ triggerOnce: true });

  const fetchMoreEpisodes = async () => {
    //Fetching episodes with axios
  };

  useEffect(() => {
    if (inView === true) fetchMoreEpisodes();
  }, [fetchMoreEpisodes, inView]);

  useEffect(() => {
    fetchEpisodes().then((res) => setEpisodes(res.data));
  }, []);

  return (
    <div className="flex justify-center items-center flex-col p-10">
      <h2 className=" font-medium text-4xl my-5">Rick and Morty</h2>
      <div style={{ width: '1000px' }}>
        {episodes?.results.map((episode, index) => (
          <EpisodeWrapper
            episode={episode}
            key={episode.name}
            viewRef={index === episodes.results.length - 1 ? ref : undefined}
          />
        ))}
      </div>
    </div>
  );
};

export default App;

Solid

const fetchEpisodes = async (optionalUrl?: string) =>
  axios.get<EpisodeResponse>(optionalUrl ?? 'https://rickandmortyapi.com/api/episode');

const App: Component = () => {
  const [episodes, setEpisodes] = createSignal<EpisodeResponse>();

  const fetchMoreImages = async () => {
    //Fetching episodes with axios
  };

  const handleScroll = () => {
    if (window.innerHeight + window.scrollY >= document.body.offsetHeight) {
      fetchMoreImages();
    }
  };

  createEffect(() => {
    window.addEventListener('scroll', handleScroll);
  });

  onMount(async () => {
    setEpisodes((await fetchEpisodes()).data);
  });

  onCleanup(async () => {
    window.removeEventListener('scroll', handleScroll);
  });

  return (
    <div class="flex justify-center items-center flex-col p-10">
      <h2 class=" font-medium text-4xl my-5">Rick and Morty</h2>
      <div style={{ width: '1000px' }}>
        <For each={episodes()?.results} fallback={<p>Loading...</p>}>
          {(episode) => (
            <div>
              <EpisodeWrapper episode={episode} />
            </div>
          )}
        </For>
      </div>
    </div>
  );
};

export default App;

Apart from some syntactic differences they are pretty much the same. In Solid we use useSignal hook instead of useState hook. Only difference between these hooks, in useState we can directly call the episodes, but in useSignal we have to invoke it just like a function, because it's a function. If we are using Typescript we can give generic type to our signal just like we do in React.

In React we call our API's in useEffect to supply inital data for states. But, in Solid we can either call lifecycle method called onMount or you can ditch, onMount and use createResource hook. This hook works like a custom fetch — useFetch — takes a function and returns a promise, loading and error status. But, for the sake of ease
I'll go with onMount.

To handle side-effects in Solid we have a hook called createEffect this particular hook quite similar to useEffect but it has some quirks. Instead of taking dependencies manually
it automatically binds itself to state inside that causes changes. Example:

function Counter() {
  const [count, setCount] = createSignal(0);
  const increment = () => setCount(count() + 1);

  createEffect(() => {
    console.log(count()); // Logs count every time it changes
  });
  return (
    <button type="button" onClick={increment}>
      {count()}
    </button>
  );
}

Going back to our original example. So, we want to run handleScroll each time person scrolls. We create createEffect and call our event listener. That's it. For the return part, in React we generally use map to iterate over the state, but it Solid we have a built in option called For. It's actually a component which receives each in our case it's episodes state and fallback option to show loading or anything you want. And, good part is you don't have to deal with keys in Solid it automatically handles it for you.

By the way, you can pass props just like you pass props in React everything is the same.

Benchmarks

Benchmarks criteria will be performance profiling in Chrome Dev Tools and final bundle sizes. Let's start with Performance profiling. The performance tab shows an overall breakdown of CPU activity into four categories:

Loading: Making network requests and parsing HTML
Scripting: Parsing, compiling, and running JavaScript code, also includes Garbage Collection (GC)
Rendering: Style and layout calculations
Painting: Painting, compositing, resizing and decoding images

The left side is React, and the right is Solid. As you can see Scripting part is almost 3x faster, Rendering almost 2x faster, Painting part is abnormally faster.

If we went down a level deep on the scripting part, we see why.

React

Solid

React first makes a Function Call which evaluates and commits VDOM into DOM, then makes the XHR calls. Since Solid does not have to deal with VDOM to DOM, it skips that part and starts requests right away. By the way, if you are wondering about what Functional Call and XHR Load, means you can check this site Event References.

Bundle sizes of apps:

React

Solid

Conclusion

SolidJS definitely doing some things or maybe most of the things better than React, but in my humble opinion, the biggest problem for Solid is the ecosystem. React has an enourmous ecosystem it has components, hooks, patterns for everything. Think something and try serching that thing in npm, and I bet you will find something regarding your needs. Right now Solid's selling point is being fast. In benchmarks it says
it is quite close to vanilla JS.

It is close to vanilla JS, but we are missing the key thing here. People are not going with React because it is fast, and people even know it isn't. They are going with React because of the massive community and tooling ecosystem around it. But I believe that SolidJS has a bright future and, as the community gets bigger and bigger, it'll be even better.

SolidJS App Github Link
ReactJS App Github Link

Function Composition in Javascript

Oğuzhan Olguncu — Sun, 03 Oct 2021 19:46:18 +0000

After learning map, reduce and higher-order functions, you finally stepped into the gate of functional programming. As you keep delving deeper you stumbled upon composing and piping, and, you start to wonder why one even uses compose. Function composition(compose) allows us to define reusable, testable and maintainable functions. All those perks are the motivation behind functional programming's existence.

This whole process is quite parallel to what we do in math.

f(x) = x + 2
g(x) = x * 2

h(x) = f(g(x)) // If x is 2, then result will be 6.

Just like in this example, compose function uses the output of the functions as input for the next function. Let's see it in action.

[
  {
    "id": 1,
    "name": "Alice's Adventures in Wonderland",
    "completed": false
  },
  {
    "id": 2,
    "name": "The Fellowship of the Ring",
    "completed": true
  },
  {
    "id": 3,
    "name": "The Return of the King",
    "completed": false
  },
  {
    "id": 4,
    "name": "The Golden Compass",
    "completed": true
  },
  {
    "id": 5,
    "name": "1984",
    "completed": false
  }
]

Suppose we want to find completed book titles using regular ES6 it would be something like this:

const completedBookTitles = book.filter((book) => book.completed).map((book) => book.name);
//  ["The Fellowship of the Ring", "The Golden Compass"]

We can even separate arrow functions to their own functions to make it more readable.

const completedBooks = (book) => book.completed;
const completedBookNames = (book) => book.name;
const completedBookTitles = books.filter(completedBooks).map(completedBookNames);
//  ["The Fellowship of the Ring", "The Golden Compass"]

Or, we can compose them but, first, we need to make ourselves a brand new compose function.

const compose = (...fns) => (val) => fns.reduceRight((acc, fn) => fn(acc), val);

Reduce works left-to-right, but, since composition works right-to-left we use reduceRight to reverse it. Now, let's demystify this function.
We will go step-by-step and start with ...fns, what is this? If we are not certain about how many arguments will be received we tend to use
...args, but in our case, we are expecting functions instead of regular values. This is also called rest parameters.

const add = (a, b, c, ...args) => {
  console.log(args); // returns [4,5,6]
  return a + b + c;
};
add(1, 2, 3, 4, 5, 6);

Currying

Now, we have another mysterious thing in our function, another arrow function. This thing actually called currying.
Let's quickly recap currying. Currying gives you ability to splitting your function calls into multiple calls and gives you ability to provide one argument at a time which gives you unary functions.

const curriedAdd = (x) => (y) => x + y;

curriedAdd(1)(2); // returns 3

In the third part - fns.reduceRight - we are just iterating over functions which received by compose function and calling each function with
a given array which in our case it's our curried value - val -. Now, instead of chaining filter and map let's compose them.

const completedBooks = (books) => books.filter((book) => book.completed);
const bookNames = (books) => books.map((book) => book.name);

const completedBookNames = compose(bookNames, completedBooks);
completedBookNames(books); // ["The Fellowship of the Ring", "The Golden Compass"]

By the way, if reading right to left feels weird don't worry I got you covered. There is another function called pipe, which works just like compose but in reverse.
All we have to do is use reduce instead of reduceRight.

const pipe = (...fns) => (val) => fns.reduce((acc, fn) => fn(acc), val);
const completedBookNames = pipe(completedBooks, bookNames);
completedBookNames(books); // ["The Fellowship of the Ring", "The Golden Compass"]

If you dislike defining functions on top instead of using arrow function directly we can define our own map and filter.

const map = (fn) => (arr) => arr.map(fn);
const filter = (fn) => (arr) => arr.filter(fn);

const completedBookNames = pipe(
  filter((book) => book.completed),
  map((book) => book.name),
);
completedBookNames(books); // ["The Fellowship of the Ring", "The Golden Compass"]

Partial Application

We can even spice up our compose/pipe more with a partial application, by the way, partial application is just like currying allows you to make multiple function calls, but
also gives you an option to provide multiple arguments. In our case, we will provide only one argument for the sake of simplicity. Let's see it in the action.

const log = (val) => console.log(val);
const reverseArray = (isReverse) => (arr) => (isReverse ? arr.reverse() : arr);
const reversed = reverseArray(true); // Partially applied

pipe(
  filter((book) => book.completed),
  map((book) => book.name),
  reversed,
  log,
)(books); //  ['The Golden Compass', 'The Fellowship of the Ring'],

Practical Examples

const person = {
  name: 'Jack The Ripper',
  location: 'London',
};

Let's imagine we have a person object, and we have been requested to make few changes without mutating the object.
Because objects are passed around by their references which results in mutating the object and losing the previous version of the object which generates impure functions.
In functional programming, we always strive for pure functions. To overcome that hurdle, we need to make a shallow copy of our object first, then mutate the copied object.

const person = {
  name: 'Jack The Ripper',
  location: 'London',
};

const shallowClone = (obj) => (Array.isArray(obj) ? [...obj] : { ...obj });
const changeLocation = (obj) => {
  obj.location = 'Birmingham';
  return obj;
};
const result = pipe(shallowClone, changeLocation)(person);
console.log(person === result); // false

const result = pipe(changeLocation)(person);
console.log(person === result); // true

Another example would be finding word count in string.

const log = (val) => console.log(val);
const text =
  "Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book";

const splitWords = (val) => val.split(' ');
const countWords = (val) => val.length;

pipe(splitWords, countWords, log)(text);

Conclusion

It's been quite an adventure, we learned lots of new things, things that take time to digest. Such as currying to call the function multiple times with different arguments, reduceRight right to reverse reduce, compose/pipe to compose functions as unaries, partially applying function so we can provide additional arguments on the fly. All these concepts give us side-effect free(pure functions), immutable objects, testable and reusable functions. The examples we went through were quite trivial, but they can be used in complicated scenarios as well. This is just the beginning of functional programming if you are into it check monads, transducers, functors.

Introduction to Micro Frontends with Module Federation, React and Typescript

Oğuzhan Olguncu — Thu, 27 May 2021 19:12:44 +0000

The Micro Frontend is one of the hottest topics on the internet right now. We hear it all the time, but what is micro Frontend? Imagine a website with lots of components such as Navbar, Footer, Main Container and Side Menu. What would happen, if they were being served from different domains? Yes, you guessed it right we would've ended up with a micro Frontend. Now, thanks to micro frontend technologies, we can deal with those apps separately. We can write their unit tests separately, e2e tests separately we can even use different frameworks like Angular, Vue and Svelte.

There are two major players to make those things happen right now, one of them is Module Federation and another one is Single SPA which I covered here: 🔗Migrating CRA to Micro Frontends with Single SPA.

Unlike Single SPA, Module Federation is lot less opiniated. You can architect your project however you want in Module Federation whereas in Single SPA you need setup a config file and architect your project around this file.
And there is only one thing scary about micro Frontends, and, that is configurations. Initial configuration scares people away because there are lots of pieces you need to bring together, and if it's your first time, without guidance, it's so easy to get lost.

Working Example

This a POC(Proof of Concept) project it may not look great, but that's not the point in our case.

🔗Project's Github address

🔴Live Example

Module Federation

The Module Federation is actually part of Webpack config. This config enables us to expose or receive different parts of the CRA to another CRA project.
These separate project should not have dependencies between each other, so they can be developed and deployed individually.

Let's first start by creating our Container project which exports other two app APP-1 and APP-2.

npx create-react-app container --template typescript

Container App

Project Structure

container
├─ package.json
├─ public
│ ├─ index.dev.html
│ └─ index.prod.html
├─ src
│ ├─ App.tsx
│ ├─ bootstrap.tsx
│ └─ index.ts
├─ tsconfig.json
├─ webpack.config.js
├─ webpack.prod.js
└─ yarn.lock

Let's add our dependencies

yarn add html-webpack-plugin serve ts-loader webpack webpack-cli webpack-dev-server

We need to make some changes. Create a file called bootstrap.tsx and move index.ts into bootstrap.tsx.

bootstrap.tsx

import App from './App';
import React from 'react';
import ReactDOM from 'react-dom';

ReactDOM.render(<App />, document.getElementById('root'));

And add those into index.ts

index.ts

import('./bootstrap');
export {};

And, finally add those into app.tsx for future use. We will discuss them later.

app.tsx

import React from 'react';
//@ts-ignore
import CounterAppTwo from 'app2/CounterAppTwo';
//@ts-ignore
import CounterAppOne from 'app1/CounterAppOne';

export default () => (
  <div style={{ margin: '20px' }}>
    <React.Suspense fallback="Loading header...">
      <div
        style={{
          border: '1px dashed black',
          height: '50vh',
          display: 'flex',
          justifyContent: 'space-around',
          alignItems: 'center',
          flexDirection: 'column',
        }}
      >
        <h1>CONTAINER</h1>
        <div
          style={{
            display: 'flex',
            flexDirection: 'row',
            justifyContent: 'space-around',
          }}
        >
          <div
            style={{
              marginRight: '2rem',
              padding: '2rem',
              border: '1px dashed black',
            }}
          >
            <h2>APP-1</h2>
            <CounterAppOne />
          </div>
          <div style={{ border: '1px dashed black', padding: '2rem' }}>
            <h2>APP-2</h2>
            <CounterAppTwo />
          </div>
        </div>
      </div>
    </React.Suspense>
  </div>
);

We've completed component parts and here comes the critical part. We need to setup our container apps Webpack to receive app-1 and app-2.

webpack.config.js

const HtmlWebpackPlugin = require('html-webpack-plugin');
const { ModuleFederationPlugin } = require('webpack').container;
const path = require('path');
const deps = require('./package.json').dependencies;

module.exports = {
  entry: './src/index.ts',
  mode: 'development',
  devServer: {
    contentBase: path.join(__dirname, 'dist'),
    port: 3000,
  },
  output: {
    publicPath: 'http://localhost:3000/',
  },
  resolve: {
    extensions: ['.ts', '.tsx', '.js'],
  },
  module: {
    rules: [
      {
        test: /\.(js|jsx|tsx|ts)$/,
        loader: 'ts-loader',
        exclude: /node_modules/,
      },
    ],
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'container',
      library: { type: 'var', name: 'container' },
      remotes: {
        app1: 'app1',
        app2: 'app2',
      },
      shared: {
        ...deps,
        react: { singleton: true, eager: true, requiredVersion: deps.react },
        'react-dom': {
          singleton: true,
          eager: true,
          requiredVersion: deps['react-dom'],
        },
      },
    }),
    new HtmlWebpackPlugin({
      template: './public/index.dev.html',
    }),
  ],
};

Update your package.json scripts as follows:

"scripts": {
    "start": "webpack serve --open",
    "build": "webpack --config webpack.prod.js",
    "serve": "serve dist -p 3002",
    "clean": "rm -rf dist"
}

Update your tsconfig as follows:

{
  "compilerOptions": {
    "target": "es5",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "noFallthroughCasesInSwitch": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": false,
    "jsx": "react-jsx"
  },
  "include": ["src"]
}

Most important thing to consider is ModuleFederationPlugin. We specify name of the module and remotes we receive from outside of the project. And set shared dependencies for eager consumption.

Don't mess up remote names. If the names are set incorrectly project won't compile.

Final step is to edit index.html.

<html>
  <head>
    <script src="http://localhost:3001/remoteEntry.js"></script>
    <script src="http://localhost:3002/remoteEntry.js"></script>
  </head>
  <body>
    <div id="root"></div>
  </body>
</html>

Here, we add remotes with corresponding ports.

Now our container app is ready we need setup app-1 and app-2, and expose <Counter /> components. Steps are pretty much the same, we'll setup bootstrap.tsx and webpack.config.js.
There are only minor changes in webpack config.

App-1

Project Structure

├─ package.json
├─ public
│  └─ index.html
├─ README.md
├─ src
│  ├─ App.tsx
│  ├─ bootstrap.tsx
│  ├─ components
│  │  └─ CounterAppOne.tsx
│  └─ index.ts
├─ tsconfig.json
├─ webpack.config.js
├─ webpack.prod.js
└─ yarn.lock

Let's add our dependencies

npx create-react-app app-1 --template typescript
yarn add html-webpack-plugin serve ts-loader webpack webpack-cli webpack-dev-server

Just like we did in Container app we'll setup bootstrap.tsx, index.ts and app.tsx.

bootstrap.tsx

import App from './App';
import React from 'react';
import ReactDOM from 'react-dom';

ReactDOM.render(<App />, document.getElementById('root'));

And add those into index.ts

index.ts

import('./bootstrap');
export {};

And, finally add those into app.tsx for future use. We will discuss them later.

app.tsx

import React from 'react';
import CounterAppOne from './components/CounterAppOne';

const App = () => (
  <div style={{ margin: '20px' }}>
    <div>APP-1 - S4 </div>
    <div>
      <CounterAppOne />
    </div>
  </div>
);

export default App;

Now we will create <Counter /> component which we will expose to container later in webpack config.

components > CounterAppOne.tsx

import React, { useState } from 'react';

const Counter = () => {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>
        Add by one each click <strong>APP-1</strong>
      </p>
      <p>Your click count: {count} </p>
      <button onClick={() => setCount(count + 1)}>Click me</button>
    </div>
  );
};

export default Counter;

We are pretty much done here, just need to add webpack configs.

const HtmlWebpackPlugin = require('html-webpack-plugin');
const { ModuleFederationPlugin } = require('webpack').container;
const path = require('path');
const deps = require('./package.json').dependencies;

module.exports = {
  entry: './src/index.ts',
  mode: 'development',
  devServer: {
    contentBase: path.join(__dirname, 'dist'),
    port: 3001,
  },
  output: {
    publicPath: 'http://localhost:3001/',
  },
  resolve: {
    extensions: ['.ts', '.tsx', '.js'],
  },
  module: {
    rules: [
      {
        test: /\.(js|jsx|tsx|ts)$/,
        loader: 'ts-loader',
        exclude: /node_modules/,
      },
    ],
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'app1',
      library: { type: 'var', name: 'app1' },
      filename: 'remoteEntry.js',
      exposes: {
        // expose each component
        './CounterAppOne': './src/components/CounterAppOne',
      },
      shared: {
        ...deps,
        react: { singleton: true, eager: true, requiredVersion: deps.react },
        'react-dom': {
          singleton: true,
          eager: true,
          requiredVersion: deps['react-dom'],
        },
      },
    }),
    new HtmlWebpackPlugin({
      template: './public/index.html',
    }),
  ],
};

Update your package.json scripts as follows:

"scripts": {
    "start": "webpack serve --open",
    "build": "webpack --config webpack.prod.js",
    "serve": "serve dist -p 3001",
    "clean": "rm -rf dist"
}

Update your tsconfig as follows:

{
  "compilerOptions": {
    "target": "es5",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "noFallthroughCasesInSwitch": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": false,
    "jsx": "react-jsx"
  },
  "include": ["src"]
}

Edit index.html.

<html>
  <head> </head>
  <body>
    <div id="root"></div>
  </body>
</html>

This config has some differences. We set port differently, exposed our app instead of remoting it, and we have a thing called filename where expose our
module to different modules. Remember that we add <script src="http://localhost:3001/remoteEntry.js"></script> to our container index.html. This is where
container will look up for app-1.

Important things here:

name: 'app1'
filename: 'remoteEntry.js'
expose

Exposing the wrong path very likely to cause a failure at compile time. Also settting up wrong name will cause a problem, because container is looking for app-1 if it can't
find it, it will fail.

App-2

Project Structure

├─ package.json
├─ public
│  └─ index.html
├─ README.md
├─ src
│  ├─ App.tsx
│  ├─ bootstrap.tsx
│  ├─ components
│  │  └─ CounterAppTwo.tsx
│  └─ index.ts
├─ tsconfig.json
├─ webpack.config.js
├─ webpack.prod.js
└─ yarn.lock

App-2 is pretty much the same. Create a new react project do all the thing above and just add <CounterAppTwo /> and webpack config.

components > CounterAppTwo

import React, { useState } from 'react';

const Counter = () => {
  const [count, setCount] = useState(1);

  return (
    <div>
      <p>
        Multiply by two each click <strong>APP-2</strong>
      </p>
      <p>Your click count: {count}</p>
      <button onClick={() => setCount((prevState) => prevState * 2)}>Click me</button>
    </div>
  );
};

export default Counter;

webpack.config.js

const HtmlWebpackPlugin = require('html-webpack-plugin');
const { ModuleFederationPlugin } = require('webpack').container;
const path = require('path');
const deps = require('./package.json').dependencies;

module.exports = {
  entry: './src/index.ts',
  mode: 'development',
  devServer: {
    contentBase: path.join(__dirname, 'dist'),
    port: 3002,
  },
  output: {
    publicPath: 'http://localhost:3002/',
  },
  resolve: {
    extensions: ['.ts', '.tsx', '.js'],
  },
  module: {
    rules: [
      {
        test: /\.(js|jsx|tsx|ts)$/,
        loader: 'ts-loader',
        exclude: /node_modules/,
      },
    ],
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'app2',
      library: { type: 'var', name: 'app2' },
      filename: 'remoteEntry.js',
      exposes: {
        // expose each component
        './CounterAppTwo': './src/components/CounterAppTwo',
      },
      shared: {
        ...deps,
        react: { singleton: true, eager: true, requiredVersion: deps.react },
        'react-dom': {
          singleton: true,
          eager: true,
          requiredVersion: deps['react-dom'],
        },
      },
    }),
    new HtmlWebpackPlugin({
      template: './public/index.html',
    }),
  ],
};

Update your package.json scripts as follows:

"scripts": {
    "start": "webpack serve --open",
    "build": "webpack --config webpack.prod.js",
    "serve": "serve dist -p 3002",
    "clean": "rm -rf dist"
}

Update your tsconfig as follows:

{
  "compilerOptions": {
    "target": "es5",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "noFallthroughCasesInSwitch": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": false,
    "jsx": "react-jsx"
  },
  "include": ["src"]
}

Edit index.html.

<html>
  <head> </head>
  <body>
    <div id="root"></div>
  </body>
</html>

Now go to each project and run yarn start and navigate to localhost:3000. If you head over to sources tab in your
developer console, you'll see that each app comes from different port.

Roundup

Pros

Easier to maintain
Easier to test
Independent deploy
Increases scalability of the teams

Cons

Requires lots of configuration
If one of the projects crashes may affect other micro-frontends as well
Having multiple projects run on the background for the development

In essence, it's pretty easy, bunch of apps getting together in a same website and being served from different servers. If you are dealing with huge codebases, it's a fantastic technology
to keep in your arsenal. It will feel like a breeze to decouple your huge components into little apps. I hope I encouraged you to give micro-frontends a try.

Migrating CRA to Micro Frontends with Single SPA

Oğuzhan Olguncu — Thu, 13 May 2021 11:57:55 +0000

We started to hear the term Micro Frontend a lot because as web apps getting bigger and bigger each day, they also become harder to maintain by teams of developers without breaking each others code. That's why people came up with a term called Micro Frontend where people develop their web apps separately, maybe using different libraries or frameworks. One of the projects may use React for the navigation section whereas another project may use Vue or Angular for the footer section. In the end, you may end up with something below.

In essence, they are pretty similar to microservices. They both have different development processes, unit tests, end-to-end tests and CI/CD pipelines. As every technology comes with a trade-off, let's see its pros and cons.

Pros

Easier to maintain
Easier to test
Independent deploy
Increases scalability of the teams

Cons

Requires lots of configuration
If one of the projects crashes may affect other micro-frontends as well
Having multiple projects run in the background for the

Since we made a brief introduction to micro frontends, we can now start migrating from CRA to Single Spa. I'll share a project which uses Rick and Morty api.
Project uses React, Typescript and Chakra UI. Tests are also included.

Working Example

🔗Project's Github address

Single SPA

The idea behind Single SPA is it lets us build our micro-frontends around a root or container app that encapsulates all. In this root app, we can configure routing, shared dependencies, style guides, API and such. We can use as many micro-frontends as we like. And Single SPA has a powerful CLI that enables us to
do things above without a hussle.

Before we move on to Single SPA, let's first decide how we are going to split our CRA into micro-frontends.

├─ src
│  ├─ App.tsx
│  ├─ components
│  │  ├─ CharacterFeatureCard.tsx
│  │  ├─ CustomError.tsx
│  │  ├─ CustomSpinner.tsx
│  │  ├─ EpisodeCardWrapper.tsx
│  │  ├─ Layout.tsx
│  │  ├─ LocationCardWrapper.tsx
│  │  └─ Navbar.tsx
│  ├─ constants
│  │  ├─ routes.ts
│  │  └─ urls.ts
│  ├─ hooks
│  │  ├─ useFetchCharacters.ts
│  │  └─ useInitialData.ts
│  ├─ index.tsx
│  ├─ pages
│  │  ├─ Episodes.tsx
│  │  ├─ Locations.tsx
│  │  └─ NotFound.tsx
│  ├─ react-app-env.d.ts
│  ├─ setupTests.ts
│  └─ __tests__
│     ├─ CharacterFeatureWrapper.spec.tsx
│     ├─ Episodes.spec.tsx
│     ├─ EpisodesCardWrapper.spec.tsx
│     ├─ Location.spec.tsx
│     ├─ LocationCardWrapper.spec.tsx
│     └─ Navbar.spec.tsx
├─ type.d.ts

Our project has two features, Locations and Episodes. Components or tests either associated with Locations or Episodes.
So it's quite easy to see what to separate when we introduced our project to Single SPA. The final structure will resemble something like.

Let's get started by creating our root project. Project projects are essential in Single SPA.

mkdir MFProjects
cd MFProjects
npx create-single-spa

Then, pick the followings:

? Directory for new project single-spa-root
? Select type to generate single-spa root config
? Which package manager do you want to use? yarn
? Will this project use Typescript? Yes
? Would you like to use single-spa Layout Engine No
? Organization name (can use letters, numbers, dash or underscore) Tutorial
cd single-spa-root
yarn add npm-run-all

Organization name is quite critical here. If we name other projects differently we may end up with a broken app, so follow the convention.

In root app we register other projects in Tutorial-root-config.ts.

registerApplication({
  name: '@single-spa/welcome',
  app: () => System.import('https://unpkg.com/single-spa-welcome/dist/single-spa-welcome.js'),
  activeWhen: ['/'],
});

name is quite important as well it should always start @Organization name/project-name in our case it's @single-spa/welcome.

app lets us specify import path.

activeWhen for routing purposes.

And, we have another important file called index.ejs. If we register new apps into our root we also need to update index.ejs.

<% if (isLocal) { %>
<script type="systemjs-importmap">
  {
    "imports": {
      "@Tutorial/root-config": "//localhost:9000/Tutorial-root-config.js"
    }
  }
</script>
<% } %>

Update your package.json script section as follows.

"scripts": {
    "start": "webpack serve --port 9000 --env isLocal",
    "lint": "eslint src --ext js,ts,tsx",
    "test": "cross-env BABEL_ENV=test jest --passWithNoTests",
    "format": "prettier --write .",
    "check-format": "prettier --check .",
    "build": "webpack --mode=production",
    "episodes": "cd .. && cd single-spa-app-episodes && yarn start --port 9001",
    "locations": "cd .. && cd single-spa-app-locations && yarn start --port 9002",
    "episodes-build": "cd .. && cd single-spa-app-episodes && yarn",
    "locations-build": "cd .. && cd single-spa-app-locations && yarn",
    "start-all": "npm-run-all --parallel start episodes locations",
    "build-all": "npm-run-all --parallel episodes-build locations-build"
}

We will come back to this part when we add Episodes and Locations.

Now, let's add Episodes project.

npx create-single-spa
? Directory for new project single-spa-episodes
? Select type to generate single-spa application / parcel
? Which framework do you want to use? react
? Which package manager do you want to use? yarn
? Will this project use Typescript? Yes
? Organization name (can use letters, numbers, dash or underscore) Tutorial
? Project name (can use letters, numbers, dash or underscore) tutorial-episodes

This time we picked single-spa application / parcel and specificed project name as tutorial-episodes.

Now, let's add Locations project.

npx create-single-spa
? Directory for new project single-spa-locations
? Select type to generate single-spa application / parcel
? Which framework do you want to use? react
? Which package manager do you want to use? yarn
? Will this project use Typescript? Yes
? Organization name (can use letters, numbers, dash or underscore) Tutorial
? Project name (can use letters, numbers, dash or underscore) tutorial-locations

Before we move on we need to configure our Tutorial-root-config.ts and index.ejs. Head over to your root app and change the followings.

Tutorial-root-config.ts

import { registerApplication, start } from 'single-spa';

registerApplication({
  name: '@Tutorial/tutorial-episodes',
  app: () => System.import('@Tutorial/tutorial-episodes'),
  activeWhen: ['/episodes'],
});

registerApplication({
  name: '@Tutorial/tutorial-locations',
  app: () => System.import('@Tutorial/tutorial-locations'),
  activeWhen: ['/locations'],
});

start({
  urlRerouteOnly: true,
});

location.pathname === '/' ? location.replace('/episodes') : null;

index.ejs

<script type="systemjs-importmap">
  {
    "imports": {
      "react": "https://cdn.jsdelivr.net/npm/react@16.13.1/umd/react.development.js",
      "react-dom": "https://cdn.jsdelivr.net/npm/react-dom@16.13.1/umd/react-dom.development.js",
      "@Tutorial/root-config": "http://localhost:9000/Tutorial-root-config.js",
      "@Tutorial/tutorial-episodes": "http://localhost:9001/Tutorial-tutorial-episodes.js",
      "@Tutorial/tutorial-locations": "http://localhost:9002/Tutorial-tutorial-locations.js"
    }
  }
</script>

Let's start building Episodes project. First, add the dependencies listed below.

cd single-spa-episodes
yarn add react-infinite-scroller react-lazy-load-image-component axios @chakra-ui/react @emotion/react@^11 @emotion/styled@^11 framer-motion@^4 react-router-dom @types/react-router-dom @types/react-lazy-load-image-component

Now, we will copy corresponding folders and files to Episodes project. You can copy files from: 🔗Project's Github address

├─ src
│  ├─ components
│  │  ├─ CharacterFeatureCard.tsx
│  │  ├─ CustomError.tsx
│  │  ├─ CustomSpinner.tsx
│  │  ├─ EpisodeCardWrapper.tsx
│  │  ├─ Layout.tsx
│  │  └─ Navbar.tsx
│  ├─ constants
│  │  ├─ routes.ts
│  │  └─ urls.ts
│  ├─ declarations.d.ts
│  ├─ hooks
│  │  ├─ useFetchCharacters.ts
│  │  └─ useInitialData.ts
│  ├─ pages
│  │  ├─ Episodes.tsx
│  │  └─ NotFound.tsx
│  ├─ root.component.test.tsx
│  ├─ root.component.tsx
│  ├─ Tutorial-tutorial-episodes.tsx
│  └─ __tests__
│     ├─ CharacterFeatureWrapper.spec.tsx
│     ├─ Episodes.spec.tsx
│     ├─ EpisodesCardWrapper.spec.tsx
│     └─ Navbar.spec.tsx
│─ type.d.ts

Notice that we only copied files associated with Episodes. We have one more step to do.

Episodes > root.component.tsx

import React from 'react';
import App from './App';

export default function Root(props) {
  return <App />;
}

App.tsx

import React from 'react';
import { lazy, Suspense } from 'react';
import { BrowserRouter as Router, Route, Switch } from 'react-router-dom';
import { ChakraProvider } from '@chakra-ui/react';

import * as ROUTES from './constants/routes';

const Episodes = lazy(() => import('./pages/Episodes'));
const NotFound = lazy(() => import('./pages/NotFound'));

function App() {
  return (
    <ChakraProvider>
      <Router>
        <Suspense fallback={<p>Loading...</p>}>
          <Switch>
            <Route path={ROUTES.EPISODES} component={Episodes} exact />
            <Route component={NotFound} />
          </Switch>
        </Suspense>
      </Router>
    </ChakraProvider>
  );
}

export default App;

We've created a new entry point for our Episodes project. Now, let's add Locations project.

cd single-spa-locations
yarn add react-infinite-scroller react-lazy-load-image-component axios @chakra-ui/react @emotion/react@^11 @emotion/styled@^11 framer-motion@^4 react-router-dom @types/react-router-dom @types/react-lazy-load-image-component

Now, we will copy corresponding folders and files to the Locations project just like we did for Episodes. You can copy files from: 🔗Project's Github address

├─ src
│  ├─ components
│  │  ├─ CharacterFeatureCard.tsx
│  │  ├─ CustomError.tsx
│  │  ├─ CustomSpinner.tsx
│  │  ├─ Layout.tsx
│  │  ├─ LocationCardWrapper.tsx
│  │  └─ Navbar.tsx
│  ├─ constants
│  │  ├─ routes.ts
│  │  └─ urls.ts
│  ├─ declarations.d.ts
│  ├─ hooks
│  │  ├─ useFetchCharacters.ts
│  │  └─ useInitialData.ts
│  ├─ pages
│  │  ├─ Locations.tsx
│  │  └─ NotFound.tsx
│  ├─ root.component.test.tsx
│  ├─ root.component.tsx
│  ├─ Tutorial-tutorial-locations.tsx
│  └─ __tests__
│     ├─ CharacterFeatureWrapper.spec.tsx
│     ├─ Location.spec.tsx
│     ├─ LocationCardWrapper.spec.tsx
│     └─ Navbar.spec.tsx
├─ type.d.ts

Locations > root.component.tsx

import React from 'react';
import App from './App';

export default function Root(props) {
  return <App />;
}

Locations > App.tsx

import { lazy, Suspense } from 'react';
import { BrowserRouter as Router, Route, Switch } from 'react-router-dom';
import { ChakraProvider } from '@chakra-ui/react';

import * as ROUTES from './constants/routes';
import React from 'react';

const Locations = lazy(() => import('./pages/Locations'));
const NotFound = lazy(() => import('./pages/NotFound'));

function App() {
  return (
    <ChakraProvider>
      <Router>
        <Suspense fallback={<p>Loading...</p>}>
          <Switch>
            <Route path={ROUTES.LOCATIONS} component={Locations} exact />
            <Route component={NotFound} />
          </Switch>
        </Suspense>
      </Router>
    </ChakraProvider>
  );
}

export default App;

Now let's add a header to our root project. Head over to your index.ejs and replace your body as follows.

<body>
  <main>
    <h2 id="header">The Rick and Morty Characters Directory</h2>
  </main>
  <script>
    System.import('@Tutorial/root-config');
  </script>
  <import-map-overrides-full
    show-when-local-storage="devtools"
    dev-libs
  ></import-map-overrides-full>
</body>

Add those styles to center the header.

<style>
      #header {
        width: 100%;
        -webkit-align-items: center;
        -webkit-box-align: center;
        -ms-flex-align: center;
        align-items: center;
        text-align: center;
        margin-top: 1.3rem;
        font-size: 2.25rem;
        line-height: 1.2;
        font-size: "-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";
      }
</style>

To run all projects at once, we head over to our root directory and run yarn start-all. Now, if we check localhost:9000 we will see
Episodes page being served from localhost:9001 and Locations page being served from localhost:9002. They are being conditionally rendered as we switch in our root project.

🔗Finished Project's Github address

Roundup

As we can see, setting up micro-frontends is a little tedious, but gives us the freedom to architected each project differently and that's a pretty good thing if we are work alongside lots of other devs.
Every decision every technique comes with a price so choose wisely.
Thanks for reading 🥳🥳🥳.

Handling Logged-in User in React/Firebase App

Oğuzhan Olguncu — Tue, 06 Apr 2021 19:26:05 +0000

Handling logged-in users in a React app is always tricky. But since we are going to be using Firebase to handle our auth, all we need to do is set up a custom React hook and context.
And, we are going to use Typescript during the process to make sure everything is safe and secure. We will start with our custom hook first, then move onto context.

Sole purpose of this article to cover logged-in users in the Firebase/React app which is why log-in and register phases are not covered.

useAuthListener

import { useState, useEffect } from 'react';

import firebase from 'firebase/app';
import { User } from '@firebase/auth-types';

export default function useAuthListener() {
  const [user, setUser] = useState<User | null>(() =>
    JSON.parse(localStorage.getItem('authUser') || '{}'),
  );

  useEffect(() => {
    const listener = firebase.auth().onAuthStateChanged((authUser) => {
      if (authUser) {
        localStorage.setItem('authUser', JSON.stringify(authUser));
        setUser(authUser);
      } else {
        localStorage.removeItem('authUser');
        setUser(null);
      }
    });

    return () => listener?.();
  }, [firebase]);

  return { user };
}

We first define a state which accepts User as a type and we lazily initialize it; meaning it'll only run on the first render, and not going to try parsing localStorage at each render.
The reason behind this, IO(Input-Output) operations are costly and we are trying to minimalize it via lazy-initialization.

Then we are setting up a useEffect which listens to auth changes through onAuthStateChanged. If a authUser exist we'll set localStorage so we can access it later, and of course, we'll set our setUser. If there is no authUser we'll clear our
localStorage and setUser. And do not forget to clean up the listener because listening to an event allocates memory and if we don't clean it up, it'll eventually lead to a memory leak.
In our case, it's not that important, but it's always best to follow the best practices.

Now, we are ready to use this, but there is one small thing left. We can either use this hook directly in our components or set up a new context to pass down our logged-in user.
I'll cover setting up a context because it feels more convenient than calling the same hook over and over again. In the end, that's why Context API exists.

User Context

import { createContext } from 'react';
import { User } from '@firebase/auth-types';

type ContextType = {
  user: User | null;
};

const UserContext = createContext<ContextType | null>(null);
export default UserContext;

Nothing special here we've just given type to our context.

App

import { BrowserRouter as Router, Route, Switch } from 'react-router-dom';
import PrivateRoute from 'components/private-route';

import * as ROUTES from 'constants/routes';
import UserContext from 'contexts/userContext';
import useAuthListener from 'hooks/use-auth-listener';

function App() {
  const { user } = useAuthListener();

  return (
    <UserContext.Provider value={{ user }}>
      <Router>
        <Switch>
          <PrivateRoute user={user} path={ROUTES.BOARDS} exact>
            <Boards />
          </PrivateRoute>
          <Route component={NotFound} />
        </Switch>
      </Router>
    </UserContext.Provider>
  );
}

export default App;

Now, everything inside our app.tsx can access firebase user through UserContext.

For example:

import UserContext from 'contexts/userContext';

const NavbarRight = () => {
  const user = useContext(UserContext)?.user;

  return <>{user?.displayName}</>;
};

export default NavbarRight;

You see how easy it is to manage logged-in user in a Firebase app built with React and Typescript. And, I hope encouraged you to use custom hooks and context for that matter.

Thanks for reading 🥳🥳🥳.

Introduction to Custom Hooks - useToggle & useAxiosAsync

Oğuzhan Olguncu — Tue, 23 Mar 2021 21:12:22 +0000

Custom hooks become a staple in our lives after we got introduced to hooks such as useEffect, useState, useReducer. Regardless of their purposes, custom hooks should start with use such as useAxiosAsync or useToggle. Therefore we can easily perceive that this is a custom hook. We could name them differently, but that would make them harder to detect at the first sight this is why the community following that convention.

Like in any other area of programming we always want to make things re-usable by detaching them from the main code. We, either turn them into functions or classes, but we are dealing with states so we want to be able to utilize react related stuff as well.

Thus we can achieve a couple of things:

DRY(Don't repeat yourself)
Reduced coupling
Modular code
Testable code

Let's take a look at this easy example:

useToggle

import { Alert, Button, Flex, Text } from '@chakra-ui/react';

function App() {
  const [on, toggle] = React.useState(false);
  return (
    <div>
      <span>{on ? 'ON' : 'OFF'}</span>
      <button onClick={() => toggle((prevState) => !prevState)}>TOGGLE</button>
      <button onClick={() => toggle(true)}>SET TOGGLE ON</button>
      <button onClick={() => toggle(false)}>SET TOGGLE OFF</button>
    </div>
  );
}
export default App;

This example is very different from where we toggle for Loading state while making a request for our APIs. Just on and off it's that simple. If we want this to be a custom hook, all we have to do is take useState out of this component and check for conditions while toggling state.

import { useState } from 'react';

const useToggle = (initialState = false) => {
  const [toggle, setToggle] = useState(initialState);

  const toggleState = (state?: false | true) => {
    setToggle(typeof state === 'boolean' ? state : !toggle);
  };
  return [toggle, toggleState] as const;
};

export default useToggle;

Now, using our custom hook in the same component as we did before.

import { Alert, Button, Flex, Text } from '@chakra-ui/react';
import useToggle from './useToggle';

function ToggleWithHook() {
  const [on, toggle] = useToggle(false);
  return (
    <div>
      <span>{on ? 'ON' : 'OFF'}</span>
      <button onClick={() => toggle()}>TOGGLE</button>
      <button onClick={() => toggle(true)}>SET TOGGLE ON</button>
      <button onClick={() => toggle(false)}>SET TOGGLE OFF</button>
    </div>
  );
}

export default ToggleWithHook;

Let's take a look at a more complex example, where we also use Generics in Typescript.

useAxiosAsync

type JokeType = {
  created_at: string;
  icon_url: string;
  id: string;
  url: string;
  value: string;
};

function AsyncWithoutHook() {
  const [joke, setJoke] = useState<JokeType | null>(null);
  const [error, setError] = useState<AxiosError<Error> | null>(null);
  const [isLoading, setIsLoading] = useState<boolean>(false);

  const fetchAJoke = async () => {
    setIsLoading(true);
    try {
      const { data } = await axios.get<JokeType>('https://api.chucknorris.io/jokes/random');
      setJoke(data);
      setIsLoading(false);
    } catch (error) {
      setError(error);
      setIsLoading(false);
    }
  };

  useEffect(() => {
    fetchAJoke();
  }, []);

  if (error) return <Flex>{error}</Flex>;
  if (isLoading) return <Flex>Loading...</Flex>;

  return (
    <Flex flexDirection="column" boxShadow="outline" rounded="md" width="50%" padding="1rem">
      {joke?.value}
      <Button onClick={fetchAJoke}>Fetch Again!!!</Button>
    </Flex>
  );
}

export default AsyncWithoutHook;

Now, using custom hooks, again.

import { Button, Flex } from '@chakra-ui/react';
import React from 'react';

import useAxiosAsync from './useAxiosAsync';

type JokeType = {
  created_at: string;
  icon_url: string;
  id: string;
  url: string;
  value: string;
};

function AsyncWithHook() {
  const [{ data, isLoading, error }, fetchAJoke] = useAxiosAsync<JokeType>(
    'https://api.chucknorris.io/jokes/random',
  );

  if (error) return <Flex>{error}</Flex>;
  if (isLoading) return <Flex>Loading...</Flex>;

  return (
    <Flex flexDirection="column" boxShadow="outline" rounded="md" width="50%" padding="1rem">
      {data?.value}
      <Button onClick={fetchAJoke}>Fetch Again!!!</Button>
    </Flex>
  );
}

export default AsyncWithHook;

We've shortened our component quite a bit by moving state related things to our useAxiosAsync. So, we no longer need to deal with business logic in our component and of course, we can use this useAxiosAsync whenever we want.

Roundup

In the essence, custom hooks are just useState and useEffect (of course other hooks as well) hooks moved to another file to reduce the amount of code in components.
So, if something bloating your component or you keep using same logic in other components, it's time to convert it into custom hook.

Thanks for reading 🥳🥳🥳.

Dealing With Binaries in Javascript

Oğuzhan Olguncu — Tue, 16 Mar 2021 22:37:38 +0000

If you ever had to deal with binaries in Javascript, you know you can't escape from Bitwise operators, bits, bytes and hexadecimals. I know because over the last two week or so, I've spent my time building a CHIP-8 emulator in Javascript, and I had to implement a CPU in Javascript. And, of course, without the knowledge of neither binaries nor bitwise operators,
such implementation would be impossible. That is why, today, we are going to talk about how to become a kickass bitwise ninja, but before we start talking about binaries in general we should have a solid understanding regarding:

What is Binary?
What is Byte?
What is Hexadecimal?

Binary

As you may have heard, binaries nothing but 1s and 0s streaming through your hardware. In essence, everything in our computers is binaries, but also in real life, we somehow use binaries as well.
A logical example for binary would be a Light Bulb; a light bulb has only two states it's either open(1) or close(0). Now you may say, okay there are only 2 states in a light bulb, but how do only two digits make up all this stuff?
The good thing is we can combine the values like 0101 or 1000 etc. With having more 1s in hand we can construct meaningful things such as:
Colors, Strings, Numbers.

Length	Name	Example
1	Bit	1
4	Nibble	1111
8	Byte	10111111

Everything is consist of Bits, Nibbles and Bytes. If there is only one it's a Bit, if there are 4 bits it's a Nibble, if there are 8 bits it's a Byte.
If you are curious, in Javascript to reveal the secret of binaries we have few options:

0b1111; // If you type this in your browser's console it will prompt: 15
parseInt(1111, 2); // This will also prompt: 15

Number(15).toString(2); // toString() turns your value into base-2 format which is binary

If you are wondering how 1111 become 15 don't worry I got you. Key thing to remember everything is at base-2 format.


   1       1       1         1
   ↓       ↓       ↓         ↓
   2³      2²      2¹        2⁰
   ↓       ↓       ↓         ↓
   8   +   4   +   2     +   1  = 15

Let's sum up Binaries

It's in base-2 format.
It's consist of bit.
The prefix 0b used.

Hexadecimal

Hexadecimals(also base 16) aren't so different than binaries. If we wanted to display decimal 255 in binary format we would have something like this: 0b11111111 8-bit long digits.
But, what if we wanted to display 4095 or 65535. You see where this is going it's becoming more and more difficult to present them in binary(base-2) format. Instead of
displaying them as binaries people come up with hexadecimal to present them in a more readable format.

Decimal	Binary	Hexadecimal
255	0b1111 1111	0xFF
4095	0b1111 1111 1111	0xFFF
65535	0b1111 1111 1111 1111	0xFFFF

To make these calculations at your browser:

0x1111; // If you type this in your browser's console it will prompt: 4369
parseInt(1111, 16); // This will also prompt: 4369

Number(4369).toString(16); // toString() turns your value into base-16 format which is hexadecimal

Let's see how does your browser make that calculation.


   1       1       1         1
   ↓       ↓       ↓         ↓
   16³      16²    16¹       16⁰
   ↓       ↓       ↓         ↓
 4,096  +  256  +  16    +   1  = 4369

Now, if you are curious about 0xFF, in hexadecimal we are not limited by 1 and 0 we can also use other numbers up to 9, but what comes after 9 ?
Let's see.

Decimal	Hexadecimal	Binary
0	0	0000
1	1	0001
2	2	0010
3	3	0011
4	4	0100
5	5	0101
6	6	0110
7	7	0111
8	8	1000
9	9	1001
10	A	1010
11	B	1011
12	C	1100
13	D	1101
14	E	1110
15	F	1111

Now you have an adequate amount of knowledge to see why 0xFF becomes 255.

Let's sum up Hexadecimals

It's in base-16 format.
It's consist of bytes.
Each Hexadecimal digit represents four bits.
The prefix 0x used.

Bitwise Operators

Bitwise operations work on binary format at the level of individual bits and it's a lot faster than doing arithmetic operations supported by programming languages.
If you are used to low-level programming, you are probably already familiar with these concepts. Nonetheless, if you are trying to build a pseudo-CPU, low-level programming or
learn more about memory efficiency in Javascript, please, read on.

There are several operators:

Bitwise AND (&)
Bitwise OR (|)
Bitwise XOR (^)
Bitwise NOT (~)
Bitwise Left Shift (<<)
Bitwise Right Shift (>>)

Bitwise AND (&)

The And operator(&) is quite simple it returns a 1 in each bit position for which the corresponding bits of both operands are 1s.


//If we apply & to this binaries

Binary #1      1 1 1 0
               | | | |
Binary #2      1 0 1 0
               ------- &
Result:        1 0 1 0  // Only takes 1s from both binaries

In Javascript: 0b1110 & 0b1010 // Returns 10

Practical example for And(&) would be bitmasking. A bitmask is a pattern of isolating the positions of bits we're interested in.
Let's suppose we are only interested in first 8 bits of first binary.

0100010000110010
        ^------^ Here is our 8bit
0000000011111111
--------------------- &
0000000000110010

Bitwise OR (|)

The Or operator(|) similar to And, but instead returns a 1 in each bit position for which the corresponding bits of either or both operands are 1s.


Binary #1      1 1 1 0
               | | | |
Binary #2      1 0 1 0
               ------- |
Result:        1 1 1 0  // Takes 1s from both binaries

In Javascript: 0b1110 | 0b1010 // Returns 14

Bitwise XOR (^)

The Xor operator(^) returns a 1 in each bit position for which the corresponding bits of either but not both operands are 1s.


Binary #1      1 1 1 0
               | | | |
Binary #2      1 0 1 0
               ------- ^
Result:        0 1 0 0  // If only one of two bits is 1, then set bit to 1

In Javascript: 0b1110 ^ 0b1010 // Returns 4

Bitwise NOT (~)

The Not operator(~) one of the easiest among others we simply invert 1s to 0s and 0s to 1s.


Binary #1      1 1 1 0
               ------- ~
Result:        0 0 0 1  // if only one of two bits is 1, then set bit to 1

In Javascript: ~0b1110 // Returns -15

Bitwise Left Shift (<<)

The Left Shift operator(<<) simply adds 0s to right of your binary by shifting others to left. This is generally used when we want to make room at the end of
our binary.


Binary #1      1 1 1 0
               ------- << 8
Result:        1 1 1 0 0 0 0 0  // if only one of two bits is 1, then set bit to 1

In Javascript: 0b11100000 << 8 // Returns 57344

Every shift left also multiplies your number as much as you shift left. If you shift 0b1110 << 1 this will give us 28 since 0b1110 was 14.

Bitwise Right Shift (>>)

The Right Shift operator(>>) deletes from right as much as your shift value.


Binary #1      1 1 1 0
               ------- >> 1
Result:        0 1 1 1  // if only one of two bits is 1, then set bit to 1

In Javascript: 0b1110 >> 1 // Returns 7

That's all there is to it.

Roundup

Performing some operations at binary level will be faster than regular operations.
The bitwise operators are mandatory if we have to deal with cases like bitmasking.
Must learn the shifting operations if we are saving some space or clipping a part for future use.

Thanks for reading 🥳🥳🥳.