DEV Community: Isaac C.

Entering the Outro: Considerations on Evaluating the Kendrick v. Drake Rap Battle

Isaac C. — Wed, 08 May 2024 12:22:25 +0000

Hip Hop History has been made

Kendrick Lamar vs. Drake will go down as a historical moment in Hip Hop. Their rap battle is likely the peak of their shared history beginning with them collaborating, then (maybe) becoming friends, disagreeing with each other’s decisions, leading to years of numerous sneak dissing. When the moment came for them to battle, they each produced an impressive array of high quality diss records. They were already highly skilled, and grasping at legendary status. With this battle, their names in Hip Hop history are forever etched.

Of course discussions on who won and who lost will go on for quite awhile. Some will vehemently believe it was Drake. For others it will undeniably be Kendrick. And others will never quite subscribe to a single winner. No matter the stance, discussions will continue.

As such, there are some important considerations worth noting as we enter this rap battle’s epilogue.

The Rap Battle

First, we should confine our definition of rap battle. For the purposes of this article, we will restrict the discussion of rap battles to the public production of diss records/songs about another artist. We will only focus on cases where the artists are producing records to be consumed by the general public, often distributed by CD’s, radio, or streaming platforms.

At the core of a rap battle, is answering one question, “If this rapper focused solely on rapping about/against that rapper, who wins?” That is it. A rap battle is competitive art, it is sport. Can you string together a plausible set of truths or analysis, given what you know and what information is out there about another person, and compose a better diss record? A more mild version of the rap battle is school-ground clowning. You are tasked with using observations, and creativity to compose a joke that’s undeniably funnier than your opponent in order to render them the (bigger) clown. It’s a game.

"Where's the proof"

As funny as a “yo mama” joke may be, no one is actually asking for proof that when someone’s mother turns around, the earth has, in fact, spun on its axis. It’s a joke at the expense of another. Similarly, in the moment of the rap battle, proof is not a necessity. That doesn’t mean proof is not valuable. It can absolutely supercharge a bar, and even change the course of the battle, but in the moment of the battle, proof is not a primary consideration. The primary inquiry surrounds the question, “who has the better bars?”

A rap battle is not investigative journaling over beats. Rappers are not required to collect information and produce documents, videos, books, and analysis on their opponent. A rap battle is not the forum for the presentation of that type of content. And although news or gossip may result from a rap battle, that production is not an obligation for the rapper, especially while competing. Their primary goal is to prove that they are the better rapper. The “receipts” can help, but they’re a secondary concern.

A rap battle is also not a moral or ethical competition for its participants. Rappers are not tasked with explaining why their opponent is an evil, or worse person than they are. They can use that as a tactic to win, but it isn’t the place of a rap battle to evaluate who is the better member of society. That’s not what the competition was designed for. And the competitive arena of a rap battle, given the speed and general desire to win, is not capable of being a stable ground on which to discuss how moral or ethical a person is. A rap battle is a place to dismantle your opponent as quickly and artistically as you can, while also doing your best to ensure your reputation remains intact. It does not have the time or space to nurture a discussion on who is more moral or ethical. And to expect that a rapper will prove that they are the more moral or ethical person than their opponent is an undue burden. That does not mean the audience is precluded from that discussion. The audience participates in the event as a witness. They are not bound by the same time restrictions as the rappers (e.g. they can leave and come back and the battle will continue). The audience has the capacity to facilitate that discussion. But it is not a requirement for the rappers to bring up, or address their own, or their opponents proximity to morality.

"Pedo Allegations Were Too Far"

Pedo(philia) allegations are serious, and one could absolutely make the argument that Kendrick took it to far to make those accusations. That is a worthy debate to have. At the same time, we should consider that even though there aren’t many rules in a rap battle, there are some. And among them, the most well-known rule is to not mention another person’s partners or children, and that if you do, every topic is available. Pusha T is among the recent artists to highlight this rule. Specifically, he (Pusha T) stated that Drake’s mention of his partner, by name, is why he took their rap battle to the next level of disrespect.

Keeping in mind that a rap battle is a competitive sport, wherein proof is not required at the moment of the battle, a rapper only needs to make plausible claims. If there is some content, that could allow the audience to believe the claim, and the other artist has crossed the “line in the sand”, then the door is open to move in that direction. It doesn’t mean that the rapper has to, or even that they should, it only means that they can.

Again, let’s be clear, pedo allegations are serious. They are not a joke (and especially if they’re made out of thin air) it should be avoided. Rappers do not have a license to blatantly lie, and they shouldn’t. They should be held accountable and called out whenever a line is crossed. But they are not journalists. And we are not in a court of law. Rappers are artists, and storytellers, and musicians. The product of their work has and will always have a fluid relationship with reality.

