DEV Community: Francisldn

Be Grateful for Rejections - Anecdotes about Rejections in Job Hunting Process

Francisldn — Mon, 26 Dec 2022 16:41:19 +0000

Remember to constantly remind yourself:
"Be grateful for the rejection, you are one step closer to getting a better offer!"

With the completion of the Codeworks bootcamp, one then realises that an even bigger challenge is on the horizon. Yes, job hunting in tech is a daunting task, a full time job in itself. In particular, for someone without a meaningful commercial software development experience, one will likely face multiple rejections before one eventually lands on a full time software developer role.

Facing Multiple Rejections
In this article, having had the experience of facing multiple rejections, I would like to share some anecdotes about my experience with rejections and how I handled them with a positive mindset during the job hunting process. I hope that it will inject some positive thinking and provide some form of encouragement to others who are currently in the job hunting process, and hopefully will also inspire others to share your own experiences as well.

Handle Rejections with a Positive Mindset
Receiving a rejection email or news from a company, which you have invested time going through various stages of the application process, can be demoralising. But it doesn't have to be that way. One can, and should, view job interview as a match-making process. You learn more about the company's culture, their way of working and the individuals that you will be working with, through the interview process, and you may or may not like what you have learnt.

Avoided a "Toxic Startup"
One of the first companies which I had interviewed with, had less than stellar reviews on Glassdoor. Inevitably, there will always be disgruntled staff in every workplace, but Glassdoor reviews give you a good insight about the company's culture and how the company treats its staff. In addition to the single negative review below, there were a few other similarly negative reviews about the company on Glassdoor.

Having gone through the 1st round interview with the company, I was invited to a live coding test, and I received a rejection email from the company after that. While it was disappointing, I was relieved at the same time. Had they offered me the role and had I accepted it, I would probably have walked into a "toxic workplace", to quote one of the former employee's reviews at Glassdoor. Sticking to a positive mindset, one can't help but feel lucky to have avoided this company.
Moral of the story: Rejection from a company is positive if the company has a toxic workplace.

Avoided a Shaky Startup
Early on in my job hunting process (around early October), I was invited to an interview for a frontend developer role with a crypto-bank startup. I spoke to the HR person in my 1st screening round and he assured me that, while the company was an early stage startup, they had a "solid, blue-chip" financial backer. And guess who was the financial backer? It turned out to be none other than the now-bankrupt FTX! Having passed the 1st screening round, I was given a technical take-home assignment, then I was invited to another live coding round with the Frontend Lead. I got a rejection email from the company after that. As we all know by now, FTX saw an implosion and collapsed in early November and, as they said, the rest is history.
Moral of the story: A rejection is a blessing in disguise when you found out, ex-post, that you have avoided a company saddled with funding problem due to the financial calamity of its financial backer.

Promised to be Agile But...
Another company which I had interviewed with, was truly fast-moving with their hiring process, at least initially. I completed the 1st screening round with the tech lead, 2nd round with the company's director/founder and 3rd round live-coding test, all within a week. When I met the company's director, he impressed upon me that, given the small size of the firm (about 20+ employees), the company adopted an agile hiring process and can move quickly with the right candidate without having to wait for other processes.

Having gone through all the rounds, which I thought I had performed well and was given such impression during the process, I was promised to be informed of the outcome 2 days later. One week went by and no news from them, then came the second week, still no news from them for the first few days. Finally, on the final day of the 2nd week, I received a rejection news from the company. At this point, I had already received a great offer from another company, so I was not that bothered about this promised-agile-but-slow-moving company anymore. In a way, I was thankful that they had moved slowly, had they moved fast and offered me the role and had I accepted it, I would have missed a better offer from another firm (which is fully remote with great pay and benefits).
Moral of the story: Don't be disheartened if you received a rejection, be hopeful that there is a better opportunity awaits you around the corner.

Closing Thought
Facing multiple rejections is an inevitable part of the job hunting process, especially tech jobs. I hope that the anecdotes above would inspire you to embrace rejections with a positive mindset and strengthen your resolve to persevere and break into tech in 2023.

