DEV Community: Keke Arif

Cleaning up Decodable Responses with Enums in Swift

Keke Arif — Mon, 10 Aug 2020 11:20:46 +0000

Let's have a quick discussion about how to clean up your response objects using enums with associated values. I am assuming you are usingSwift's Decodable protocol for parsing data. If you're not using it and still stuck using a 3rd-party then it's time to make the change. Don't be a dinosaur. Let's take a look at an example API response.

  "posts": [
    {
      "id": 1,
      "content_type": "text",
      "description": "Hello world",
      "image_url": null,
      "cta_type": "url",
      "cta_url": "goole.com",
      "cta_file_url": null
    }
  ]

cta_type is defined on the backend as:

enum content_type: {
    text: 0,
    image: 1,
  }

enum cta_type: {
  no_action: 0,
  url: 1,
  deep_link: 2,
  file: 3,
}

This response is describing a post object in our app. It can be either a text or image. It can also have an optional call-to-action button that either opens a url, uses a deep link or opens a file (PDF). First lets check out the most obvious struct implementation.

struct Post: Decodable {
  private enum CodingKeys: String, CodingKey {
    case id
    case contentType = "content_type"
    case desc = "description"
    case imageURL = "image_url"
    case ctaType = "cta_type"
    case ctaFileURL = "cta_file_url"
  }

  enum ContentType: String, Decodable {
    case text, image
  }

  enum CTAType: String, Decodable {
    case url, file
    case noAction = "no_action"
    case  deepLink = "deep_link"
  }

  let id: Int
  let contentType: ContentType
  let desc: String?
  let imageURL: String?
  let ctaType: CTAType
  let ctaURL: String?
  let ctaFileURL: String?
}

We get the benefit of the free init(from decoder: Decoder) method from the above implementation however there is a glaring problem with this response object. Consider configuring the UI by using switch on contentType.

switch contentType {
case .text:
  guard let desc = desc else { return }
  setupTextView(with: desc)
case .image:
  guard let imageURL = imageURL else { return }
  setupImageView(with: imageURL)
}

After switching the enum we have to try and access the properties for desc and imageURL separately, this makes the enum pretty redundant. A much more swifty way of dealing with this type of data would be to use enums with
associated values. We can make this magic happen by implementing our own init(from decoder: Decoder) method. Below is the cleaned up version.

struct Post: Decodable {

  // MARK: - Coding Keys

  private enum CodingKeys: String, CodingKey {
    case id
    case content = "content_type"
    case desc = "description"
    case imageURL = "image_url"
    case action = "cta_type"
    case ctaURL = "cta_url"
    case ctaFileURL = "cta_file_url"
  }

  private enum ContentKeys: String, Decodable {
    case text, image
  }

  private enum ActionKeys: String, Decodable {
    case url, file
    case none = "no_action"
    case deepLink = "deep_link"
  }

  // MARK: - Properties

  enum Content {
    case text(String), image(URL)
  }

  enum Action {
    case none, url(URL), deepLink(String)
  }

  let id: Int
  let content: Content
  let action: Action

  // MARK: - Decodable