I am not interested in definitively stating whether or not Kendrick took it too far, or even if Drake took it too far. Considering one of the core rules of rap battles, the proverbial gloves were removed early into the battle. And once the gloves are off, it’s not always easy to find exactly where they are placed.

"Kendrick was too hateful"

A rap battle is a strategic endeavor. The term “battle” is not in the name simply to sound nice. It is a metaphorical battle. And in a battle, you typically want your opponent to believe you are are bigger, badder, more resourced, more prepared, and all around more ready and capable of easily dismantling and defeating them. You want them to fear you. Both Drake and Kendrick understand this, and they always have. Their early diss records, both “Push Ups”/“Taylor Made” and “Euphoria”/ “6:16 in LA” are littered with warnings, and reminders, that they are the best and that the other should not continue down the war path.

None of us actually knows if Kendrick hates Drake. And to callback to the earlier point on the goal of the rap battle, it doesn’t really matter if he does or not. He really just needs Drake to believe it. The audience believing it is a bit of a bonus. He needs Drake to truly believe that he has a deep well of resentment, and anger to source his greatest rapping ability from. He needs Drake to believe that he is “the boogeyman”. Because if Drake believes that his opponent is not only skilled and maybe crazy, but also deeply hates him, then the dynamics of the battle have shifted. Kendrick will have mentally moved the board in his favor. Hate, in this case is an intimidation tactic first and foremost. The validity of Kendrick’s hate is a secondary matter.

"People just wanted to see Drake Lose"

This may be true, some certainly feel this way, and some don’t, and some initially believed Kendrick was the underdog. It doesn’t help that very little of this is verified (and maybe even verifiable). Regardless, proving this is inconsequential. Drake and Kendrick are two of the most popular rappers of our generation. They can and have produced globally recognized, hit records, on multiple occasions. They can write a song, and a damn good one at that. They know it, we know it, and they consistently remind us. Each of them has repeatedly rapped that they are the greatest of all time, they are the King, and there is no other rapper above them (especially in their generation).

Consequently, if statements like that are made, and there’s some data to back it up, as there is (e.g. sales, streaming, awards etc.), then as greats they can and are expected to overcome the audience’s predispositions. The craving for their loss is not a valid excuse. It is a reason why one person may have had more to overcome than the other, but it’s not enough of a significant hindrance, or a justifiable reason for why they, as the greatest to ever rap, lost.

Even if the audience wanted to see Drake lose, he absolutely has the ability to make a record, so clearly good, that it has to be admitted as being such, even by his detractors. And if he is truly the best, and there is no question, then the desire to see him lose is only eligible for being a noticeable obstacle, it is not eligible for being the sole reason he lost.

"Drake is not a colonizer, they worked with him"

This discussion has many layers to it. It intertwines thoughts on Blackness, colonialism, capitalism, and the global diaspora. This is probably the most complex topic to come from their rap battle and it is likely best kept in it’s own, separate article, where it can be treated with the proper time and care it deserves.

What is worth addressing is the notion that the rappers he worked with benefitted from him, and therefore he can’t be a colonizer. Whether or not he is an actual colonizer is for another place. The worthy note to make is that there are forms of colonialism where the people being colonized are “benefitted” (it may even be considered a constituent element). Essentially, the colonized receive something they desire. The asterisk to that reception, is that whatever they receive will never equal or supersede what the colonizing entity receives. It is a (potentially very) uneven trade.

"__ won and that's it"

Who won is going to be debated for quite a while. And there is no definitive “right” or “wrong” answer. Two people can view the same record multiple ways.

The important aspect to remember is that you can change your mind. It’s okay. No matter what you think or feel today, you are able to reevaluate at any time. Receipts and evidence may come out that alters your original (maybe even public) assessment. That’s okay. It’s your thoughts on the winner of a rap battle, your opinion is not set in stone. You can absolutely revisit it.

Drake and Kendrick remain highly skilled rappers. There is no question or change in the fact that they can write and perform a hit record. These are the two biggest artists of our time, who battled it out. The ending of the battle does not mean they are done.

A rap battle, especially a good one, is a moment in time. It is the moment a pot boils. It’s hot, and dangerous to touch without being prepared and thinking it through. But as all things, it cools down, it ends. And we are tasked with returning to our lives, grateful that we were present for such a historical event.

A (Simple) Modal Management Option for React Native

Isaac C. — Sat, 13 May 2023 12:23:06 +0000