Remember to constantly remind yourself: 
Be grateful for the rejection, 
you are one step closer to getting a better offer!

React Data Fetching Pattern - Part III

Francisldn — Wed, 16 Nov 2022 16:31:16 +0000

This article is a continuation of

Click here to access the Github repo for the code examples discussed below.

Redux createAsyncThunk

While React Context API is suitable for smaller apps, we need a more performant solution for larger apps.

Redux provides a solution to the problem of unnecessary re-rendering of components posed by Context API, as Redux only re-renders the updated component. Within the Redux-toolkit library, one has access to an API known as createAsyncThunk.

createAsyncThunk will accept a callback function that returns a promise - this is where the getUsersAPI function will reside. Upon execution of the createAsyncThunk function, similar to a Promise function, it will generate 3 types of actions: pending, fulfilled, rejected, and the users state will be updated accordingly depending on the action type.
Below is an example of the code:

interface UsersDataState {
  users: User[]
  loading: boolean
  error: string
}

const initialState: UsersDataState = {
  users: [] as User[],
  loading: false,
  error: "",
}

// set up createAsyncThunk function
export const getUsersData = createAsyncThunk("users/fetchUsers", () => {
  return getUsers(apiURL).then(({results}) => results)
})

const userSlice = createSlice({
  name: "user",
  initialState,
  reducers: {},

  extraReducers: (builder) => {
// Pending - users state is not updated
    builder.addCase(getUsersData.pending, (state) => {
      state.loading = true
    })

// Fulfilled - users state is updated
    builder.addCase(getUsersData.fulfilled, (state, action: PayloadAction<UserApi[]>) => {
      state.users = action.payload
        .map((user: UserApi) => {
          return {
            id: user.id.value,
            firstName: user.name.first,
            lastName: user.name.last,
            username: user.login.username,
            email: user.email,
          }
        })

      state.loading = false
    })

// Rejected - users state is an empty array
    builder.addCase(getUsersData.rejected, (state, action) => {
      state.loading = false
      state.users = []
      state.error = action.error.message || "Something went wrong"
    })
  },
})

For a React component to have access to the users state using Redux, one also has to set up a redux store and then wrap the <App /> component with Redux Provider. You may refer to the boilerplate code in the repo here for further details.

Having done the above, let's see how we can retrieve the data in the component for UI rendering.

As shown below, within a React component, one has access to 2 redux hooks:

useAppSelector - enable access to states
useAppDispatch - enable update to states

We can use useEffect hook to trigger the data fetching and updating of the users state. Then the state will be used for UI rendering.

export default function CardList() {
    const {users, loading, error} = useAppSelector((state) => state.user)
    const dispatch = useAppDispatch()

    // update of users state with useEffect
    useEffect(() => {
        dispatch(getUsersData())
    },[])

  return (
    <div className="grid sm:grid-cols-2 md:grid-cols-3 lg:grid-cols-4 justify-center grid-cols-1 mt-8">
        {loading 
        ? <Loading />
        : error 
        ? <ErrorFallBack />
        : users.map((user:User) => (<CardItem key={user.id} user={user}/>))
        }
    </div>
  )
}

Pros

More Performant than Context API: As Redux avoids unnecessary re-rendering, the app is more performant as a result.

Cons

Complicated setup: As demonstrated above, there are a lot of boilerplate codes to set up redux slicer and store.

Having discussed a few data fetching methods, could there be a solution that is both simple to set up and performant? Let's proceed to look at the next method - SWR.

To be continued:

For more information on Redux createAsyncThunk, see here.

If you like the content, please hit the like button so that it can reach more people.

React Data Fetching Patterns - Part II

Francisldn — Wed, 16 Nov 2022 16:31:05 +0000

This article is a continuation of:

React Data Fetching Patterns - useState-useEffect

Click here to access the Github repo for the code examples discussed below.

Custom Hook using React Context API

To deal with the problem of prop-drilling, we could create a custom hook which utilises React Context API. The useState-useEffect data fetching logic can then reside within this hook.

Using the example below, the UserContext component will create the users state, while UserProvider stores the states and provides them to other components through useContext hook.

interface UserProps {
    users: User[],
    loading: boolean,
    error: boolean,
}

