This February, I noticed something odd about how my team was using AI.

Every one of us was getting better at it. We wrote better prompts, pasted in better context, and got better answers. But every conversation started cold. The decision we made last Tuesday about why a component works the way it does lived in one person's chat history, on one person's laptop, and nowhere else. The AI was learning nothing about us. It was only ever answering the person in front of it.

That's the gap I tried to close with a project I called Team Context Intelligence, or TCI. I built it at Coinbase, where I was a software engineer, over February and March of this year. I no longer have the code, because it lived on a laptop I handed back when I left. But the idea has stayed with me, so I'm rebuilding it as an open-source project. This post is the argument for why, plus what I learned the first time.

### The problem: context dies in private conversations
AI assistants have quietly become a place where engineering context gets created. We debug in them, we weigh trade-offs in them, and we reach conclusions like "we can't do X because of Y, so we did Z." Then the tab closes.

Compare that to how knowledge used to travel. A decision lived in a PR description, a design doc, a Slack thread, or someone's head. All of those were imperfect, but they were shared. A teammate could find them.

Local AI conversations are different. They're private by default and fragmented by nature, so the most thoughtful reasoning on the team is also the least discoverable. Two consequences follow:

- **Handoffs are lossy.** When someone moves teams or goes on leave, what transfers is the code and maybe a document. The reasoning, the dead ends, and the "we tried that" are gone.
- **Working in unfamiliar territory is slow.** If you pick up a component you don't know, you're starting from scratch, even though three of your colleagues have already spent hours thinking about it with an AI.

I didn't want a better chatbot. I wanted the team's accumulated thinking to be available at the moment someone asks a question.

### The idea: check the team first
TCI's premise is simple: **before a prompt goes to the model, ask the team.**

Instead of going straight to the AI, a query first hits a shared store of summaries written by people on your team or at your company. The most relevant ones come back and are attached to the AI's response, so the person gets the model's answer together with "here's what your colleagues already figured out about this."

It had three parts.

**1. Signals.** TCI listens for moments that mean a unit of work just happened. I treated three things as signals: a commit, a push, and an explicit save by the user. These are natural boundaries, because something just changed, or someone decided it was worth keeping. Nobody has to remember to write documentation.

**2. Summaries.** When a signal fires, an LLM generates a summary of what happened and why. That summary, rather than the raw diff or the full chat, is what goes into the shared store. Summaries are small, readable, and easy to rank. They also keep the private details of a raw conversation out of the team's view while preserving the conclusions.

**3. Retrieval.** When someone asks a question, TCI searches the store and fuses several rankings with Reciprocal Rank Fusion (RRF). I combined:

- **Keyword search (BM25)**, which is good at exact terms like function names, error strings, and service names.
- **Vector embeddings**, which find summaries that are semantically close even when the words differ.
- **Recency**, because a decision from last week is usually more relevant than one from two years ago.

RRF is a nice fit here because you don't have to reconcile incompatible score scales. A BM25 score and a cosine similarity aren't comparable numbers, but their *ranks* are. Each summary gets credit for how high it placed in each list, the credits are summed, and the top results win. It's cheap, robust, and surprisingly hard to beat for a first version.

One more design choice mattered to me: **TCI was AI-agnostic.** It wasn't a plugin for one assistant. It sat beside whichever tool people already used. That's important because teams don't standardize on one model, and the context shouldn't be held hostage by any single vendor.

### What happened: the technology wasn't the hard part
I'll be honest about how it went. The retrieval worked well enough, and the idea held up. The thing that hurt was **adoption**.

Here's the trouble. TCI asks each person to take part in a system whose payoff is mostly *someone else's* benefit and *later*. When I save a summary, I get nothing right now. The win shows up when a teammate asks a related question next month. The cost is immediate, even if it's small: one more tool, one more habit, one more thing in the workflow.

That's a classic shared-resource problem, and it's hard to solve from the bottom up. A knowledge base is worthless when empty and valuable when full, and nobody wants to be the one pouring into an empty one. Without enough contributions, retrieval returns little. When retrieval returns little, nobody sees the win, so nobody contributes.

I came away with a fairly firm belief: **a tool like this works much better when a team, or the company, commits to it.** Not as a mandate for its own sake, but because the value is a network effect, and network effects don't start by themselves. One team that decides "we all do this" would probably get more out of it than a hundred individually curious engineers.

TCI stopped when I left Coinbase. I hadn't kept maintaining it there, and adoption was never what it needed to be to justify someone else picking it up. That's a fair outcome, and I'd rather say so than dress it up.

### Why I still think the idea is right
Even with that result, the problem hasn't gone away. It has grown. People use AI more now than they did when I started, which means more reasoning is happening in places no teammate can see.

I also think the framing matters. Most of the conversation about AI at work is about *generation*: write the code, draft the doc, summarize the meeting. TCI is about *memory*. It treats the team's collective thinking as an asset that compounds, and it asks a different question: not "what can the model produce?" but "what does our team already know?"

Some of the instincts I'd defend:

- **Retrieve before you generate.** An answer grounded in your team's actual decisions beats a generic answer every time.
- **Capture at natural boundaries.** A commit or a push is already a moment where someone has finished a thought. That's the cheapest time to ask for a summary, and a model can do the writing.
- **Keep it private to the organization.** Context about how your systems work shouldn't leave the company. Self-hosting and team-level visibility aren't extras, they're the reason people will trust it.
- **Make visibility a feature.** Not everything should go to everyone. Team-scoped context is the difference between a useful memory and a liability.