We talking about modals

Your basic modals aren't that difficult to build. For a simple modal, you'll want to be able to open it and close it. You'll probably use some form of isVisible or open prop set to true/false, and maybe some neat animations so that the modal slides/fades when it enters or exits the user's view. But the modal itself isn't the focus of this article. The focus is on how we manage those modals across the application.

In my case, I joined a team, and we started this process of refactoring large portions of the application. And I realized that it might be beneficial to take this time and revisit and refactor the modal management logic. The logic worked, but it wasn't in a style we wanted to maintain. And after expressing this, it was agreed that I could refactor it.

Originally, I wanted to adopt an approach that I had experienced in a previous role. But I couldn't remember the exact implementation details (maybe a sign that they were well-hidden hahaha).

I did remember that we might have used some form of portal, and I considered doing the same. The problem is that React Native doesn't exactly support portals (out of the box), which is understandable. I could have (and probably easily) used a package and commenced, but we were in the middle of a major refactor and no one was thrilled to add a new package. So, I had to do this from scratch, only using native React Native tools.

The Requirements

The first thing we did was list our base-level requirements:

Context should handle the modal opening/closing - Some form of context should hold the internal logic for how the modal is shown.
Hook as an Interface - Components should use a hook as an interface for opening a modal (i.e. the component shouldn't directly use the context)
Pass Custom Data - We should have the ability to pass data (we'll call props) to the hook and have those props be received by the rendered modal
Support Custom and Default modals - The consumer can pass/request their own custom modal if they need to. And if they don't specify a modal, a default modal is loaded and will be rendered with the props passed to it.

Those were the "Final 4" of our absolute needs. The bonuses would have been 5) Easy animation handling, and 6) Support for modal-in-modal (I know, this is bad hahaha but sometimes you're asked for it, and pushing back doesn't work 🤷🏾‍♂️). But we really just wanted something clear, and easy to use, that would last if we couldn't get around to refactoring it in the near future.

And that's when I found this article suggesting something similar to what we wanted. But, for us, it wasn't exactly what we wanted. And we opted not to fully adopt it. But the overall approach was in the right direction. So we took the core pieces and made some slight modifications. And below is how that looked...

Building the Context

First, we built the context

import React, { createContext, useCallback, useState } from 'react';
import { DEFAULT_MODAL } from '@components/CustomModal'

const ModalContext = createContext();

const DEFAULT_PROPS = {
  content: null,
  description: '',
  primaryCTA: null,
  secondaryCTA: null,
  shouldCenterTitle: true,
  shouldShowClose: true,
  title: '',
};

const ModalProvider = ({ children }) => {
  const [modalName, setModalName] = useState('');
  const [modalProps, setModalProps] = useState(DEFAULT_PROPS);

  const openModal = ({ modalName: mName = DEFAULT_MODAL, props }) => {
    if (mName) {
      setModalName(mName);
      setModalProps({ ...modalProps, ...props });
    }
  };

  const closeModal = () => setModalName('')

  const value = {
    closeModal,
    modalName,
    modalProps,
    openModal,
  };

  return <ModalContext.Provider value={value}>{children}</ModalContext.Provider>;
};

export { ModalProvider, ModalContext };

Let's review this. The context is storing 2 pieces of state and exposing 4 things:

The context stores the name of the modal. You can think of this a bit like a key in an object
The context also stores the data that is intended to be passed to the modal, which we call modalProps
And the 4 things this context exposes are: a) The ability to open the modal (by passing as an argument, the name of the modal, and the props intended to be passed to the modal) b) The ability to close the modal (wherein the Context will remove the name) c) The name of the modal set in state d) The props (object) to be passed to the modal

Remember our (overall) goal was to get the 4 requirements listed above. And this context got us there. But it's not the only thing we would need.

Building the adjacent Hook

The context was our core, but we didn't want everyone digging into that core directly. We wanted an interface, and that's where the hook came in. So we built this:

import { useContext } from 'react';
import { ModalContext } from '@context/ModalContext';

export const useModal = () => {
  const context = useContext(ModalContext);

  if (!context) {
    throw new Error('useModal must be used within a ModalProvider');
  }

  return context;
};

This hook is again, trying to be as simple as possible, it's really just returning the context, and only throwing an error if we're operating outside of the provider.

Adding the Provider to the App

Speaking of the Provider, before we forget, let's be sure we have that setup. Here's what we did, and it should look familiar.

import { CustomModal } from '@components/CustomModal'