export const UserContext = createContext<UserProps>({
    users: [],
    loading: false,
    error: false
})

export const UserProvider = ({children}: {children: React.ReactNode}) => {
    const [users, setUsers] = useState<User[]>([])
    const [error, setError] = useState(false)
    const [loading, setLoading] = useState(false)

    useEffect(() => {
        setLoading(true)
        getUsers(apiURL)
            .then(({results:data}) => {
                console.log({data})
                setUsers(
                    data.map((user:UserApi) => {
                        return {
                            id: user.id.value,
                            firstName: user.name.first,
                            lastName: user.name.last,
                            username: user.login.username,
                            email: user.email,
                        }})
                    )
                })
            .catch(() => setError(true))
            .finally(() => setLoading(false))
    },[])

    // useMemo hook is used to `memoize` the value so that they only recompute when states have changed
    const value = useMemo(() => ({
        users,
        loading,
        error
    }),[users, loading, error])

    return (
        <UserContext.Provider value={value}>
          {children}
        </UserContext.Provider>
      )
}
// Provide access to other components through useUsers custom hook
export function useUsers() {
    return useContext(UserContext)
}

To provide access of the states to all the child components, we need to wrap the UserProvider around the top level component (<App/>).

const root = ReactDOM.createRoot(
  document.getElementById('root') as HTMLElement
);
root.render(
  <React.StrictMode>
    <UserProvider>
      <App />
    </UserProvider>
  </React.StrictMode>
);

For a React component to access the states from UserProvider, the custom hook can be imported, and the required data can be retrieved through the custom hook, as illustrated below. This will allow any React component to have access to a full or subset of the states without having to prop-drill.

import { useUsers } from '../hooks/useUsers';

export default function CardList() {
    const {users, loading, error} = useUsers()

  return (
    <div className="grid sm:grid-cols-2 md:grid-cols-3 lg:grid-cols-4 justify-center grid-cols-1 mt-8">
        {loading 
            ? <Loading />
            : error 
            ? <ErrorFallBack />
            : users.map((user:User) => (<CardItem key={`${user.id}${user.email}`} user={user}/>))
        }
    </div>
  )
}

Pros

Easy to setup: With the Context API, it is relatively easy to set up and use
Easy to understand: The simple setup means that the code is also easily understandable

Cons

Unnecessary re-rendering: React will re-render all components whenever there is an update to the value of the props. For a larger app with thousands of components, this will slow down the performance of the app.

To deal with the issue of unnecessary component re-rendering and improve the performance of the app, let's proceed to look at the next data fetching method - Redux.

To be continued:

For more info on React Context, see here.

If you like the content, please hit the like button so that it can reach more people.

React Data Fetching Pattern - Part IV

Francisldn — Wed, 16 Nov 2022 16:30:39 +0000

This article is a continuation of

Click here to access the Github repo for the code examples discussed below.

SWR

From the previous discussions, we see that there are pros and cons with each data fetching method. Could there be a method that is both performant and easy to use? Enter SWR.

SWR is a relatively recent library created by Vercel, the same team that created NextJS. SWR stands for stale-while-revalidate.

SWR promises

to supply data to components constantly and automatically. And the UI will be always fast and reactive.

To make the data fetching really easy, SWR provides useSWR hook which accepts an API url and a callback function (fetcher) and then it returns data and error. There is also an option for suspense:true with useSWR hook, which allows for integration with the React Suspense API.

React Suspense API will wait for the data to finish loading before showing the UI to a user. While waiting, a fallback component, such as <Loading /> will be shown to the user.

To make the code reusable and avoid prop-drilling, we can perform the data fetching in a custom hook (useUsers), as below. We have to first define a fetcher function, where the getUsers function will reside. The fetcher function will then be passed as a callback function to the useSWR hook.

const fetcher = async (apiURL:string) => {
    try{
        const {results:data} = await getUsers(apiURL)
        return data.map((user:UserApi) => ({
            id: user.id.value,
            firstName: user.name.first,
            lastName: user.name.last,
            username: user.login.username,
            email: user.email,
        }))
    } catch(error) {
        throw new Error("unable to fetch data")
    }
}