### What I'm building now
I'm rebuilding TCI as an open-source project, written in JavaScript. It's still at the documentation stage, which I'm treating as a feature rather than an apology. The first time, I built first and wrote the design afterward, and I lost both when the laptop went. This time I'm writing down the contracts first: what a signal looks like, what a summary contains, how scoping works, and how retrieval results get attached to a response.

Here's what I'm aiming for:

- A signal listener that works with the events engineers already produce: commits, pushes, and explicit saves.
- LLM-generated summaries, with a clear shape and the ability to review or redact before they're shared.
- A retrieval layer that fuses keyword, vector, and recency signals with RRF.
- Team-level visibility, designed in from the start rather than bolted on.
- No dependence on a particular AI assistant.

And I want to learn from the adoption failure directly. That means the design has to show a win *now*, not only later: for example, surfacing relevant context for the person who just saved something, so contributing is immediately useful to them as well. I don't know yet whether that's enough. That's the part I most want to test.

### What I'd like from you
If you've felt this problem, I'd love to hear about it. Specifically:

- Where does your team's AI-generated context get lost today?
- What would make you willing to contribute a summary when the payoff isn't yours?
- What would make you *not* trust a shared memory like this?

I'll share the repository in a future blog post, once the documentation is in a state I'm happy to share. Until then, you can reach me on LinkedIn.

The models will keep getting better at answering questions. The harder and more interesting question is whether our teams get better at remembering what they've already answered.


Your AI Should Ask Your Team Before It Asks the Model

In January 2026, "agent orchestration" was not really a thing yet. You had one assistant, one chat, and one very long prompt. I wanted something different: multiple agents working on different things at the same time, each with a clear purpose.

That idea became `identity/claude`, a private repository inside Coinbase's Identity Platform. The name came from the fact that we were using Claude a lot, but it was designed from day one to work with whatever AI the user preferred. A few months later, roughly 90 engineers were using it or contributing to it every day, and it had become the source of truth for everything AI-related in the org.

This is how it started, what worked, and the one thing I would do differently.

## The problem

The `identity/frontend` repository holds every frontend surface of the Identity Platform. Its test coverage sat below 60%, and the usual approaches were not moving it: nobody wakes up wanting to write tests for files they did not touch, and a single AI assistant given "increase coverage" will happily generate tests that execute lines without verifying anything.

Coverage is a number. What I wanted was meaningful tests, and a way to keep them meaningful.

## Three agents, three jobs

Instead of one assistant doing everything, I split the work the way a good team would:

- **The Architect** takes the decisions closer to product and engineering cost. What is worth doing, how big should it be, what is the cheapest design that solves the problem.
- **The Tester** makes sure every test is meaningful. It owns edge cases: empty states, failures, race conditions, the inputs nobody thinks about.
- **The Engineer** does the raw implementation. It takes the structure produced by the other two and turns it into code.

Each one lives in its own markdown file with its own rules: what it is responsible for, what it must never do, what "done" looks like. Today these would simply be called agents, but at the time they were a set of well-written instructions that I pointed the AI at.

## The orchestration

The part that made this feel like orchestration was the workflow, not the prompts.

For any task, I asked the AI to break the work into steps, and every step had exactly one of those markdown files as its owner. The agents worked side by side, with blocking where it mattered: if the Architect was working, no agent that depended on its output would start. The Tester would not move until the Architect had defined the shape, and the Engineer would not write a line until the Tester had defined what proof looked like.

That ordering is the whole trick. Most "AI wrote bad code" problems are really "AI started coding before anyone decided what to build and how to verify it".

## A surprise: the Architect on small work

I assumed the Architect would be overkill for small features and bug fixes. It was the opposite.

Even on a tiny change, it started thinking more broadly about the files being touched: what could be improved, simplified, or documented for the sake of the next engineer who would open them. Small PRs left the code a little better than they found it, without turning into large refactors, because the same agent was also responsible for engineering cost.

## The result

Over about one month, with a single engineer (me) driving it, this touched roughly 1,000 files across more than 100 PRs. Coverage in `identity/frontend` went from under 60% to over 80%.

Getting there was only half of it. Coverage that is not defended decays, so I added a CI check that made you accountable whenever code was merged with less coverage than `master`. We rolled it out in two phases: first it only warned, so people could see it and adjust, and later it blocked the merge. Nobody was surprised by the block, because everyone had already seen the warning for weeks.

## Adoption

It started with a couple of commits from my core team, `identity/frontend`. Then people from other teams started adding their own rules and workflows, and it grew into the repo everyone reached for when they wanted to do something with AI. Eventually managers and leadership were hands-on too, contributing to it.

The hardest adoption problem was other AI tools. A repo built around one tool's conventions does not carry over to Cursor for free, and making the instructions portable took real work.

## How to do this at your company

You do not need a platform to start. What worked for me:

1. **Split by role, not by task.** Pick two or three distinct responsibilities (decide, verify, implement) and write one file for each.
2. **Write what each agent must not do.** Boundaries make agents useful more than capabilities do.
3. **Make steps single-owner.** Every step has exactly one agent responsible for it.
4. **Block on dependencies.** Do not let the implementer start before the decider and the verifier have finished.
5. **Enforce with CI, gradually.** Warn first, block later. Measure against your main branch rather than a fixed number so the bar only goes up.
6. **Keep the instructions tool-agnostic.** Plain markdown travels. Tool-specific features do not.