export const App = () => {
  return (
    <ModalProvider>
       <CustomModal /> {/** Continue reading (please)... **/}
       {...YOUR_OTHER_COMPONENTS_AND_PROVIDERS_ETC}
    </ModalProvider>
  )
}

The Actual Modal Component

At this point, you might be asking, "Where in the world is the actual modal that gets rendered? I've seen ModalContext's that conditionally render the modal inside of it, where's your modal?" And you'd be 100% right to ask those questions. Here it is:

import React, { useCallback } from 'react';
import { TransactionModal } from '@modals/TransactionModal';
import { FunUserModal } from '@modals/FunUserModal';
import { useModal } from '@hooks/useModal';

export const DEFAULT_MODAL = 'a string I like';
export const FUN_MODAL = 'another one of my favorite strings';

export const MODAL_LIST = {
  [DEFAULT_MODAL]: TransactionModal,
  [FUN_MODAL]: FunUserModal,
};

export const CustomModal = () => {
  const { closeModal, modalName, modalProps } = useModal();

  const renderModal = useCallback(() => {
    const Component = MODAL_LIST[modalName];

    return (
      <Component
        {...modalProps}
        closeModal={closeModal}
        isOpen={!!modalName}
      />
    );
   }, [closeModal, modalName, modalProps]);

  if (!modalName) {
    return null;
  }

  return renderModal();
};