const useUsers = () => {
    const {data, error} = useSWR(apiURL, fetcher,{suspense:true})

    return ({
        users: data,
        loading: !data && !error ? true : false,
        error: error
    })
}

export default useUsers;

With the useUsers hook set up, any react component will now have access to the users state through the useUsers hook, as below.

export default function CardList() {
  const { users } = useUsers()

  return (
    <div className="grid sm:grid-cols-2 md:grid-cols-3 lg:grid-cols-4 justify-center grid-cols-1 mt-8">
      <Suspense fallback={<Loading />}>
        {users.map((user:User) => (<CardItem key={`${user.id}${user.email}`} user={user}/>))}
      </Suspense>
    </div>
  )
}

Pros

As you can see from the codes above, useSWR greatly simplifies the complexity of the initial code set up to fetch data, and this is done without compromising on performance (it is incredibly performant!).
Besides the advantages above, SWR also provides other utilities such as data refetching & prefetching, conditional fetching, caching and data refresh interval config.

Now, at this point, I would also like to introduce an alternative library that provides similar utilities as SWR - React Query.

To be continued:

React Query

For more information on SWR, see here.

If you like the content, please hit the like button so that it can reach more people.

React Data Fetching Pattern - Part V

Francisldn — Wed, 16 Nov 2022 16:30:18 +0000

This article is a continuation of:

Click here to access the Github repo for the code examples discussed below.

React Query

An alternative React data fetching library that provides similar utilities as SWR is React Query.

React Query provides a hook called useQuery which accepts a query key and a callback function (fetcher). Similar to SWR, it also allows for integration with React Suspense API by simply including the option suspense: true. If the fetcher callback requires a parameter (eg: URL), we can include this as a 2nd item in the array after the query key. useQuery will return data, isLoading, error, isError to be accessed by React components.

To allow for code reusability and avoid prop-drilling, we can create a custom hook to perform the logic of data fetching using React Query, as below.

const fetcher = async(apiURL:string) => {
    try {
      const {results: data} = await getUsers(apiURL)
      return data.map((user:UserApi) => ({
          id: user.id.value,
          firstName: user.name.first,
          lastName: user.name.last,
          username: user.login.username,
          email: user.email,  
      }))
    } catch(error) {
      throw new Error('unable to fetch data')
    }
}

const useUsers = () => {
    const {isLoading, isError, data, error} = useQuery(['users',apiURL], () => fetcher(apiURL),{suspense: true})

    return ({
        users: data,
        isLoading,
        isError,
        error
    })
}

export default useUsers;

Before we can access the data in any React component, we have to wrap the QueryClientProvider around the top-level component (<App />).

import { QueryClientProvider, QueryClient } from 'react-query';

const queryClient = new QueryClient()

const root = ReactDOM.createRoot(
  document.getElementById('root') as HTMLElement
);
root.render(
  <React.StrictMode>
    <QueryClientProvider client={queryClient}>
      <App />
    </QueryClientProvider>
  </React.StrictMode>
);

Within React component, we can now access the users state from useUsers hook, as below.

export default function CardList() {
  const {users} = useUsers()

  return (
    <div className="grid sm:grid-cols-2 md:grid-cols-3 lg:grid-cols-4 justify-center grid-cols-1 mt-8">
      <Suspense fallback={<Loading />}>
        {
          users.map((user:User) => (<CardItem key={user.id} user={user}/>))
        }
      </Suspense>
    </div>
  )
}

Pros

Similar to SWR, the initial code set-up is relatively easy and it is also performant.

For more information on React Query, see here.

I hope these article provides valuable information to you as a React developer.

If you like the content, please hit the like button so that it can reach more people.

React Data Fetching Patterns - Part I

Francisldn — Wed, 16 Nov 2022 12:09:23 +0000

In React, data fetching from an external API typically involves a few steps, as below:

send a fetch request
await for response
receive the requested data or error

In this article, we will first discuss how data fetching is traditionally done in React using useState-useEffect hooks. We will then proceed to discuss other data fetching patterns, utilising Suspense - an API made available in React v18 (no longer experimental), as follows:

Click here to access the Github repo for the code examples discussed below.

How data fetching is traditionally done

In React, we traditionally perform data fetching using useState-useEffect hooks. Within a React component, a state is created using useState hook to store data. useEffect hook is executed as the component first mounts or page first renders. The data fetching logic in the useEffect hook will run and data will be stored as a state.

Let's go through the code:

users state is declared with useState, together with loading and error states
Within useEffect, getUsers function will execute on component mounts, and the loading state will set to true while waiting for data to be retrieved
On successful data retrieval, the loading and error states will set to false, and users state will contain the retrieved data, ready for UI rendering.

export default function CardList() {
    const [users, setUsers] = useState<User[]>([])
    const [isLoading, setLoading] = useState(false)
    const [isError, setError] = useState(false)

    useEffect(() => { 
        setLoading(true)  
        getUsers(apiURL)
            .then(({results:data}) => {
                setUsers(
                data.map((user:UserApi) => {
                    return {
                        id: user.id.value,
                        firstName: user.name.first,
                        lastName: user.name.last,
                        username: user.login.username,
                        email: user.email,
                    }}))
                })
            .catch(() => setError(true))
            .finally(() => setLoading(false))
    },[])

  return (
    <div className="grid sm:grid-cols-2 md:grid-cols-3 lg:grid-cols-4 justify-center grid-cols-1 mt-8">
        {isLoading 
        ? <Loading />
        : isError 
        ? <ErrorFallBack />
        : users.map((user:User) => (<CardItem key={user.id} user={user}/>))
        }
    </div>
  )
}

Downsides

Prop-drilling
While this data fetching pattern works fine for a local component, if there were multiple components that require access to the same set or a subset of the data, then we will need to pass the props through multiple child components, which could lead to problems of prop-drilling. For a larger app, prop-drilling through multiple layers of components can make the app unwieldy and hard to manage.

To overcome the issues outlined above, let's proceed to look at a few other data fetching methods, as below.

To be continued:

If you like the content, please hit the like button so that it can reach more people.

Managing State with React useContext

Francisldn — Sun, 24 Apr 2022 17:52:12 +0000

This is a short post to explain how one can use React useContext hook to create global state variables, thus allowing for props to be passed onto different components easily and avoiding "prop-drilling".

Set up Context file

Create a context component using createContext

import {createContext, useState} from 'react'

export const LoginContext = createContext({});

Wrap components with `Context.Provider`

Wrap all components within LoginContext. All components will have access to the LoginContext props.
Note that the props are passed in using {{double curly braces}}.

import {LoginContext} from './Context'

export function App() {
  const [loggedIn, setLoggedIn] = useState(false)

  return(
    <LoginContext.Provider value={{loggedIn, setLoggedIn}}>
       <Home />
       <Login />
       <Profile />
    </LoginContext.Provider>
  )
}

Passing props to components

Pass loggedIn and setLoggedIn to Login component
Login component can access the props from LoginContext through useContext
Note the use of {curly braces} instead of [square brackets] for props destructuring.

import {LoginContext} from '../Context';
import React, {useContext} from 'react';

export const Login = () => {
   const {loggedIn, setLoggedIn} = useContext(LoginContext);

   return (
      <div>
         <button onClick={() => setLoggedIn(!loggedIn)}>Click 
           here to login
         </button>
         {loggedIn? <h1>You are logged in</h1>: <h1>You are 
         not logged in</h1>}
      </div> 
   )
}

5 Tips & Tricks for DeFi Developers from the UniswapV2 Contracts Review

Francisldn — Sat, 22 Jan 2022 15:44:29 +0000

Uniswap announced their V2 launch on Ethereum mainnet on 18 May 2020, followed by the V3 launch on 5 May 2021. With a total value locked (TVL)of USD 7.4 billion (as of 21 Jan 2022), Uniswap V2 accounted for slightly more than half of the total Uniswap TVL (USD 3.6 billion), with an average daily trading volume of around USD 500 million. Clearly, Uniswap V2 remains a highly popular decentralised exchange (DEX) among DeFi users.

