DEV Community: KT

Breaking Into Japan’s Tech Industry: My experience breaking into IT from being an ALT (assistant English teacher)

KT — Tue, 04 Mar 2025 09:34:56 +0000

TL;DR:
I share my journey from working as an ALT (Assistant Language Teacher) in Japan to becoming a self-taught web developer. I retell of the challenges I faced navigating the tech job market here—especially the pitfalls of SES/SIer companies—and offer advice for those looking to break into IT. If you're starting out, this post highlights what I wish I’d known before diving in.

I wanted to write about the tech landscape for those looking to start out as a self-taught web developer in Japan. From my own experience, I’ve noticed there aren’t many detailed articles covering this topic—aside from a few Reddit discussions. There are a lot of things that aren’t talked about enough, including the challenges and traps that newcomers might face.

So, I want to share my journey—how I got started as a web developer in Japan and what I’ve learned along the way. I’ll also go over things to be aware of when looking for your first company, so you can avoid potential missteps and make better decisions.

A bit about myself

I came to Japan in 2018 as an ALT (Assistant Language Teacher). It was an experience I genuinely enjoyed—getting to explore Japan’s countryside, immersing myself in the culture, and engaging with students in a meaningful way. One of the best parts was feeling like I was making a difference in their learning.

Of course, being an ALT also came with a fair amount of downtime between lessons. I used that time to study for the JLPT (Japanese Language Proficiency Test), first passing N2 and then eventually N1. Once I had finished my language studies, I found myself wanting to learn something new.

That’s when I got interested in web development. Seeing how websites and web apps worked—and being able to build something interactive from scratch—seemed really cool to me. I’d always had an interest in tech since I was a kid, but I never pursued it seriously (mostly because I thought math would be a big part of it, and calculus was not my thing). To my relief, I quickly realized that advanced math isn’t really necessary for web development.

I took an online course for six months, covering the basics—HTML, CSS, JavaScript, Git, GitHub, and all the essential tools needed to start building projects. I used every resource I could find: Udemy, The Odin Project, YouTube tutorials... anything that could help me learn.

Near the end of my course, I had built enough projects to get comfortable with web development. I enjoyed working with React, so most of my projects were based on it. I also found myself really enjoying the styling and design aspects—it was fun making things look good while keeping them functional.

My First Programming(?) Job After Being an ALT

Oooh boy. The few months leading up to the end of my ALT contract were brutal. I was firing off applications left and right to every developer job listing I could find online. But most postings—especially on LinkedIn—were looking for mid to senior-level developers with at least 3+ years of experience.

It was tough. Really tough.

There were barely any entry-level English speaking dev jobs, and the only entry-level ones that existed were mostly at Japanese companies listed on recruitment sites like En Tenshoku, Doda, and Type. Unfortunately though, Japanese is required in these type of companies.

At first, I was amazed by how many “entry-level” programming jobs there seemed to be. Japan must really need a lot of developers! But despite the sheer number of listings, I struggled to secure an actual job offer. I got plenty of interviews, though, which at least meant my resume was good enough to catch attention.

Falling Into the SES/SIer Trap

Eventually, I landed a job at a small startup IT company and was excited to finally begin my Frontend development journey! Or so I thought.

At the time, I had no idea how most local Japanese IT companies actually worked. What I had signed up for was an SES (System Engineering Service) / SIer (System Integrator) company.

Quick explainer: These companies don’t actually do development work in-house. Instead, they hire engineers and “rent” them out to client companies as temporary workers. So instead of being assigned to internal projects, you're basically a contractor, waiting for a client to pick you up.

My First Day

On my first day, I arrived at the office expecting to be assigned to a front-end project. Instead, I was asked to:

Get my picture taken
Record a self-introduction video
Fill out a skill sheet

I was confused. Wait, I thought I'll be assigned to a project straight away? Am I job searching again?

Turns out, I had to go through another round of interviews—this time with potential client companies. These were arranged by my account manager, who basically acted as a middleman trying to “sell” me to clients.

A bit odd… but I figured as long as I can land a Frontend development project, I’d be fine.

My “Programming” Assignments (Or Lack Thereof)

I was on standby for almost a month, using the time to polish my skills while waiting for an interview. And then…

My first assignment? Updating POS registers at a supermarket chain.