  init(from decoder: Decoder) throws {
    let container = try decoder.container(keyedBy: CodingKeys.self)

    let content = try container.decode(ContentKeys.self, forKey: .content)
    let desc = try container.decode(String.self, forKey: .desc)
    let imageURL = try container.decode(String.self, forKey: .imageURL)
    let action = try container.decode(ActionKeys.self, forKey: .action)
    let ctaURL = try container.decode(String.self, forKey: .ctaURL)
    let ctaFileURL = try container.decode(String.self, forKey: .ctaFileURL)

    id = try container.decode(Int.self, forKey: .id)
    order = try container.decode(Int.self, forKey: .order)

    switch content {
    case .text:
        self.content = .text(desc)
    case .image:
        if let imageURL = URL(string: imageURL) {
            self.content = .image(imageURL)
        } else {
            throw someCustomError()
        }
    }

    switch action {
    case .none: self.action = .none
    case .deepLink: self.action = .deepLink(ctaURL)
    case .file:
        if let ctaFileURL = URL(string: ctaFileURL) {
            self.action = .file(ctaFileURL)
        } else {
          throw someCustomError()
        }
    case .url:
        if let ctaURL = URL(string: ctaURL) {
            self.action = .file(ctaURL)
        } else {
            throw someCustomError()
        }
    }
}

There are a couple of improvements:

I am now using three very concise properties id and the enums content and action, both of which use associated values.
I have improved the naming of properties e.g. Content instead of ContentType. It's no necessary to follow the backend's naming scheme if something seems unclear so remove ambiguity at the client level.

Note that I also throw a custom error if decoding fails and I declared two new enums ContentKeys and ActionKeys to help decode the raw part of the response.

It's now much easier to use the data:

switch contentType {
case .text(let desc):
  setupTextView(with: desc)
case .image(let imageURL):
  setupImageView(with: imageURL)
}

Thanks for reading. Hope this helps you when writing response objects. If you enjoyed the post give me a follow on Twitter @keke_arif.

Cheers,

Keke

Understanding State and Lifecycle in React

Keke Arif — Mon, 03 Aug 2020 14:27:23 +0000

When does a component re-render? What about mounting? It's easy to just rush over these concepts and continue on with a shallow understanding, however they will eventually come back to bite you. Let's clear them up once and for all.

Rendering

Think of rendering as just drawing the UI to the screen. When we talk about UI in React we are referring to components.

import React from 'react';

const App = () => {
  console.log('render app');
  return <h1>Hello World</h1>;
};

export default App;

App is a component and when the application is run React needs to render it to the screen. A component can also re-render because of some changes made. This usually goes hand in hand with updating state.

import React, { useState } from 'react';

const App = () => {
  const [title, setTitle] = useState('Hello World');

  const buttonHandler = () => {
    const newTitle = title === 'Hello World' ? 'Goodbye World' : 'Hello World';
    setTitle(newTitle);
  };

  console.log('render app');

  return (
    <div>
      <h1>{title}</h1>
      <button onClick={buttonHandler}>tap</button>
    </div>
  );
};

export default App;

Tapping on the button above will trigger the render again. This is confirmed in the console output. Let's examine what happens if App has a child component.

const SomeChild = () => {
  console.log('render a child');

  return <h1>I'm a child</h1>;
};

const App = () => {
  const [title, setTitle] = useState('Hello World');

  const buttonHandler = () => {
    const newTitle = title === 'Hello World' ? 'Goodbye World' : 'Hello World';
    setTitle(newTitle);
  };

  console.log('render app');

  return (
    <div>
      <h1>{title}</h1>
      <button onClick={buttonHandler}>tap</button>
      <SomeChild />
    </div>
  );
};

export default App;

Both the parent and its child components are re-rendered. This is an important effect that state variables have. State variables will re-render the component they are in and all child components down the chain.

Component Lifecycle

Components go through a variety of lifecycle phases during the life of a React app.

The order of life is as follows:
1) A component is first initialized with its constructor function.
2) The component renders for the very first time.
3) The component mounts.
4) The component will render again if new props are set, a state is set or forceUpdate is triggered.

Mount and Unmount

As a React programmer the moments a component mount or unmount are important because this is where we usually call API code, set states or do cleanup. Two Simple rules to remember here:
1) When the component renders for the first time it mounts.
2) When the component's parent is no longer needed or the parent component performs an update that no longer renders the component it unmounts. This is easy to see in a typical React conditional statement.

import React, { useState, useEffect } from 'react';

const SomeChild = () => {

  useEffect(() => {
    console.log('mounted');
    return () => console.log('unmounted');
  });

  return <h1>I'm a child</h1>;
};

const App = () => {
  const [needsShowChild, setNeedsShowChild] = useState(false);

  const buttonHandler = () => {
    setNeedsShowChild(!needsShowChild);
  };

  return (
    <div>
      <button onClick={buttonHandler}>tap</button>
      {needsShowChild && 
        <SomeChild />
      }
    </div>
  );
};

export default App;

Hope that clear up some understanding. If you liked the post give me a follow on Twitter @keke_arif. Cheers.

Keke