We can read through this together. And we can start with, where is this getting rendered. This component is rendered in 1 place, in the App.js (as you've seen above), this gets rendered nowhere else. Let's review the section before the component, and then get into the actual component.

Checking out our own little "static store"

At the top of this component, we have a simple key in the format below.

const NAME_OF_MODAL_TO_BE_USED_EVERYWHERE = "string-that-will-only-be-used-as-the-value-of-the-key"

Then we have the object holding the location of the Modals, in the format below. You can think of this as a "static store" (i.e. it's not dynamic on its own, you have to add and remove components and change the keys manually). This object's keys are the above consts, and the key's values are the references to actual React components.

const LIST_OF_ALL_MODALS = {
  [NAME_OF_MODAL_TO_BE_USED_EVERYWHERE]: ActualReactJSComponent
}

Diving into the component

Next, we have the actual component. At the top of the component, we are destructuring from the hook, the modalName, the modalProps, and the closeModal function. All of these are stored within the ModalContext, and are made available to this component via the useModal hook.

export const CustomModal = () => {
  const { closeModal, modalName, modalProps } = useModal();

  const renderModal = useCallback(() => {
    const Component = MODAL_LIST[modalName];

    return (
      <Component
        {...modalProps}
        closeModal={closeModal}
        isOpen={!!modalName}
      />
    );
  }, [closeModal, modalName, modalProps]);

  if (!modalName) {
    return null;
  }

  return renderModal();
};

Then we have a function (called renderModal) that uses the modalName, by passing it as a key to the MODAL_LIST object, and in turn receiving the React component (i.e. the modal). Once it has the component, it returns it, while spreading the modalProps onto it, along with the closeModal function, and coercing modalName into a boolean which will determine when the modal should be opened. Meaning, if this function is called, it will return (and thereby render) a React component, or more specifically a modal (hence the name renderModal).

Finally, if we attempt to render this component without a modalName, it simply returns null. Otherwise, it calls the function, and the function returns the rendered component, thus rendering the modal.

How do we use this interface in our components?

That's all well and good, but how do we use this? What does using this interface look like for the individual components? Well, there are 2 options:

Option A: Using the default modal

If we just want to use the default modal (i.e. we don't want to have to build a new modal), we can do the below. We don't need to pass a name because the openModal function has a default argument that sets the modalName to the default modal. We pass only the props that we want to be passed to the modal.

export const MyComponent = () => {
  const { openModal, closeModal } = useModal();

  const onPress = () => {
    openModal({
      props: {
        title: 'Do you exist?',
        description: "Please confirm your existence",
        primaryCTA: {
          backgroundColors: [Colors.myColorOne, Colors.myColorTwo],
          buttonTitle: 'Yes, I do',
          colors: Colors.black,
          onPress: () => {
            console.log("You clicked the primary 'call to action' button")
          }
        },
        secondaryCTA: {
          backgroundColors: [Colors.myColorThree, Colors.myColorFour],
          buttonTitle: "No, I don't",
          colors: Colors.black,
          onPress: closeModal,
        },
       },
     });
    }

  return <View>{/** Component with some button that has the onPress prop **/}</View>

Option B: Using a custom modal:

If we don't want to use the default modal (i.e. we need to build a fully custom modal), we can use the openModal function and pass the name of the modal, and the props we want to be spread onto it.

export const MyComponent = () => {
  const { openModal } = useModal();

  const onPress = () => {
    openModal({
      modalName: FUN_MODAL,
      modalProps: { onDelete: deleteActionFunction },
    });
  };

 return <View>{/** Component with some button that has the onPress prop **/}</View>

What are the Tradeoffs or Things to consider?

Without types, the props passed to the modal are quite loose - There's no type safety on the modalProps. This means, almost anything can be added to that object. That's not necessarily the worst thing (it can maybe even be argued that it's a good thing). But on top of that, we're spreading the props, which has its own detriments. One of them is that you're not 100% sure what's getting spread unless you investigate. If we were implementing this in TypeScript, I'd recommend using some form of generic so that the props object being passed to the hook is a bit clearer and more restrictive. Regardless, of whether or not you love/hate this "object freedom", it's worth keeping in mind.
We are using strings - This might be a bit of a nitpick, but for this use case, I'm not a big fan of using strings. In general string literals can easily be misspelled, accidentally changed, etc. Here, we alleviate some of this worry by using a const that holds the string literal. This allows us to rely on the import statement, as well as IntelliSense when we want to pass a modalName. We are also using the ALERT_LIST object's built-in key-value syntax to actually find the component. However, we do have to type the name of the key twice (i.e. once as a standalone const, and then again as the key in the object) but that's a price we were willing to pay.
We call it modalProps and modalName when we maybe could just call it modal and props, but we felt like modal sounded a bit like a standalone component, and props a tad too vague. Sure, the context of the names should help shed light on their meaning, and this is certainly more of a preference but we wanted a little bit more verbosity.
- Speaking of names, CustomModal might be better named ModalViewer or ModalViewManager, since it's not literally a modal, it only returns a modal. I'm (always) open to hearing better names and why they're better. But this was a bit of a nitpick for us as we had quite a significant amount of refactoring left. So we stuck with CustomModal as our name and moved on.
What happens when a string is passed that isn't represented by a component - This is a valid point and something we'll likely fix soon. We could throw an error when a matching component isn't found. In TypeScript, maybe some form of union of string literals could be helpful to use to restrict rogue strings from getting passed in. I'm not sure if an enum would make the most sense, but I'd be open to hearing why it might. Overall this is something to think about. And I might add, it could be a bit of a result of #2 (that using strings, in this manner, has tradeoffs).
Modal-in-Modals - I'm not sure this implementation can clearly and easily support opening a modal on top of another modal. But to be fair, supporting this ability was a bonus, not a requirement. It does technically give us a little ammo to push back on any modal-in-modal designs 😉 But since this wasn't a requirement for us, we're okay with not being able to support this.
Animation - This approach sort of precludes us from using the native Modal features/props that have to deal with opening and closing the modal. The rendering of the modal is fully controlled by the coercion of the modalName to a boolean. Once it's false, the modal is no longer rendered, regardless of the animation props on it. We could make use of React Native's Animated API to resolve this. But it's not the option built specifically for modals, and that made us a little sad. But animation was a bonus, not a requirement, so we're a little less sad.
It takes a second to see what's happening - We think this implementation is simple and clear. But that's a bit subjective. It's totally valid that coming into this, for the very first time, could be slightly jarring. That's part of why we opted for some of the naming verbosity. We thought it might help make the behavior clear.

I think it's worth noting that this list of Tradeoffs and Things to Consider is not exhaustive. As with everything (especially in software design), there are many tradeoffs. These are only the first few that kind of "poked us in the side". In the end, we deemed them acceptable in the short term. Some we'll get around to fixing soon (i.e. error handling, and animations), and others we'll live with. Are there more tradeoffs? Yes, most likely, but perfect doesn't exist, and for now (and for us) this implementation is good.

Conclusion

This implementation is very simple (at least it's intended to be). The file lengths are small, the names are verbose, and it can be quickly read, and improved by engineers at (just about) all levels. That's intentional. As much as we (currently) like this, this implementation is not meant to be used forever (at least for us). It's a placeholder structure that's simple and would be relatively easy for us to re-work the inner implementation details without having to destroy the components using the interface. We know in the future that:

We will probably want some form of Context that manages our modals
We will probably want a hook that provides an interface to the Component for the context
We will probably want to pass props that will be received by the rendered modal
We will probably want a default component rendered if we don't pass one, and a custom component rendered if we do

This is an option, there are many more with different tradeoffs to consider. But the above implementation gets all four of those items relatively well. Hopefully reading about this implementation helps you in your own modal management scheming, and/or inspires you to modify (this) and write about it for others to learn, discuss, and share.