Job description: Follow a manual and install new software on registers.
Schedule: Graveyard shift. Twice a week.
Programming involved? None.

Not exactly what I imagined for my first “dev job.”

Still, I figured it was just the start. I put up with it for two months before being placed on standby again.

Next assignment? Working at a PC recycling company, wiping and refurbishing old business/consumer PCs.

I started asking my account manager when I’d actually be assigned to a Frontend development role. His response? “There just aren’t any frontend projects available right now unfortunately.”

Then, to make things even worse, they tried to assign me to:

Another kitting job
A call center role
A project management position

That was it. I had enough.

Escaping the SES Cycle

At this point, I realized I was wasting my time and immediately started job hunting again. Eventually, I landed a position at another Japanese startup—this time, as a real Frontend Developer.

It wasn’t exactly smooth sailing (I’ll write another post about that), but at least I was finally in the field I had worked so hard to break into.

Final Thoughts & Advice

I'll be honest—I was naive. I didn’t do proper research on SES companies before joining one, and looking back, I wish I had been more informed. After leaving, I started digging deeper into how these companies operate, watching YouTube videos, reading reviews, and hearing others’ experiences. Many SES companies can be sketchy, and I should have been more cautious. But at the time, I was desperate for a job and needed a way to stay in Japan.

So, if you're looking to start your IT career in Japan, here’s what I’ve learned:

Prioritize international companies (called Gaishikei (外資系). They generally offer better salaries, work-life balance, and career growth opportunities.
Get your JLPT N2 or N1. This is very important as your personal projects on Github alone won't make you stand out without the language skills for workplace communication.
Look for 自社開発 (jisha kaihatsu) in job listings. This means the company works on its own internal projects, rather than dispatching employees to clients.

However as a disclaimer, not ALL of Japanese companies are terrible, as well as not ALL of international companies are perfect. You just need to use your intuition and look up the companies in detail as much as you can.

If You’re Considering an SES Company… Be Careful

If you’re set on joining an SES company, do your homework. Here’s what to watch out for:

During the interview, ask how likely you are to be placed in a project that matches your skills and the guaranteed chance of getting it. If they dodge the question or give some vague answer, that’s a red flag.
Pay attention to the vibe of the people interviewing you. If the recruiter, CEO, or engineers seem uninterested, unprofessional, or just gives off bad vibes, it may not be the place you want to work at. My interviewer looked grumpy and he didn't exactly make the interview comfortable—should’ve taken that as a sign.
Research the company on review sites:
転職会議 (Highly recommended)
OpenWork
enひょうばん

Use Google Translate if needed, and take note of recurring negative reviews. I know some reviews can be very exaggerated but there is always a grain of truth in them.

Check the company size and number of employees. A small size company could mean a lot of pressure and low quality jobs (hence lower chance of ending up with the type of project that you want to belong in)
Look at their overtime policy. In Japan, overtime is unfortunately mostly unavoidable, so avoid companies that list 30+ hours per month.

I hope my experience gives you some insight into the IT job market in Japan and helps you navigate it more smoothly. My goal with this blog is simply to share what I’ve learned and offer a fair bit of caution for those starting out. If this helps even one person avoid the traps I faced, then it’s worth it.

Lessons Learned from Tackling a Frontend Mentor Project: Coffee Roasters themed Edition

KT — Mon, 01 May 2023 01:20:18 +0000

Hey everyone! I recently took on a project challenge from Frontend Mentor and wanted to share my learnings with you all. The design files were provided, and I had the freedom to choose whichever tech stack I wanted to use and modify it as I pleased.

Being a coffee addict, I was immediately drawn to the coffee-themed design of the project. Not only did it look amazing, but it was also an excellent opportunity for me to practice using React Router since I was just starting to learn routing.

I've been working on this project for some time now, and it's become one of my main focuses for implementing various features and concepts that I have learned. I even took on the challenge of rewriting the project in TypeScript, which helped me become more familiar with the language.

Recently, I've been exploring testing in React using Jest, and let me tell you, it was a challenging process! I had to work through the complexities of configuring the testing environment with TypeScript, but it was worth it because I learned some valuable skills that will come in handy in the future.

Main Challenge

When I was building this website, I faced a major challenge while trying to accommodate the edge cases of the challenge. One of the tasks provided was to calculate prices based on various factors like order frequency and quantity of beans, when a user clicks on a subscription option. Initially, I planned to map the subscription options and render multiple instances of it, but that turned out to be quite difficult. There were multiple factors dependent on each other to calculate prices dynamically.

Eventually, I decided to revise my original solution of mapping all the subscription option sections. Instead, I created separate sections to handle this complex calculation.

           <Method
                id="method"
                plan={planOption[0]}
                onHoldChoice={(id: string, event: MouseEvent) =>
                  holdChoice(planOption[0].id, id, event)
                }
                onButtonClick={handleCoffeeMethodBtn}
              />
              <CoffeeType
                id="coffee-type"
                plan={planOption[1]}
                onHoldChoice={(id: string, event: MouseEvent) =>
                  holdChoice(planOption[1].id, id, event)
                }
                onButtonClick={handleCoffeeTypeBtn}
              />
              <Amount
                id="amount"
                plan={planOption[2]}
                onHoldChoice={(id: string, event: MouseEvent) =>
                  holdChoice(planOption[2].id, id, event)
                }
                onButtonClick={handleAmountBtn}
                onSetWeight={setWeightBoolean}
              />
              <Grind
                id="grind"
                plan={planOption[3]}
                isCapsule={isCapsule}
                onHoldChoice={(id: string, event: MouseEvent) =>
                  holdChoice(planOption[3].id, id, event)
                }
                onButtonClick={handleGrindTypeBtn}
              />
              <Delivery
                id="delivery"
                plan={planOption[4]}
                onHoldChoice={(id: string, event: MouseEvent) =>
                  holdChoice(planOption[4].id, id, event)
                }
                onButtonClick={handleDeliveryBtn}
                onSetFrequency={setFrequencyBoolean}
                weight={weight}
              />

This snippet of code below was an example of one of the challenges presented by the project. Specifically, it tackled the task of calculating shipping prices based on the customer's chosen frequency and weight.

 function displayShippingPrice() {
    let price: number;
    if (frequency.isWeekSelected && weight.firstWeight) {
      price = 7.2 * 4;
    } else if (frequency.isFortnightSelected && weight.firstWeight) {
      price = 9.6 * 2;
    } else if (frequency.isMonthSelected && weight.firstWeight) {
      price = 12.0;
    } else if (frequency.isWeekSelected && weight.secondWeight) {
      price = 13.0 * 4;
    } else if (frequency.isFortnightSelected && weight.secondWeight) {
      price = 17.5 * 2;
    } else if (frequency.isMonthSelected && weight.secondWeight) {
      price = 22.0;
    } else if (frequency.isWeekSelected && weight.thirdWeight) {
      price = 22.0 * 4;
    } else if (frequency.isFortnightSelected && weight.thirdWeight) {
      price = 32.0 * 2;
    } else if (frequency.isMonthSelected && weight.thirdWeight) {
      price = 42.0;
    } else {
      price = 0;
    }
    setShippingPrice(price);
  }

  useEffect(() => {
    displayShippingPrice();
  }, [weight, frequency]);

Since there were multiple variables that were dependent on each other, it was challenging to implement the necessary conditional logic when mapping over the elements.

Of course there's more! I didn't want to just stuff all my learnings into a readme doc, so I decided to share them with you all in this blog post. If you're interested, here are the links to my key takeaways:

Thanks for reading, and I hope my learnings help you in your front-end development journey!

Building Stronger Foundations with TypeScript: Insights and Takeaways

KT — Mon, 01 May 2023 01:15:54 +0000

A few months ago, I set out to learn TypeScript, as I had heard that it was a highly sought-after skill in Frontend jobs. Initially, I was intimidated by the idea of learning a whole new language, and I thought I needed to be extremely comfortable with my JavaScript skills before diving in. However, to my surprise, TypeScript was more similar to JavaScript than I had anticipated. The only difference was that TypeScript allowed me to declare types to my variables, providing an extra layer of safety to my code.

As I progressed in my TypeScript learning journey, I discovered that it had several benefits that greatly enhanced my understanding of JavaScript and made my code more robust:

Reinforcing main concepts
TypeScript really helped reinforce the basic concepts of JavaScript, such as primitives, as well as learning other concepts such as Tuples, Unions, interfaces, and types, and many more!
Preventing errors as early as possible
TypeScript caught many potential errors that could have happened instantly, rather than finding out the errors during build time or after creating a long function and later testing it out to find that the function broke the app and after debugging for many hours.
Making your code more readable
TypeScript gives better context and readability to your code. With all of the data, functions, and variables flowing in your code, it just makes it easier for another person to go into your code and understand it once the types for these data are declared. It also helps a lot for when you revisit an old project that you haven't touched for a long time and become familiar with it quickly.

Interfaces and Type Aliases

When working with TypeScript, there are a few key tools that I rely on heavily. At the top of that list are interfaces and type aliases. These features have been a game-changer for me when defining complex data structures that have multiple nested properties.

In the past, it was all too easy to get lost in the code and lose track of what data was being passed around. However, with interfaces and type aliases, I can easily define a clear and concise structure for my data. This makes it much easier to read, understand, and maintain my code over time.

When defining an interface, you use the interface keyword to specify the shape of the object and declare the types of each property. This allows you to easily understand what data is being passed and what data types are used. For example, consider the following interface for an Apple object:


interface apple {
  color: string;
  noOfSeeds: number;
  isExpensive: boolean;
  kinds: string[]
}

In this case, the Apple interface specifies that an Apple object has three properties: color, size, and isTasty, with their respective data types.

Type aliases work in a similar way, but instead of using the interface keyword, you use the type keyword. For instance, you can create a type alias for the Apple interface as follows:


type apple = {
  color: string;
  noOfSeeds: number;
  isExpensive: boolean;
  kinds: {
    name: string,
    latinName: string,
  }[]
}

Type aliases can also be used within an interface to simplify and shorten the code. For instance, consider the following example:


type AppleKinds {
  name: string,
  latinName: string,
}


interface Apple {
  color: string;
  noOfSeeds: number;
  isExpensive: boolean;
  kinds: AppleKinds[];
}

In this way, we have defined the AppleKinds type once and can reuse them within the Apple interface

Key Difference

Through my studies, I discovered a significant difference between type aliases and interfaces - interfaces can be extended, but type aliases cannot. This means that interfaces can inherit the properties of another interface and add new properties, methods, or index signatures to it.

Here's an example of how to extend an interface:


interface Fruit {
 shape: string;
 organic: boolean;
 country: string;
}

interface Apple extends Fruit {
  color: string;
  noOfSeeds: number;
  isExpensive: boolean;
  kinds: AppleKinds[];
}

In this example, the Apple interface is created by extending the Fruit interface and adding new properties such as color, noOfSeeds, isExpensive, and kinds.

On the other hand, trying to extend a type alias would result in an error:


interface Fruit {
 shape: string;
 organic: boolean;
 country: string
}

type Apple extends Fruit {
  color: string;
  noOfSeeds: number;
  isExpensive: boolean;
  kinds: AppleKinds[];
}

//Error log: error TS1110: Type expected.

Since type is used to create a new type, rather than extend an existing one, extending a type alias in this way is not allowed.

To conclude, while there is still much more to learn about TypeScript, I am excited to continue exploring its various features and concepts in my learning journey as I work on new projects. By using TypeScript in my projects, I was able to solidify my understanding of its basic concepts and appreciate the many benefits it offers for developers, including preventing errors early on, reinforcing main concepts, and making code more readable. As I continue to work with TypeScript, I look forward to discovering even more ways it can improve my development workflow and create better, more reliable projects.

Thank you for reading!

Image credit by Image by pikisuperstar on Freepik

Keeping state of data within localStorage in React

KT — Tue, 25 Apr 2023 04:28:59 +0000

So I was working on a feature that would allow users to save their progress with flashcards. However, I ran into a problem where refreshing the page or navigating away from it would reset the number of revised cards to its original state. As you can imagine, this was frustrating and took me nearly a week to figure out.

After trying a few different solutions, I decided to use localStorage to store the modified state of the deck array within each flashcard component. This way, the component would use the stored data instead of reusing the original data that was passed down. This approach worked well for the "revise all cards" section, but I still had some trouble with individual sets.

For one of my sets, my initial solution was:

  useEffect(() => {
   localStorage.setItem(`cardDeckSet`, JSON.stringify(cardDeck));
   }, []);

However, I ran into a bug. When I entered another flashcard set (for example, going from Set 1 to Set 2) and then went back to Set 1, the same updated flashcard set from Set 1 would be shown again. It was really frustrating because I couldn't figure out what was causing the problem.

Eventually, I realized that since there were multiple instances of the same component, storing the current state data in just one item in localStorage meant that ALL of the other flashcard components would get the same state. That was a bit of a facepalm moment for me!

After spending a lot of time brainstorming a solution, I finally came up with an idea. I decided to make multiple cardDeckSet items in local storage, like so:

  useEffect(() => {
   localStorage.setItem(`cardDeckSet${setNumber}`, JSON.stringify(cardDeck));
   }, []);

This solution worked but the next problem I encountered was that there was a discrepancy in setting the updated state in localStorage.

useState is asynchronous

After some debugging, I realized that the issue was related to the asynchronous nature of useState in React.

When I tried calling setCardDeck to update the state of cardDeck in my component, the change doesn't happen immediately. Instead, it schedules a state update and re-renders the component on the next cycle. This means that when I called localStorage.setItem right after setCardDeck, it was still using the old value of cardDeck from the previous render cycle.

To fix this issue, I needed to find a way to ensure that localStorage was updated with the most recent state of cardDeck. After some experimentation, I found a solution by inserting the code for saving the state of the cards within the vocabLearnt() and reviseVocab() functions of my custom hook:


//For reference
const [cardDeck, setCardDeck] = useState(incomingDeck);

function vocabLearnt(storageItem: string) {
    //The current position of the card at this time
    const cardToRemove = cardDeck[cardIndex];
    const newDeck = cardDeck.filter((card) => card.id !== cardToRemove.id);
    setCardDeck(newDeck);
    // To store current state of deck
    localStorage.setItem(storageItem, JSON.stringify(newDeck));
  }

  function reviseVocab(storageItem: string) {
    const cardToRemove = cardDeck[cardIndex];
    const newDeck = cardDeck.filter(
      (card: { id: string }) => card.id !== cardToRemove.id
    );
    // To store current state of deck
    localStorage.setItem(storageItem, JSON.stringify(newDeck));

    //To make sure same cards are not being added
    const vocabToLearnArr = vocabToLearn.find(
      (card) => card.id === cardToRemove.id
    )
      ? [...vocabToLearn]
      : [...vocabToLearn, cardToRemove];
    setCardDeck(newDeck);
    setVocabToLearn(vocabToLearnArr);
  }

In conclusion, after exploring different options to keep track of the user's progress with the flashcards, I decided that the best solution for my app is to use localStorage.

The app will mainly be used within my school, so it's important to keep it as accessible as possible. Using localStorage allows me to store the state of the flashcards even if the user refreshes the page or moves to another page within the app.

I did consider sessionStorage as an alternative, but I need the data to persist even after the user closes the app or the browser. So for my purposes, localStorage is the most suitable solution.

Of course, as my app grows and evolves, I may need to explore other options in the future. But for now, I'm happy with the decision to use localStorage to keep track of the user's progress with the flashcards.

Thanks for the read!

Use Firebase? localStorage? Or both?

KT — Mon, 24 Apr 2023 12:39:58 +0000

During my coding journey, creating this app allowed me to put into practice all the concepts I have learned. Specifically, I took the opportunity to become more proficient in using styled components and React Router, two essential tools for React development.

As I developed the app, one of the most significant challenges I encountered was determining the best way to store flashcard data and track their state. The purpose of the app was to help students revise vocabulary they had learned since third grade from their textbooks.

Initially, I considered uploading every single flashcard to Firebase. However, I soon realized that this approach would be overly complicated and burdensome. Additionally, it would require each student to create a registered account and log in, which would create significant hassle, especially since the app's goal was to be simple and straightforward.

After exploring various options, I decided to use localStorage as the most accessible and straightforward solution for students to track their flashcard revision progress. The main master deck would be stored in Firebase and only be accessible to teachers.

Implementing the Firebase feature presented a challenge since I was not very familiar with the technology. However, I eventually succeeded in uploading the master deck to Firebase and retrieving the main data. This achievement was one of the project's highlights.

 /* Upload initial data to Firebase */
  function writeFlashcardData(decks: FlashcardSetData[]) {
    const db = getDatabase();
    set(ref(db, 'flashcards'), {
      decks,
    });
  }

  /* Fetching flashcard from Firebase*/
  const fetchFlashcardHandler = useCallback(async () => {
    setIsLoading(true);
    setError(null);
    try {
      const response = await fetch(
        'https://english-flashcards-app-962bb-default-rtdb.asia-southeast1.firebasedatabase.app/flashcards.json'
      );
      if (!response.ok) {
        throw new Error('An error has occurred');
      }

      const data = await response.json();
      setDeck(data.decks);

      // Obtain all of the cards arrays, join them and flatten it
      const decksArr = [];
      for (let i = 0; i < data.decks.length; i++) {
        decksArr.push(data.decks[i].cards);
      }
      const flattenedDecksArr = decksArr.flat();
      setAllCards(flattenedDecksArr);
    } catch (error: any) {
      setError(error.message);
    }
    setIsLoading(false);
  }, []);

  useEffect(() => {
    if (deck.length === 0) {
      writeFlashcardData(deckData);
      fetchFlashcardHandler();
    }
  }, [deck.length]);

Hoping to implement user authentication for the teachers to login in the future using Firebase!

My learning journey through my English Flashcard Project

KT — Mon, 24 Apr 2023 09:01:17 +0000

Hey hey, friends! I'm super excited to share with you a project I've been working on - a flashcard app for my school!.
My co-teacher was manually printing and attaching flashcards, which seemed like a lot of work. So, I decided to use my coding skills to create an app that would make studying easier for everyone.

I used React, React Router, styled-components, and TypeScript to build the app. It was definitely a challenge, but it was so rewarding to see everything come together in the end. I loved using TypeScript to catch all my errors early on - it definitely saved me a lot of time and headaches.

Overall, it was an awesome learning experience. Seeing the app build successfully was a major win for me, and I'm excited to share it with my school and anyone else who wants to study smarter, not harder!

Oh, and before I forget, I picked up a some key takeaways from this project that I think you'll find useful!

1. Understanding the difference between useContext and creating your own custom hooks

2. Use Firebase? localStorage? Or both?

3. Keeping state of data within localStorage in React

Understanding the difference between useContext and custom hooks

KT — Mon, 24 Apr 2023 08:58:54 +0000

Continuing from my previous blog post, I wanted to share my understanding of the difference between useContext and custom hooks.

After completing all the main functions of my app, I noticed that there was some repeated code across three of my components. I thought, "Why not refactor it and create a common component to handle all the business logic that could be used across all other components and future components too?"

My first idea was to use useContext to hold all the common state variables and functions, which could then be shared across all of the other components.

For context (heh, get it), useContext is a hook that allows access to data and functions from a parent component within a child component without having to pass props down through layers of children components (aka prop drilling). It's a way to share state between components without the use of props, cutting the middleman out.

Although my project wasn't deeply nested, I wanted to be more familiar with useContext, so I refactored my code and transferred all of the common business logic into a context file.

Essentially, my components would receive an array of objects passed via props, and various functions would modify the passed-down data and send the modified data back upstream, changing the state within the parent component. Here's what it looks like when using useContext:

export const ExampleContext = React.createContext<ExampleContextObj>({
    data: [],
    doSomething1: () => {},
    doSomething2: () => {},
  });

function ExampleContextProvider({passedInObjectArray, children}){
  const [modifedData, setModifiedData] = useState(passedInObjectArray);
  const [something, setSomething] = useState("");

  function doSomething1() {
      //...rest of code,
      setModifedData(changedData)
    }

    function doSomething2() {
      //...rest of code,
      setSomething("thing")
    }

  const contextValue: ExampleContextObj = {
    data: modifiedData,
    doSomething1: doSomething1,
    doSomething2: doSomething2,
  };

  return (
    <ExampleContext.Provider value={contextValue}>
      {children}
    </ExampleContext.Provider>
  );
}

export default ExampleContextProvider;

Then, within my App component it will look like:

function App() {
  const [object1, setObject1] = useState(originalObjectArray1)
  const [object2, setObject2] = useState(originalObjectArray2)
  const [object3, setObject3] = useState(originalObjectArray3)

  function modifyObject1(newData){
    setObject1(newData)
    //... rest of code
   }

  //... rest of code

  return (
  <>
    <ExampleContextProvider passedInObjectArray={object1}>
          <ComponentOne />
    </ExampleContextProvider>

    <ExampleContextProvider passedInObjectArray={object2}>
          <ComponentTwo />
    </ExampleContextProvider>

    <ExampleContextProvider passedInObjectArray={object3}>
          <ComponentThree />
    </ExampleContextProvider>
  </>
   )
}

Then, within say, Component One it will look like this:

import React, { useContext } from "react";

function ComponentOne() {
  const {
    data,
    doSomething1,
    doSomething2,
  } = useContext(FlashcardContext);

 return (
   <>
     <h1>{data[0].title}</h1>
     <button onClick={doSomething1} />
     <button onClick={doSomething2} />   
  </>
 )

And imagine it will be similar with Component Two and Three.

When I first started using separate context providers to wrap around each component, I assumed that each component would only receive data that was relevant to it. However, I quickly discovered that this was not the case, as Component 2 and 3 were showing the same data as Component 1.

I was surprised to find that the data was being shared across all components, despite the fact that I had separated the context providers. I tried several hacks, such as using ternaries to check the type of object being passed down within each component, but none of them worked.

It was then that I realized I had overlooked a core concept of useContext: context holds a universal state, which means that components have easy access to the same data and functions without needing to drill down through props. Rather than using context to pass data down to individual components, it's better suited for sharing data across multiple components that are part of the same section of the application.

Although I was disappointed that I couldn't use useContext for my business logic, I wanted to refactor my code since it was sharing the same logic. I considered making an intermediary component to hold the business logic, but I thought that might make things unnecessarily complicated.

Then I thought of Higher Order Components, which seemed to fit the bill. However, I realized that this method was mostly used in class-based React applications, while my project was using functional components. After some research and prompting from ChatGPT, I remembered something about custom hooks, which I had only used a bit in my course projects. I was excited to finally be able to use them in my project!

I set out to rework the whole code using a custom hook, and everything worked just like before. The great thing about changing it to a custom hook was that I didn't have to change too much code from the context file. I deleted some unnecessary code and renamed a few things, and that was it!

function useExampleCustomHook({passedInObjectArray}){
  const [modifedData, setModifiedData] = useState(passedInObjectArray);
  const [something, setSomething] = useState("");

  function doSomething1() {
      //...rest of code,
      setModifedData(changedData)
    }

    function doSomething2() {
      //...rest of code,
      setSomething("thing")
    }

  return {
    data: modifiedData,
    doSomething1: doSomething1,
    doSomething2: doSomething2,
  };
}

export default useExampleCustomHook;

Which then made my App component leaner:


  function App() {
  const [object1, setObject1] = useState(originalObjectArray1)
  const [object2, setObject2] = useState(originalObjectArray2)
  const [object3, setObject3] = useState(originalObjectArray3)

  function modifyObject1(newData){
    setObject1(newData)
    //... rest of code
   }

  //... rest of code

  return (
     <>
          <ComponentOne passedInObjectArray={object1} />
          <ComponentTwo passedInObjectArray={object2} />
          <ComponentThree passedInObjectArray={object3} />
     </>
   )
}

And finally used it here:

import React from "react";
import useExampleCustomHook  from "./hooks/useExampleCustomHook"

function ComponentOne({passedInObjectArray}) {
  const {
    data,
    doSomething1,
    doSomething2,
  } = useExampleCustomHook(passedInObjectArray);

 return (
   <>
     <h1>{data[0].title}</h1>
     <button onClick={doSomething1} />
     <button onClick={doSomething2} />   
  </>
 )

You can just imagine the sigh of relief I got when this was working for me!

In summary, my exploration of useContext and custom hooks in React highlighted a crucial distinction. Initially drawn to useContext for its promise of simplified state management, I discovered its inherent nature of holding universal state, making it more suitable for sharing data across components within the same section.

Realizing this wasn't the optimal fit for my specific use case, I seamlessly transitioned to custom hooks. This switch not only resolved shared data issues but also emphasized a more modular code structure. The key takeaway lies in understanding the nuanced differences between these tools.

While useContext is designed for universal state-sharing within a specific context, custom hooks provide a more flexible and targeted approach, allowing for efficient encapsulation of logic tailored to individual components.

This was a great learning journey and knowing when to use custom hooks and useContext.

I hope this was a good read and maybe it will help you too in your learning journey!

For anyone wanting to see which project I'm referencing to, it's in my Github repo.