## What I would do differently

Everything went smoothly, with one exception, and it is not technical.

I created this project, but as it grew, other staff engineers and leaders took over its direction, and I was not in the room for it. I treated it like an open contribution space and stepped back. That is a mistake.

If you build something that many people depend on, stay on top of it for as long as you can. Be its maintainer. Be present, review, answer questions, and make it visible that someone owns it. A shared repo with no clear keeper is not open source in the healthy sense. It is land with no owner, and the original idea drifts.

I am proud of what `identity/claude` became. Next time, I will make sure I am still the one holding it.


How I Built the Most Used Repo in Identity Platform at Coinbase

Last week, I was having a problem in my current job, that basically we were refactoring stuffs in our code, and one of them was the Status Screen.
The previous developer left to us a linear navigation (using react-navigation), that basically works without different stacks (not differing auth and app). With that in mind, one of our screens was the Status one, that basically could be navigated towards all the application.
After I start the refactor of the navigation, and update the navigation from a linear one to a navigation by stack, based on the authentication flows from react-navigation, we start to have a problem:

**How to have a global Status for our API responses, without to have it as a Screen?**

The response takes a bit to come for me, but, at evening the light came, why not use a High Order Component to get around this problem?!

So, let's start doing it, first and formals, we are going to use React Native (Expo Bare-Workflow), to be able to get our results more quickly, but the same can be achieved using React Native CLI.

### Getting Started
First, we're going to init our project, as I'm using Expo, I'll do:

```bash
expo init
```

After that, I'm going to select my workflow, based on expo. So I'll select:

```bash
minimal (TypeScript)  same as minimal but with TypeScript configuration 
```

### Creating our Context
Okay, with our code ready to start, we're going to create our context, in my case, the StatusContext.

Inside the source of our code, create a `contexts` folder, and inside it, create: `index.ts`, `provider.tsx` and `types.ts`.

#### types.ts
In this file, we need to create all types that we're going to need in our context:

1) *STATUS*: responsible for been a status state, to render or not, our Status Modal;
2) *StatusScreen*: all different statuses, that can be called in our components;
This type will be really important to be used, because, in my case I have tons of different requests that has different responses, so, I need to be able to specify my status modal and, perhaps, their options.

3) *StatusContextType*: our context types, all properties that can be used from the components that knows our context.

```javascript
export enum STATUS {
  SUCCESS,
  ERROR,
}

export type StatusScreen = 'status_one' | 'status_two' | undefined

export type StatusContextType = {
  status: STATUS | false
  statusScreen: StatusScreen | undefined
  setStatus(status: STATUS | false): void
  setStatusScreen(statusScreen: StatusScreen | undefined): void
  clearState(): void
  statusOptions: any
}
```


#### provider.tsx

Okay, in this file we'll create our context himself. My StatusProvider will work as following:

```javascript
import React, { createContext, useEffect, useState } from 'react'
import { STATUS, StatusContextType, StatusScreen } from './types'

export const StatusContext = createContext<StatusContextType>(
  {} as StatusContextType
)

export default function StatusProvider({
  children,
}: {
  children: React.ReactNode
}) {
  const [status, setStatus] = useState<STATUS | false>(false)
  const [statusScreen, setStatusScreen] = useState<StatusScreen | undefined>(
    undefined
  )

  const [statusOptions, setStatusOptions] = useState<any>(undefined)

  const clearState = () => {
    setStatus(false)
    setStatusScreen(undefined)
    setStatusOptions(undefined)
  }

  const getStatusScreenProps = () => {
    if (statusScreen) {
      switch (statusScreen) {
        case 'status_one':
          return {
            title: 'TITLE OF SCREEN ONE',
            description: 'This is the description of screen one',
          }
        case 'status_two':
          return {
            title: 'TITLE OF SCREEN TWO',
            description: 'This is the description of screen two',
          }

        default:
          break
      }
    }
  }

  useEffect(() => {
    setStatusOptions(getStatusScreenProps())
  }, [status, statusScreen])

  return (
    <StatusContext.Provider
      value={{
        status,
        statusScreen,
        setStatus,
        setStatusScreen,
        statusOptions,
        clearState,
      }}
    >
      {children}
    </StatusContext.Provider>
  )
}

```

Is really important to remember that the `getStatusScreenProps` function is something that will be used for my purposes, BUT, can also be inexistent.
In my case, I need to have a chance to render the same status modal, just changing the options, WITHOUT using this contexts in different statuses file.

I could create a `Status.tsx` component in each of my Screens, but them, at some point, with a possible redesign, I would to change all my components. Creating just a StatusCustom, we can concentrate our efforts in just one file with a Custom Settings.

#### index.ts
In here we're just creating our Hook and exporting it.

```javascript
import { useContext } from 'react'
import { StatusContext } from './provider'
import { StatusContextType } from './types'

export const useStatus = (): StatusContextType => {
  return useContext(StatusContext)
}
```

#### Provider
Last but not least, we need to put our Provider above all our application (or above the Components we need to use).

To do that, I created a `Welcome.tsx` file in the root, for testing purposes, and, in the `App.tsx` I did:

```javascript
import React from 'react'
import StatusProvider from './contexts/provider'
import Welcome from './pages/Welcome'

export default function App() {
  return (
    <StatusProvider>
      <Welcome />
    </StatusProvider>
  )
}

```

Now, our entire App can use the Status Context, including the Welcome Component.

### Creating the Status Component and Welcome Page
Now, we need to create our Status Component, as I already said, I'll create my Status as a Modal, so, let's do it:

```javascript
import React, { useEffect, useState } from 'react'
import { View, Modal, Text, TouchableOpacity } from 'react-native'
import { STATUS } from '../../contexts/types'

interface StatusProps {
  title?: string
  description?: string
  clearState(): void
  status: STATUS | false
}

const Status = ({ title, description, status, clearState }: StatusProps) => {
  const [visible, setVisible] = useState<boolean>(false)

  useEffect(() => {
    setVisible(status !== false)
  }, [status])

  return (
    <View>
      <Modal visible={visible}>
        <View>
          <Text>{title}</Text>
          <Text>{description}</Text>
          <TouchableOpacity onPress={clearState}>
            <Text>Close modal</Text>
          </TouchableOpacity>
        </View>
      </Modal>
    </View>
  )
}

export default Status
```

Okay. You can notice that this file is really reusable, that's totally the thought. We have a really simple and custom Status, that receives all props from the Parent Component who calls.

#### Welcome.tsx
This file is just a really playground for our tests.

```javascript
import React, { useEffect } from 'react'
import { SafeAreaView, Text, TouchableOpacity, View } from 'react-native'
import Status from '../components/Status'
import { useStatus } from '../contexts'
import { STATUS } from '../contexts/types'
import withStatus from '../hoc/withStatus'

function Welcome() {
  const { status, statusScreen, setStatus, setStatusScreen } = useStatus()

  const onPressFirstStatus = () => {
    setStatus(STATUS.SUCCESS)
    setStatusScreen('screen_one')
  }

  const onPressSecondStatus = () => {
    setStatus(STATUS.SUCCESS)
    setStatusScreen('screen_two')
  }

  return (
    <SafeAreaView style={{ flex: 1 }}>
      <TouchableOpacity onPress={onPressFirstStatus}>
        <Text>OPEN MODAL 1</Text>
      </TouchableOpacity>
      <TouchableOpacity
        style={{ marginTop: 100 }}
        onPress={onPressSecondStatus}
      >
        <Text>OPEN MODAL 2</Text>
      </TouchableOpacity>
    </SafeAreaView>
  )
}

export default Welcome
```

Here, I created two different buttons for render the modals, but we can see, that once we clicked in the Button, nothing happens. That's because we didn't have the Status Component included in our code yet.

Some code examples, could do like:

```javascript
function Welcome() {
  {...}

  if (status !== false) {
    return (
     <Status {...statusOptions} status={status} clearState={clearState} />
    )
  }

  return (
    ...
  )
}

export default Welcome
```

And, we have no problem with that solution, BUT. Remember that we want to have this Status in multiple Components, imagine to put this condition inside 100 different files, wouldn't that be a rough task?!

### HOC - High Order Component

So, now we reach the focus point of this article. My major problem was how to use a HOC to achieve my goal. So, I have multiple screens that needs to render a Status Modal once we have a response from API. 
**IMPORTANT**: Just explaining a HOC, really simple, a High Order Component is a technique in React to reuse logic for multiple components. A HOC receives, on a raw manner, a Component, and returns other Component. 

That is the most important thing here, we can do whatever we want above the Component that is coming to us, and the following code is what we're going to do:

```javascript
import React from 'react'
import Status from '../components/Status'
import { useStatus } from '../contexts'
import { STATUS } from '../contexts/types'

const withStatus = (Component: any) => {
  return function WithStatus({ children }: any) {
    const { status, statusOptions, clearState } = useStatus()

    if (status !== false) {
      return (
        <Status {...statusOptions} status={status} clearState={clearState} />
      )
    }

    return <Component>{children}</Component>
  }
}
export default withStatus

```

Here, we have a `withStatus` HOC, that are a Component, and we're putting a condition inside it, DEPENDING on our Status hook. If we have a Status (remember that we're returning in our hook a `status` state, that returns to us if is SUCCESS or ERROR) the Status Modal needs to be shown.

#### Updating Welcome.tsx

Now that we have our withStatus HOC, we need to update the `Welcome.tsx` file, so the Modal can be finally rendered.

```javascript
{...}

function Welcome() {
  {...}
}

ADDED -> export default withStatus(Welcome)
```

We added the withStatus above our Welcome Component, and now, the Component is Wrapped by the Status Modal, and will be listening for all changes in the StatusContext and rerender whenever is needed.

Now, this is the result:

**Welcome Page**:
![Screen Shot 2021-09-27 at 19.42.31](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/u2f00gc1lx5y2scublxb.png)

**Status - status_one (after click on onPressFirstStatus)**:
![Screen Shot 2021-09-27 at 19.42.49](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mx07c19i99gr8x6ogcp5.png)

**Status - status_two (after click on onPressSecondStatus)**
![Screen Shot 2021-09-27 at 19.42.52](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5zpfnrhyprspj0a2m5kw.png)
   


### Finish
So, this is everything guys, hope you enjoy to read it, and get all the knowledge I try to pass here. This was my workaround for a problem that I found myself trapped in. If
you think something could get better, please let me know, let's talk about that, thanks for reading it.