Having recently reviewed the Uniswap V2 contracts, I found the contracts full of gems which are worth sharing with fellow DeFi smart contract developers.

Brief Overview of Contracts

Uniswap V2 contracts are organised into V2 Core and V2 Periphery. V2 Core consists of the essential V2 smart contracts, including UniswapV2Pair, UniswapV2Factory and UniswapV2ERC20. V2 Periphery consists of a set of helper contracts or functions which include UniswapV2Migrator, UniswapV2Router and a number of libraries.

UniswapV2 Core

UniswapV2Pair - responsible for the maintenance of liquidity pool and token swapping functionality.
UniswapV2Factory - responsible for the creation of token pair liquidity pools and the setting of liquidity provider fee.
UniswapV2ERC20 - implements the ERC20 token interface but with an additional feature, this is something which I will explore a bit more later.

UniswapV2 Periphery

UniswapV2Router01 and 02 - acts as a wrapper for V2Pair, handling liquidity addition and removal operations and token swapping functionalities.
UniswapV2Migrator - provides liquidity migration service from Uniswap V1 to V2.

Review of Source Code

Below are some of the interesting tips and tricks implemented in UniswapV2.

1. ERC-20-Permit - a gas-efficient version of ERC-20

With a standard ERC-20 token, a tokenholder needs to execute approve transaction prior to executing transferFrom. The approve function must be performed by an Externally-Owned Wallet (EOA) and this is meant to protect user's wallet from being drained by a malicious contract. But this also leads to degradation of user experience, as it means that a user would need to execute 2 transactions: approve and transferFrom to transfer a token, which is not gas-efficient. So can we implement a more gas-efficient version of ERC20 token while retain the security for user's funds?

Solution: With the addition of permit function, Uniswap implements offline signature for the approval of token transfer, which is gas-less. The signature can then be used for on-chain execution of transferFrom function (or any other functions). The permit function is also used in the V2 Router contract for user to withdraw liquidity from a liquidity pool (eg.removeLiquidityWithPermit function).

To prevent replay attack using the same signature multiple times (given it is done off-chain), a valid signature would consist of a few safeguards such as a clear definition of scope for the signature as defined in DOMAIN_SEPARATOR and PERMIT_TYPEHASH with non-reusable nonce which increments with every signature. The signature uses EIP-712 standard for signing and the ERC-20 implementation of permit extension follows EIP-2612 standard.

Smart contract developers who are interested in implementing or learning more about ERC-20-Permit may refer to the resources below:

2. CREATE2 - creation of pair addresses

There are 2 ways to create a new contract on EVM-compatible chain - CREATE and CREATE2. In the UniswapV2Pair contract, CREATE2 opcode (in assembly) is used to create a token pair liquidity pool address, which is a change from the V1 contract (where CREATE is used).

CREATE opcode is used to compute deployed contract address like so:

keccak256(senderAddress, nonce)

In Solidity, one can also create a new contract through new keyword, as below. Instantiating a new contract in this way uses the CREATE opcode, and contract address cannot be pre-determined in a deterministic manner (due to the use of nonce).

pair = new UniswapV2Pair()

CREATE2 opcode computes pre-determined contract address like so:

keccak256(0xFF, senderAddress, salt, bytecode)

0xFF is a constant to prevent collision with the CREATE function
senderAddress - sender's own address
salt - an arbitrary value provided by the sender
bytecode - contract's bytecode to be deployed

The advantage of CREATE2 vs CREATE is that with CREATE2, contract address can be pre-computed off-chain (therefore gas-less) and one can then send ETH to the pre-computed contract address even before the contract is deployed on-chain. One such use case is that a developer may distribute a pre-computed contract address to a user in advance without having to deploy the contract, and the contract can then be initialised when a user starts sending funds to it, thus allowing for gas fee saving.

To learn more about deploying contract using CREATE2, below are some resources for your reference:

3. Time-Weighted Average Price update

In the UniswapV2Pair contract, token prices are updated based on time-weighted average prices (TWAP) mechanism. The way it works is that each transacted price is weighted by the time that has passed since the last block in which it was updated and the historical prices are then accumulated. This increases the difficulty and reduces the incentive to manipulate prices on Uniswap, especially for tokens with high trading volume. This is an improvement from Uniswap V1. The diagram below gives a good overview of the TWAP price mechanism (courtesy of Uniswap).