A Simple Guide to React Context with Hooks

Keke Arif — Thu, 30 Jul 2020 10:31:57 +0000

It took me a while to get my head around using React Context with hooks, all the tutorials I read failed to explain it in a simple manner or seemed focused on class syntax. The class syntax is due to die soon so let me give it a try.

Why use Context?

Passing props down multiple child components can become unwieldy.

const [someState, setSomeState] = useState('cool value');

return <SomeBigDaddyComponent someState={someState} />

Now the implementation of SomeBigDaddyComponent.

const SomeBigDaddyComponent = ({ someState }) = {
  return <SomeMediumDaddyComponent someSate={someState} />
}

Now the implementation of SomeMediumDaddyComponent.

const SomeMediumDaddyComponent = ({ someState }) = {
  return <SomeSmallDaddyComponent someSate={someState} />
}

Now the implementation of SomeSmallDaddyComponent.........
It's becoming a mess right? This is about the right time to use context.

Creating and Broadcasting a Context

Context is essentially a way to broadcast data down a chain of child components without passing props. It's easier to explain by just doing it. Let's create a very simple context.

import React from 'react';

const CoolMessageContext = React.createContext('hello hello hello');

export default CoolMessageContext;

I initialized the context above with a simple string, however this can be any value and usually an object would be used. Now lets see how the context works. Consider App.js.

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

const App = () => {
  return (
    <CoolMessageContext.Provider value={'bye bye bye'} />
      <SomeBigDaddyComponent />
    </CoolMessageContext.Provider>
  );
}

The components that will have access to the context's value are wrapped in Provider. This is essentially saying "Hey I'm the provider of the value, anything below me will get that value". In the example above SomeBigDaddyComponent can get the value and also its children, SomeMediumDaddyComponent and SomeSmallDaddy. Anything above the provider can not access the value.

const App = () => {
  return (
    <div>
      <SomeOtherComponent />
      <CoolMessageContext.Provider value={'bye bye bye'} />
        <SomeBigDaddyComponent />
      </CoolMessageContext.Provider>
    </div>
  );
}

SomeOtherComponent does not have access to the value because it is sitting above the provider. Note that an initial value must be provided, here I provide 'bye bye bye'. Although an initial value was set with createContext this is really just a fail-safe value in case a value isn't provided when setting the provider.

Getting the Context's Value

Now the value is being broadcast we can go ahead and access it from any of the children. To get the value we will use the hook useContext.

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

const SomeSmallDaddyComponent = () => {
  const coolMessage = useContext(CoolMessageContext);
  return <h1>{coolMessage}</h1>
};

export default SomeSmallDaddyComponent;

The useContext hook is initialized with the context object and so that the value can be accessed without messy prop passing. You can think of useContext as providing a teleport for the value so that it can teleport down into the component that needs it.

Setting a Context's Value

A context's value can also be changed from anywhere in a similar manner if state is used.

import React from 'react';

const ObjectContext = React.createContext({
  object: {
    number: 0,
    word: 'hello'
  },
  setObject: () => {}
});

export default ObjectContext;

The above context is similar to what we used before but also has a property to store the set function for setState.

import React, { useState } from 'react';
import ObjectContext from './ObjectContext';

const App = () => {
  const [object, setObject] = useState({
    number: 1,
    word: 'bye'
  });

  return (
    // ES6 Object Property Value Shorthand 
    <ObjectContext value={{ object, setObject }} />
      <SomeBigDaddyComponent />
    </ObjectContext >
  );
};

The value above is set with the state object and also the state set function. Now setting the state from anywhere is the same as accessing the value.

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

const SomeSmallDaddyComponent = () => {
  const { object, setObject } = useContext(ObjectContext);
  const clickHandler = () => {
    const objectCopy = {...object};
    objectCopy.title = 'wow new title!';
    setObject(objectCopy);
  }
  return <button onClick={clickHandler}>{object.title}</button>
};

export default SomeSmallDaddyComponent;

That's the basic rundown of contexts! Let me know if I missed anything or you have any questions. If you like the post give me a follow on Twitter @keke_arif . Cheers.

keke