Here's the repository link: [Repository Link](https://github.com/brunofrigeri/hoc-with-status)
   


Global Status Modal HOC

Every developer have to follow prototypes coming from design work. The thing is not always said is that sometimes the designer perceive something that it's hard for developers. I have a similar comparison that I like to do: Imagine an architect that architects a house in some weird or hard way, pretty, but hard. The engineer needs to overcome the issues, and, if possible delivery the architect solution. 
Getting back to ours, we are the engineer (metaphoric and specifically saying) that needs to deliver the awkward, pretty and hard structure.

For me, it was on my way working on a fintech, the need of a curved tab navigation arrived, and me, as a developer that have never done it, struggled.
So today, I'll try, hope with success, explain in details how I could achieve the desired behavior with performance, low and clean code.


## Introduction
The first step of the way was understanding the ways to do it, my finds were divided in:
- Creating a curved bottom navigation using Views only.
- Using SVG forms and trying to shape them the way we need (fyi, we can create awesome forms by shaping them).

Moving on, I decided to go with the most beautiful, performant and cleaner solution I encounter, which was using SVGs and shaping them accordingly. So let's code!!

## Setting up Project and Installing dependencies

1. Let's start our react-native app, I'm going to use a bare `react-native-cli` installation, but you can go with `expo` too:
First and formals we need to create a react native app:

```bash
yarn react-native init curved-bottom-tab-rn
```

2. Moving on we need to install the needed `react-navigation` dependencies for a bottom tab use. At this tutrial, I'm using `v5` of `react-navigation` which it's completely your choice.

```bash
yarn add @react-navigation/native
yarn add react-native-reanimated react-native-gesture-handler react-native-screens react-native-safe-area-context @react-native-community/masked-view
yarn add @react-navigation/stack
yarn add @react-navigation/bottom-tabs
```