Given the improvement in price update mechanism in V2, which is more resistant to price manipulation, Uniswap V2 can therefore serve as an on-chain price oracle for other DApps. Uniswap has actually created the UniswapV2OracleLibrary exactly for such purpose.

Implications
As the token prices are not updated based on the actual reserve balance in the liquidity pool, there will exist discrepancies between the token balance calculated based on TWAP mechanism and the actual reserve balance. There are also tokens with deflationary or inflationary implementations which could lead to discrepancies in token balances. Tokens with balances greater than 2¹¹² will also lead to overflow of the storage slots for reserves, which could lead to failed trades. For all the cases mentioned above (not exhaustive), users can withdraw excess token balances or reserves through skim and sync functions.

4. Fixed Point Binary Library (UQ112x112.sol)

library UQ112x112 {
    uint224 constant Q112 = 2**112;

    // encode a uint112 as a UQ112x112
    function encode(uint112 y) internal pure returns (uint224 z) {
        z = uint224(y) * Q112; // never overflows
    }

    // divide a UQ112x112 by a uint112, returning a UQ112x112
    function uqdiv(uint224 x, uint112 y) internal pure returns (uint224 z) {
        z = x / uint224(y);
    }
}

Problem: Solidity lacks support for non-integer numeric types (such as fractions)

Solution: To overcome the problem above, Uniswap V2 uses the above library to handle fixed point binary numbers for updating prices. With fixed point binary numbers, there is a trade-off between range and precision, the higher the range of numbers, the lower the precision. In the case of Uniswap, the fixed point binary numbers are implemented as uint224, where the first 112 bits represent integers and the last 112 bits represent decimals. This means the numbers would have a range of [0, 2¹¹²-1] and a precision of ¹⁄112.

Readers who would like to learn more about fixed point binary numbers may refer to the excellent explanation in the video below:

Fixed Point Binary Fractions

5. Lock

uint private unlocked = 1;

    modifier lock() {
        require(unlocked == 1, 'UniswapV2: LOCKED');
        unlocked = 0;
        _;
        unlocked = 1;
    }

Uniswap uses the lock modifier as a measure to prevent reentrancy attack. The most high profile reentrancy attack occurred in 2016 where the attacker drained 3.6 million ether from The DAO.

The lock modifier prevents reentrancy attack by setting the initial value of unlocked state variable to 1. Once a function with lock modifier is executed, the unlocked state variable value will be set to 0. To reenter the contract, the unlocked state variable is required to be == 1, thus preventing reentrancy. The unlocked state variable value will return to 1 upon successful execution of the function or failed execution (reversion to original state). Uniswap applies the lock modifier to all the UniswapV2Pair functions that perform external calls, such as mint, burn, swap and skim.

Developers may also refer to the Openzeppelin contract suite for a similar implementation of reentrancy guard.

Further resources:

If you like the content, please hit the like button so that it can reach more people.

DEV Community: Francisldn

Be Grateful for Rejections - Anecdotes about Rejections in Job Hunting Process

React Data Fetching Pattern - Part III

Redux createAsyncThunk

Pros

Cons

React Data Fetching Patterns - Part II

Custom Hook using React Context API

Pros

Cons

React Data Fetching Pattern - Part IV

SWR

Pros

React Data Fetching Pattern - Part V

React Query

Pros

React Data Fetching Patterns - Part I

How data fetching is traditionally done

Downsides

Managing State with React useContext

Set up Context file

Wrap components with Context.Provider

Passing props to components

5 Tips & Tricks for DeFi Developers from the UniswapV2 Contracts Review

Brief Overview of Contracts

UniswapV2 Core

UniswapV2 Periphery

Review of Source Code

1. ERC-20-Permit - a gas-efficient version of ERC-20

2. CREATE2 - creation of pair addresses

3. Time-Weighted Average Price update

4. Fixed Point Binary Library (UQ112x112.sol)

5. Lock

Wrap components with `Context.Provider`