**PS:** You should follow react-navigation [documentation](https://reactnavigation.org/docs/getting-started/) for better documentation on installing all dependencies and settings. All of them are made for this project and can be encountered in the repository at the final of this post.

## Using React Navigation
Here, for test purposes, I'm going to create different Stacks, which are going to be used as an entry point to different Tabs. So with no more delay, let's create our first file `navigation.{ts,js}` inside our `src/*` folder.
In my case here's the example below:

```javascript
import React from 'react';
import { NavigationContainer } from '@react-navigation/native';
import { createStackNavigator } from '@react-navigation/stack';
import { createBottomTabNavigator } from '@react-navigation/bottom-tabs';
import { First, Second, Third } from './screens'

const Stack = createStackNavigator();

const Tab = createBottomTabNavigator();

export function FirstStack() {
  return (
    <Stack.Navigator>
      <Stack.Screen name="First" component={First} />
    </Stack.Navigator>
  );
}

export function SecondStack() {
  return (
    <Stack.Navigator>
      <Stack.Screen name="Second" component={Secondary} />
    </Stack.Navigator>
  );
}

export function ThirdStack() {
  return (
    <Stack.Navigator>
      <Stack.Screen name="Third" component={Third} />
    </Stack.Navigator>
  );
}

export default function Navigation() {
  return (
    <NavigationContainer>
      <Tab.Navigator>
        <Tab.Screen name="First" component={FirstStack} />
        <Tab.Screen name="Secondary" component={SecondaryStack}/>
        <Tab.Screen name="Third" component={ThirdStack} />
      </Tab.Navigator>
    </NavigationContainer>
  );
}
```

For more information on this piece of code, here are the things we're doing and the result of it below:
- Adding `Screens`: we added three different screens (First, Second and Third) which just exists for test purposes, and are just flex components with different background colors. 
- Creating `Stacks`, which, as the name suggests, it's a stack of screens.
- Creating a `TabNavigator`: the `TabNavigator` is basically a Tab that keeps at the bottom of the screen, in which, in our case, will be always visible for all screens no matter the current Stack. 


![Screen Shot 2021-04-24 at 17.10.23](/assets/_uploaded/curved-bottom-tab-react-native-1.png)

## Building a Custom TabBar
For customizing a TabBar, `react-navigation` give us a full documentation that can be really self explainer, so I'll leave you guys with that [here](https://reactnavigation.org/docs/5.x/bottom-tab-navigator/#tabbar).
Following, let's create a file for this custom tabBar, I'm going to name it `MyTabBar`, inside `components` folder.

```javascript
import { View, Text, TouchableOpacity } from 'react-native';

function MyTabBar({ state, descriptors, navigation }) {
  const focusedOptions = descriptors[state.routes[state.index].key].options;

  if (focusedOptions.tabBarVisible === false) {
    return null;
  }

  return (
    <View style={{ flexDirection: 'row' }}>
      {state.routes.map((route, index) => {
        const { options } = descriptors[route.key];
        const label =
          options.tabBarLabel !== undefined
            ? options.tabBarLabel
            : options.title !== undefined
            ? options.title
            : route.name;

        const isFocused = state.index === index;

        const onPress = () => {
          const event = navigation.emit({
            type: 'tabPress',
            target: route.key,
            canPreventDefault: true,
          });

          if (!isFocused && !event.defaultPrevented) {
            navigation.navigate(route.name);
          }
        };

        const onLongPress = () => {
          navigation.emit({
            type: 'tabLongPress',
            target: route.key,
          });
        };

        return (
          <TouchableOpacity
            accessibilityRole="button"
            accessibilityState={isFocused ? { selected: true } : {}}
            accessibilityLabel={options.tabBarAccessibilityLabel}
            testID={options.tabBarTestID}
            onPress={onPress}
            onLongPress={onLongPress}
            style={{ flex: 1 }}
          >
            <Text style={{ color: isFocused ? '#673ab7' : '#222' }}>
              {label}
            </Text>
          </TouchableOpacity>
        );
      })}
    </View>
  );
}
```

1. Now, let's get to work. In our `src/navigation.{ts,js}` file, we have in the TabNavigator a prop named `tabBar` that returns a function with props, those props are what we need for our custom tab navigator, so we can receive those props and return our custom component. So let's import our component `MyTabBar` and in our `navigation.{ts,js}` file we're going to use the property `tabBar` mentioned prior:

```javascript
import { MyTabBar } from './components'

export default function Navigation() {
  return (
    <NavigationContainer>
      <Tab.Navigator tabBar={props => <MyTabBar {...props} />}>
        <Tab.Screen name="First" component={FirstStack} />
        <Tab.Screen name="Secondary" component={SecondaryStack}/>
        <Tab.Screen name="Third" component={ThirdStack} />
      </Tab.Navigator>
    </NavigationContainer>
  );
}
```

2. Now, you can realize that all three tabs has the same shape, but we want the middle one with a different display. For that we're going to create a `TabBarButton.{tsx,jsx}` component, which will be used only for the middle tab.

```javascript
import React from 'react';
import { StyleSheet, Text, View } from 'react-native';

export default function TabBarButton() {
  return (
    <View style={styles.container}>
      <Text style={styles.text}>+</Text>
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    position: 'absolute',
    width: 55,
    height: 55,
    borderRadius: 999, // full radius
    bottom: 10,
    justifyContent: 'center',
    alignItems: 'center',
    backgroundColor: 'purple',
  },
  text: {
    fontSize: 40,
    color: 'white',
  },
});
```

3. Let's add the `TabBarButton` to our `TabNavigator`, using a prop called `options.tabBarButton` which receives an Component instead of the current tabBarButton component:

```javascript
  export default function Navigation() {
    return (
      <NavigationContainer>
        <Tab.Navigator>
          <Tab.Screen name="First" component={FirstStack} />
          <Tab.Screen name="Secondary" component={SecondaryStack} options={{ tabBarButton: () => <TabBarButton /> }} />
          <Tab.Screen name="Third" component={ThirdStack} />
        </Tab.Navigator>
      </NavigationContainer>
    );
  }
```

4. Things are not working correctly just yet, as we created a custom tabBar, the option `tabBarButton` is not being accessed. For accessing it, we can add a condition like the following:

```javascript
import { View, Text, TouchableOpacity } from 'react-native';

function MyTabBar({ state, descriptors, navigation }) {
  const focusedOptions = descriptors[state.routes[state.index].key].options;

  if (focusedOptions.tabBarVisible === false) {
    return null;
  }

  return (
    <View style={{ flexDirection: 'row' }}>
      {state.routes.map((route, index) => {
        const { options } = descriptors[route.key];
        const label =
          options.tabBarLabel !== undefined
            ? options.tabBarLabel
            : options.title !== undefined
            ? options.title
            : route.name;

        const isFocused = state.index === index;

        const onPress = () => {
          const event = navigation.emit({
            type: 'tabPress',
            target: route.key,
            canPreventDefault: true,
          });

          if (!isFocused && !event.defaultPrevented) {
            navigation.navigate(route.name);
          }
        };

        const onLongPress = () => {
          navigation.emit({
            type: 'tabLongPress',
            target: route.key,
          });
        };

        return (
          <TouchableOpacity
            accessibilityRole="button"
            accessibilityState={isFocused ? {selected: true} : {}}
            accessibilityLabel={options.tabBarAccessibilityLabel}
            testID={options.tabBarTestID}
            onPress={onPress}
            onLongPress={onLongPress}
            style={{flex: 1, justifyContent: 'center', alignItems: 'center'}}>
            {options.tabBarButton ? (
              <TabBarButton />
            ) : (
              <Text style={{color: isFocused ? '#673ab7' : '#222'}}>
                {label}
              </Text>
            )}
          </TouchableOpacity>
        );
      })}
    </View>
  );
}
```

Let's look what we have at this moment:
![Screen Shot 2021-04-24 at 17.32.31](/assets/_uploaded/curved-bottom-tab-react-native-2.png)

## Using D3-Shape to Shape our TabBar
1. Mostly important, and probably why you're here to be honest, we're going to shape our TabBar. For that we're going to use [d3-shape](https://github.com/d3/d3-shape) and [react-native-svg](https://github.com/software-mansion/react-native-svg), so let's add them:

```bash
yarn add d3-shape react-native-svg
```

If using **IOS**, run:
```bash
cd ios/ && pod install && cd ..
```

2. Now, we're going to build a component that will be called `TabShape.{tsx,jsx}` which will be responsible for shaping our tabBar:

```javascript
import React from 'react';
import {Dimensions} from 'react-native';
import {curveBasis, line} from 'd3-shape';
import Svg, {Path} from 'react-native-svg';

const TAB_HEIGHT = 80; // This fixed height can be as you wish.

const { width } = Dimensions.get('window');

const lineGenerator = line();

const rect = lineGenerator([
  [0, 0],
  [width / 2, 0],
  [width, 0],
  [width, TAB_HEIGHT],
  [0, TAB_HEIGHT],
  [0, 0],
]);

const center = lineGenerator.curve(curveBasis)([
  [(width / 5) * 2, 0],
  [(width / 5) * 2 + 20, TAB_HEIGHT * 0.5],
  [(width / 5) * 3 - 20, TAB_HEIGHT * 0.5],
  [(width / 5) * 3, 0],
]);

const d = `${center} ${rect}`;

export default function TabShape() {
  return (
    <Svg width={width} height={TAB_HEIGHT}>
      <Path fill="white" {...{d}} />
    </Svg>
  );
}
```

Okay, let's run into this code so you can understand it:

- `Svg` and `Path` from `react-native-svg` are responsible for creating an SVG through something, which in this case are shapes generated from d3-shape.
- The `line` function is responsible for generating lines based on giving coordinates.
- The `rect` constant uses the `lineGenerator` to build a rectangle, as the following:

```javascript
const rect = lineGenerator([
  [0, 0],
  [width / 2, 0],
  [width, 0],
  [width, TAB_HEIGHT],
  [0, TAB_HEIGHT],
  [0, 0],
]);
```

Translates to that in the reality:

```
    [0,0] ─────────────── [width / 2, 0] ───────────────────── [width, 0]         
       │                         │                                │              
       │                         │                                │             
       │                         │                                │              
 [0,TAB_HEIGHT] ────────────────────────────────────── [width, TAB_HEIGHT]
```

- Last and most importantly, the `curve`, which follows the exact same idea of the `rect`, but by curving it:

```javascript
const center = lineGenerator.curve(curveBasis)([
  [(width / 5) * 2, 0],
  [(width / 5) * 2 + 20, HEIGHT_SIZE * 0.5],
  [(width / 5) * 3 - 20, HEIGHT_SIZE * 0.5],
  [(width / 5) * 3, 0],
]);
```

- Check the whole explanation with this excalindraw Draw:

![CURVED_TAB_EXPLANATION](/assets/_uploaded/curved-bottom-tab-react-native-3.png#light-mode-only)
![CURVED_TAB_EXPLANATION](/assets/_uploaded/curved-bottom-tab-react-native-4.png#dark-mode-only)

- Now that we have our TabShape ready we need to turn our `TabBar` into an absolute component, so we can add a shape to it:

```javascript
import { Dimensions } from 'react-native'
import TabShape from './TabShape'
const TAB_HEIGHT = 80;

const { width } = Dimensions.get('window')

const styles = StyleSheet.create({
  myTabBarContainer: {
    position: 'absolute',
    height: TAB_HEIGHT,
    width,
    shadowOffset: {
      width: 0,
      height: 0,
    },
    shadowOpacity: 0.2,
    elevation: 5,
  }
})

const MyTabBar = ({...}) => {
return (
    <View style={styles.myTabBarContainer}>
      <TabShape />
      <View style={StyleSheet.absoluteFill}>
        <View style={{ flexDirection: 'row', flex: 1, alignItems: 'center', justifyContent: 'center' }}>
          {state.routes.map((route, index) => {
            const {options} = descriptors[route.key];
            const label =
              options.tabBarLabel !== undefined
                ? options.tabBarLabel
                : options.title !== undefined
                ? options.title
                : route.name;

            const isFocused = state.index === index;

            const onPress = () => {
              const event = navigation.emit({
                type: 'tabPress',
                target: route.key,
                canPreventDefault: true,
              });

              if (!isFocused && !event.defaultPrevented) {
                navigation.navigate(route.name);
              }
            };

            const onLongPress = () => {
              navigation.emit({
                type: 'tabLongPress',
                target: route.key,
              });
            };

            return (
              <TouchableOpacity
                key={index}
                accessibilityRole="button"
                accessibilityState={isFocused ? {selected: true} : {}}
                accessibilityLabel={options.tabBarAccessibilityLabel}
                testID={options.tabBarTestID}
                onPress={onPress}
                onLongPress={onLongPress}
                style={styles.button}>
                {options.tabBarButton ? (
                  <TabBarButton />
                ) : (
                  <Text style={isFocused ? styles.label : styles.inactiveLabel}>
                    {label}
                  </Text>
                )}
              </TouchableOpacity>
            );
          })}
        </View>
      </View>
    </View>
  );
}
```

## Results
Finally, we have our goal done!!! Take a look at that:
![Screen Shot 2021-04-24 at 17.49.31](/assets/_uploaded/curved-bottom-tab-react-native-5.png)

## Conclusion
It was definitely a challenge that we've faced, but we made it! Thanks to you, as I'm seeing you reached the end of it, hope you understood the whole tutorial without problems. Let me know if you have doubts or encountered issues. Stay tuned!

You can check the [repository example](https://github.com/brunofrigeri/curved-bottom-tab) for the full implementation.

Curved Bottom Tab in React Native using SVG and D3-Shape

A lot of people, like me, are trying to get jobs outside their own country so to be able to do that we need to learn and master other languages.
In the programming world (and to be honest, in almost all areas that involve technology in some degree), the universal language is the english.

With that, beyond mastering communicating (which I mean, talking and listening) in those languages, we need to write our CV, blog posts and copies in this universal language.
So, today I'll be writing about how to manage a multi-language website using Next.js.

## Setting up the Project

Let's set up our Next.js project using the `create-next-app` lib, which give us a pretty good template (you can follow up to see options in [here](https://nextjs.org/docs/api-reference/create-next-app))

```bash
npx create-next-app@latest
# or
yarn create next-app
# or
pnpm create next-app
```

Altought Next.js providers internationalised routing, it doesn't handle management of translation content, so to be able to achieve that we're going to install `next-i18next` dependency for our project:

```bash
yarn add next-i18next react-i18next i18next
# or
npm install --save next-i18next react-i18next i18next
```

## Configuring Next.js with I18n

Following the `next-i18next` documentation, we need set up the project for it:

1. First, create a `next-i18next.config.js` file in the root of your project. 
- Inside it we need to add the locales configuration, based on your locale languages, which in my case is:

```javascript
  module.exports = {
    i18n: {
      defaultLocale: 'en',
      locales: ['en', 'pt-BR'],
    },
  }
```

2. Next, we're going to modify the `next.config.js` file, by passing the i18n config that we previously set up on our `next-i18next.config.js` file.

```javascript
const { i18n } = require('./next-i18next.config')

module.exports = {
  {...}
  i18n,
}
```

3. Now we need to create a `locales` folder inside `public` and create our different languages folder with a `common.json` file each. It's important to say that the `common.json` it's basically a set of texts that will be used for all components, but you can create others for specific components)

```
└── public
    └── locales
        ├── en
        |   └── common.json
        └── pt-BR
            └── common.json
```

4. Mostly important and the last step of the configuration, we need to connect the I18n with our app. Open the `pages/_app.js` directory and wrap the default export with `appWithTranslation` from `next-i18next`, following as below:

```javascript
import '../styles/globals.css'
import { appWithTranslation } from 'next-i18next'

function MyApp({ Component, pageProps }) {
  return <Component {...pageProps} />
}


export default appWithTranslation(MyApp)
```

That's all! Now we have all configuration set up and we can start using it.

## Implementing different languages in components using SSR

It's important to know that `next-i18next` added support for using SSR, which basically can be done by using the `getStaticProps` or `getServerSideProps` from Next.js. But let's continue:

1. Let's define some example text in all our different locale folders, I will be creating a __title__ field:

```javascript
// locale/en/common.json
{
    "title": "Building a multi-language website with Next.js"
}
```

```javascript
// locale/pt-BR/common.json
{
    "title": "Construindo um website com suporte a diversas linguagens, utilizando Next.js"
}
```

2. As mentioned above, to have Next.js support, we need to use `getStaticProps`or `getServerSideProps` (you can check usage details of each [here](https://nextjs.org/docs/basic-features/data-fetching/get-server-side-props)). With the decision in place, we're going to import `serverSideTranslations` from `next-i18next` and add to our choosen method.

**getStaticProps**
```javascript
import { serverSideTranslations } from 'next-i18next/serverSideTranslations'

export const getStaticProps = async ({ locale }) => {
  return {
    props: {
      ...(await serverSideTranslations(locale, ['common'])),
    }
  }
}
```

**getServerSideProps**
```javascript
import { serverSideTranslations } from 'next-i18next/serverSideTranslations'

export const getServerSideProps = async ({ locale }) => {
  return {
    props: {
      ...(await serverSideTranslations(locale, ['common'])),
    }
  }
}
```

Another really important thing to remember is that we can have specific translations (as I mentioned prior) for each component. Let's say I created a new file in our locales named `example.json`, and we want to add the translation to the same component. We would do:

```javascript
export const getStaticProps = async ({ locale }) => {
  return {
    props: {
      ...(await serverSideTranslations(locale, ['common',
      'example']))
    }
  }
}
```

3. Last, the display!! Let's add the translation itself to our Component. Let's import `useTranslations` from `react-i18next` dependency and destructure it to get property `t` (which will be then used for translating):

```javascript
import { useTranslation } from 'react-i18next'

export default function Home() {
  const { t } = useTranslation('common')

  return (
    <div>
      <main>
        <h1>
          {t('title')}
        </h1>
      </main>
    </div>
  )
}

export const getStaticProps = async ({ locale }) => {
  return {
    props: {
      ...(await serverSideTranslations(locale, ['common']))
    }
  }
}
```

## Seeing the Results

Accessing your `YOUR_URL/$LANGUAGE`, which in my case is `http://localhost:3000/${CURRENT_LANGUAGE}`.

**English -** `http://localhost:3000/en`

![MY_WEBSITE_IN_ENGLISH](/assets/_uploaded/building-multilanguage-nextjs-1.png)

**Portuguese -** `http://localhost:3000/pt-BR`

![MY_WEBSITE_IN_PORTUGUESE](/assets/_uploaded/building-multilanguage-nextjs-2.png)

## Conclusion

There we have it! I hope the post it's clear and you guys were able to follow. Feel free to tag me into any doubts and providing any feedbacks. In **part 2**, we're going to understand on how to build a simple toggle for changing languages! Stay tuned

To check all the work done here, you can go to the [GitHub Repository](https://github.com/brunofrigeri/multi-language-nextjs)


Hey, I'm Bruno.Nice to meet you!

Writing

Your AI Should Ask Your Team Before It Asks the Model

How I Built the Most Used Repo in Identity Platform at Coinbase

Global Status Modal HOC

Curved Bottom Tab in React Native using SVG and D3-Shape

How to build multi-language website with Next.js (PART 1)