DEV Community: EchoEye

Database table structure for different notification events

EchoEye — Mon, 20 Dec 2021 14:41:52 +0000

I set out to build one of my favorite projects some time around June, and while I was able to complete it to some extent and successfully launched it, I did face some setbacks while trying to implement certain features in the application. One of the most difficult feature I had to implement was notifications. I spent quite some time trying to figure out how to model this form of data in the database. I am using a relational database (PostgreSQL). The main problem I faced with the notifications model was based on the requirements needed to store notifications in a way that still references certain rows and columns in multiple tables. Here's the explanation in details:

a. In the database, here's a User table that contains columns like id(primary key) name, email, profileUrl, etc

class User extends Model { }

User.init(
  {
    name: {
      type: DataTypes.STRING,
      allowNull: false,
    },
    bio: {
      type: DataTypes.STRING,
      allowNull: false,
      defaultValue: "Hey there!"
    },
    id: {
      type: DataTypes.UUID,
      allowNull: false,
      primaryKey: true,
      defaultValue: DataTypes.UUIDV4,
      unique: true,
    },
    username: {
      type: DataTypes.TEXT,
      allowNull: false,
      unique: true,
    },
    profile_url: {
      type: DataTypes.STRING,
      allowNull: false,
      defaultValue:
        "https://someimagesite.com/default_image.jpg",
    },
    email: {
      type: DataTypes.TEXT,
      allowNull: false,
      unique: true,
    }
  },
  {
    sequelize: instance,
    modelName: "users",
    tableName: "users",
    timestamps: true,
    createdAt: true,
    updatedAt: true,
  }
);


User.hasMany(Post, {
  foreignKey: "userId",
  foreignKeyConstraint: true,
  constraints: true,
  onUpdate: "CASCADE",
  onDelete: "CASCADE",
});


User.hasMany(Comment, {
  foreignKey: "userId",
  foreignKeyConstraint: true,
  constraints: true,
  onUpdate: "CASCADE",
  onDelete: "CASCADE",
});

Post.belongsTo(User)
Comment.belongsTo(User)

b. Here's a Post table that contains columns like id(primary key), content, title, userId, timestamp. "userId" references a row in the User table and it represents the author of the posts. It has a foreign key constraints set as "onUpdate: CASCASDE" & "onDelete: CASCADE" on the User table which ensures that when a user row is deleted/updated from the users table, any other references to the row in any table gets updated as well.

class Post extends Model { }

Post.init(
  {
    content: {
      type: DataTypes.TEXT,
      allowNull: false,
    },
    id: {
      type: DataTypes.UUID,
      allowNull: false,
      primaryKey: true,
      defaultValue: UUIDV4,
      unique: true,
    },
    userId: {
      type: DataTypes.UUID,
      allowNull: false,
    },
  },
  {
    sequelize: instance,
    modelName: "posts",
    tableName: "posts",
    timestamps: true,
    createdAt: true,
    updatedAt: true,
  }
);

Now, imagine we need to to display a notification to certain users in the following typical format(show picture of notification):
"@echoeyecodes just made a post"

In the sample format above, we can see a couple of references to certain attributes of 2 tables in the database.

a. username of user (User table)
b. post thumbnail (Post table)
c. description (Post table)
d. profile photo of user (User Table)
e. timestamp (Post table)

To model this as a table in the database for notifications, we'll need the following columns:

a. postId
b. userId
c. targetUserId (recipient of the notification)

class Notification extends Model {}

Notification.init(
  {
    id: {
      type: DataTypes.UUID,
      allowNull: false,
      primaryKey: true,
      defaultValue: UUIDV4
    },
    postId: {
      type: DataTypes.UUID,
      allowNull: false,
    },
    userId: {
      type: DataTypes.UUID,
      allowNull: false,
    },
    targetUserId: {
      type: DataTypes.UUID,
      allowNull: false,
    },
    isRead: {
        type: DataTypes.BOOLEAN,
        allowNull: false,
        defaultValue: false
    },
  },
  {
    sequelize: instance,
    modelName: "notifications",
    tableName: "notifications",
    timestamps: true,
    createdAt: true,
    updatedAt: true,
  }
);

Now to ensure our data here is consistent with the tables it references and avoid null data, we'll add foreign key constraints --> onUpdate: CASCASDE & onDelete: CASCADE to the userId, and postId columns to User and Post table

With this model, we can query for notifications on posts created by a certain user with no issues at all. But the 'gotcha!' in this is that it only works well for post notifications. What about when we need notifications for the following events:

a. when a user mentions another user in the content of a post?
b. when a user publishes a comment on someone else's post?
c. when a user mentions another user in a comment/reply
d. when a user likes a post
e. when a user likes a comment/reply

If we analyze these events, you'll notice that each event references certain columns in different tables beyond Post and User. We could go ahead and add more attributes like "commentId", "replyId" to our notification model to adjust to the requirements for notifications, but that would make our model contain redundant columns, and make it harder to debug or understand. We would also have more than a few null columns for a row that actually only references at most 2 tables.

How do we solve this problem?

I looked up for a conventional approach for storing notifications in databases, and found some that didn't exactly solve this specific issue, but gave me insights on how to resolve this. I didn't want to create separate tables for different kinds of notifications, especially when these notifications are expected to be arranged in a chronological order. Well, thanks to this stackoverflow answer, I figured that I could have a separate table for notification event-types, e.g (post-likes, comment-likes, post-mentions, comment-mentions etc) and a notification table that holds only generalized attributes for every form of notification. This notification will contain attributes like timestamp, eventId, recepientId since all forms of notification are expected to have these attributes. That was the first step towards the solution. So now we have an events table like:

class NotificationEvent extends Model {}

NotificationEvent.init(
  {
    id: {
      type: DataTypes.INTEGER,
      allowNull: false,
      primaryKey: true
    },
    type: {
      type: DataTypes.STRING,
      allowNull: false,
    }
  },
  {
    sequelize: instance,
    modelName: "notification_events",
    tableName: "notification_events",
    timestamps: true,
    createdAt: true,
    updatedAt: true,
  }
);


NotificationEvent.hasMany(Notification, {
    foreignKey: "eventId",
    foreignKeyConstraint: true,
    constraints: true,
    onUpdate: "CASCADE",
    onDelete: "CASCADE",
})

Notification.belongsTo(NotificationEvent, {
  foreignKey: "eventId",
  onDelete: "CASCADE",
  onUpdate: "CASCADE",
  foreignKeyConstraint: true,
  constraints: true
})

Then our revamped notification model would look like:

class Notification extends Model {}

Notification.init(
  {
    id: {
      type: DataTypes.UUID,
      allowNull: false,
      primaryKey: true,
      defaultValue: UUIDV4
    },
    eventId: {
        type: DataTypes.INTEGER,
        allowNull: false
    },
    targetId: {
      type: DataTypes.UUID,
      allowNull: false,
    },
    isRead: {
        type: DataTypes.BOOLEAN,
        allowNull: false,
        defaultValue: false
    },
  },
  {
    sequelize: instance,
    modelName: "notifications",
    tableName: "notifications",
    timestamps: true,
    createdAt: true,
    updatedAt: true,
  }
);

Going back to notification format for various events I listed above, I observed a pattern for each event:

(a) is a form of notification between a User and a Post table. That is pretty straightforward, so we can have a UserPostNotification table that contains the columns "userId" and "postId".
(b) is a form of notification between a Comment, and a Post table. So the main attributes needed here would be the commentId, and the postId for the PostCommentNotification table. With these columns we can easily construct our notification message by fetching the related data they reference. You know that a comment would always be from a User, therefore it would have a column called "userId" so we could fetch the user information based on this column to get data like username, and profileUrl. Also, every post has a "userId" attribute that references a certain user, so we could also get the user that owns the post based on this attribute and use it as the recipient of the notification.

We can now have something like @username commented on your post

(c) is a form of notification between a User and a Comment table. We can construct our notification message like the image below using only the attributes "userId" and "commentId".
(d) is also a form of notification between a User and a Post table. To get a message like the image below, we can obtain the information using the userId and postId attributes.
(e) is a form of notification between a "userId" and commentId and the message like @echoeyecodes liked your comment could be constructed using these two attributes.

After observing these patterns, I realized I could have a single table for notifications that are between a User & Post, User & Comment, or User & Reply. These tables would have an id attribute as primary key that references a row in the notifications table as a One-To-One Relationship. So to query all notifications in chronological order with the various attributes from different notification types, we could use an INNER JOIN for the Notification table and NotificationEvents Table, plus a LEFT JOIN with the UserPostNotification table, and PostCommentNotification table.

We could also insert an INNER JOIN clause to each of the sub-tables based on the parent tables they share constraints with, without having to re-query for these pieces of information after obtaining the foreignKey attributes since UserPostNotification would have foreign key constraints between a User and Post (userId, postId), PostCommentNotification would have a foreign key constraints between a Post and Comment userId, commentId).

here's how the UserPostNotification would look like:

class UserPostNotification extends Model {}

UserPostNotification.init(
  {
    notificationId: {
      type: DataTypes.UUID,
      allowNull: false,
      primaryKey: true,
    },
    sourceId: {
      type: DataTypes.UUID,
      allowNull: false
  },
    referenceId: {
        type: DataTypes.UUID,
        allowNull: false
    },
  },
  {
    sequelize: instance,
    modelName: "user_post_notifications",
    tableName: "user_post_notifications",
    timestamps: true,
    createdAt: true,
    updatedAt: true,
  }
);

then the PostCommentNotification:

class PostCommentNotification extends Model {}

PostCommentNotification.init(
  {
    notificationId: {
      type: DataTypes.UUID,
      allowNull: false,
      primaryKey: true,
    },
    sourceId: {
      type: DataTypes.UUID,
      allowNull: false
  },
    referenceId: {
        type: DataTypes.UUID,
        allowNull: false
    },
  },
  {
    sequelize: instance,
    modelName: "post_comment_notifications",
    tableName: "post_comment_notifications",
    timestamps: true,
    createdAt: true,
    updatedAt: true,
  }
);

Now to query for all notifications available for a particular user, we would query via the notification table and use a left join for various notification types available like:

const NOTIFICATION_INCLUDE_OPTIONS : IncludeOptions[] = [{model: User, required: true},
    {model: NotificationEvent, required: true},
    {model: UserPostNotification, include: [{model: User}]},{model: PostCommentNotification, include: [{model: User}, {model: Comment, include: [{model: User}]}]}]


async function getUserNotifications(userId:string(){
   const result = await Promise.all((await Notification.findAll({include: NOTIFICATION_INCLUDE_OPTIONS, where:{targetId: userId}}))
        .filter((item) => {
//here we filter off notifications with possible all notification type as null. this kind of state cannot possibly exist since every notification object would be of at least one type, but just to be safe, we need this check
            const result = item.get({plain: true}) as NotificationType
            if(!result.user_post_notification && !result.post_comment_notification){
                return false
            }
            return true
        })
        .map((item) => formatNotification(item.get({plain: true}))))
        return result
}

Finally, we can write a small utility function that constructs the notification message based on the event type for every notification like the one below:

async function formatNotification(instance:NotificationType){
    const type = instance.notification_event.type as NotificationEventType

   if(type == "post_comment"){
     //format notification based on requirements e.g @echoeyecodes commented on your post
   }else if(type == "post_create"){
     //format notification based on requirements e.g @echoeyecodes uploaded a photo
}
}

Replies are... well, comments too!

EchoEye — Mon, 13 Dec 2021 14:37:13 +0000

Last week, I did a bit of refactoring on Picashot's web service, and went through a rethink of how to store comments and replies in the database. I initially had 2 tables for this, a Comment table and Reply table. These tables had very similar columns, and the only thing that made them distinct in any way was that the Comment table had a comment column that holds the actual text of the comment, while the Reply table had a reply column for the reply text, and a columnID column that references the comment row it replies to.
Here's how the Comment model looks like:

class Comment extends Model { }

Comment.init(
  {
    userId: {
      type: DataTypes.UUID,
      allowNull: false,
    },
    id: {
      type: DataTypes.UUID,
      allowNull: false,
      primaryKey: true,
      unique: true,
    },
    comment: {
      type: DataTypes.TEXT,
      allowNull: false,
    },
    postId: {
      type: DataTypes.UUID,
      allowNull: false,
    },
  },
  {
    sequelize: instance,
    modelName: "comments",
    tableName: "comments",
    timestamps: true,
    createdAt: true,
    updatedAt: true,
  }
);

and now the Reply model:

class Reply extends Model {}

Reply.init(
  {
    userId: {
      type: DataTypes.UUID,
      allowNull: false,
    },
    id: {
      type: DataTypes.UUID,
      allowNull: false,
      primaryKey: true,
      unique: true,
    },
    reply: {
      type: DataTypes.TEXT,
      allowNull: false,
    },
    commentId: {
        type: DataTypes.UUID,
        allowNull: false,
      },
  },
  {
    sequelize: instance,
    modelName: "replies",
    tableName: "replies",
    timestamps: true,
    createdAt: true,
    updatedAt: true,
  }
);

What's even more wild is that I had two controllers that performed the same read/write operations for both tables and really wasn't comfortable with how this was designed. Besides the regular controllers for the table, there was a CommentLike model that stores comments liked by users using the commentId and userId column, however this table was only meant for the Comment table. Replies could not be liked, or even replied to because of the rigid design nature I adopted for it months back🤮. The final bit of crazy was where I had two notification models for both tables, CommentNotification and ReplyNotification, each referencing rows in both Comment and Reply table. Yes, this also means writing different controller classes that literally did the same thing, besides a few columns that were distinct🤦

I finally decided to rethink this design approach, and I think what really helped me out here was the way tweets work on twitter. I spent some time using the twitter api for evaluating tweet acitivities, and noticed how tweet response are usually structured. Essentially every comment, or quote made on twitter is a tweet, which means they all have the same common attributes (columns) that describes them. What could probably distinguish a tweet from another is if one tweet is a standalone tweet, or a reply to another tweet, but generally they are all a single entity - A Tweet

Having this in mind, I realized that every reply to a comment is still essentially a comment, so I could actually store all replies within the comments table. But how would I be able to distinguish a standalone comment from a reply to a comment, since querying for all comments related to a particular post would include the standalone comments and replies, which isn't what we want? For this, I created a junction table called CommentReply with two columns commentId, and referenceId like this:

class CommentReply extends Model { }
CommentReply.init(
    {
        commentId: {
            type: DataTypes.UUID,
            allowNull: false,
            primaryKey: true,
            unique: true,
        },
        referenceId: {
            type: DataTypes.UUID,
            allowNull: true,
        },
    },
    {
        sequelize: instance,
        modelName: "comment_replies",
        tableName: "comment_replies",
        timestamps: true,
        createdAt: true,
        updatedAt: true,
    }
);

The commentId column references the comment that is supposed to be a reply, while the referenceId column references the comment being replied to. So, whenever a reply is made to a certain comment, the reply is stored in the database as a comment, and the id of this comment (reply) along, with the id of the comment that's being replied to is stored in a CommentReply.

Now how do I query for comments that are originally standalone comments, not replies. The idea is to query for every comment within the database, and perform a left join with the CommentReply table. A "left join" would include null columns in the query results for comments that do not have references in the commentId column of the CommentReply table. So rows with null commentId column represents original standalone comments, while the non-null columnID rows are replies. So based on this ideology, we can query for standalone comments, or just comments that are replies to a certain comment Here's how I performed the query in the comment controller class:

  async getComments({ postId, limit, offset, userId, commentId }: GetShotParams & { shotId: string, commentId: string | null }) {

    /* if query contains commentId, fetch all comments referenced by that id
    else, fetch comments that do not have a row in the replies. Note that: Standalone
    comment ids can never have a row in the columnId for commentReplies, but references so this works!
    */

    const where: WhereOptions = commentId ? { shotId, '$comment_reply."referenceId"$': commentId } : { postId, '$comment_reply."commentId"$': null }

    const comments = (await Comment.findAll({ where, order: [['createdAt', "DESC"]], limit, offset, include: COMMENT_INCLUDE_OPTIONS }))
    return comments
  }

What makes this even better is that replies also get to have likes, or even nested replies just like "original comments" which wasn't available in the first design. This recursive sequence just keeps going on and on without adding an extra line of code to the controller, making it more flexible than the initial approach.

After implementing this, I was able to migrate every reply from the Reply table to the Comment table, and severe all ties to it😁 Now, I get to delete the reply table, its controllers, and including the notification model that is associated with this table. Damnn that's really a lot of code😵 I think the best part of refactoring code is where you get to delete a number of lines of code that really are just garbage😅

Creating uneven grids with FlexboxLayoutManager on android

EchoEye — Mon, 06 Dec 2021 11:54:34 +0000

I was looking through the DeviantArt android application for features I could implement in my latest project that could be useful to have in the mobile application, and came across this layout format I liked a lot. As you can see in the image below, the images are arranged in a grid-like form, but each image has different sizes based on their aspect ratio.

I initially tried using a workaround with the GridLayoutManager android provides, but that didn't work as expected because this layout wouldn't allow feed items to fill up extra spaces that might be available during positioning.

Turns out the answer was in the FlexboxLayoutManager - A layout manager based off of CSS' flex box. I've used this quite a number of times for basic layout, especially the "wrap" feature, but never had a use case for something specific like DeviantArt's. I set out to implement this layout manager, but of course it didn't come off as easy as I thought it would. The problem I had at first was that I couldn't control the maximum number of columns that should be displayed on a single row before wrapping, so all hundreds of images were arranged on a single row. Crazy right?😅

Anyway I did a bit of research here and there for how to achieve this form of layout in CSS Flexbox since the layout manager is based on this. A few minutes later, I came across this post on stackoverflow about setting the min-width and max-width of each flex item, then allowing the default behavior of these flex items to fill up remaining space with the flex-grow property set to 1. I applied this concept on the FlexboxLayoutManager in android, and I'm glad I was able to finally achieve the same results with DeviantArt😄

Here's how I implemented it on android; since the sizes of the various images to be rendered is based on the aspect ratio, I would return 3 different view-types based on this faactor. The viewTypes are PORTRAIT, LANDSCAPE, and SQUARE. So in the getItemViewType() method of the RecyclerView adapter, this check is performed to determine the view type to be used as here:



override fun getItemViewType(position: Int): Int {
        val item = getItem(position)
        return if (item.width > item.height) {
            LANDSCAPE
        } else if (item.width < item.height) {
            PORTRAIT
        } else {
            SQUARE
        }
    }

Now that this is available, the minimum and maximum possible width and height would be determined in the onCreateViewHolder() and these values would be different based on the view types:



    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): ShotFlexAdapterViewHolder {
val screenWidth = getScreenSize().width

        val view = LayoutInflater.from(parent.context)
            .inflate(R.layout.layout_shot_list_item, parent, false)

        if (viewType == PORTRAIT) {
            val maximumWidth = (0.5 * screenWidth).toInt()
            val minimumWidth = (0.3 * screenWidth).toInt()
            val minimumHeight = (0.5 * screenWidth).toInt()
            val maximumHeight = (0.6 * screenWidth).toInt()

            view.updateViewLayoutParams(minimumWidth, maximumWidth, minimumHeight, maximumHeight)
        } else if (viewType == LANDSCAPE) {
            val maximumWidth = screenWidth.toInt()
            val minimumWidth = (0.55 * screenWidth).toInt()
            val minimumHeight = (0.5 * screenWidth).toInt()
            val maximumHeight = (0.55 * screenWidth).toInt()

            view.updateViewLayoutParams(minimumWidth, maximumWidth, minimumHeight, maximumHeight)
        } else {
            val maximumWidth = (0.7 * screenWidth).toInt()
            val minimumWidth = (0.4 * screenWidth).toInt()
            val minimumHeight = (0.4 * screenWidth).toInt()
            val maximumHeight = (0.7 * screenWidth).toInt()

            view.updateViewLayoutParams(minimumWidth, maximumWidth, minimumHeight, maximumHeight)
        }

        return ShotFlexAdapterViewHolder(view)
    }

Now the extension function that updates the width and height properties:



private fun View.updateViewLayoutParams(
        minimumWidth: Int,
        maximumWidth: Int,
        minimumHeight: Int,
        maximumHeight: Int
    ) {
        (this.layoutParams as FlexboxLayoutManager.LayoutParams).apply {
            flexGrow = 1f
            this.width = minimumWidth
            this.height = minimumHeight
            this.maxWidth = maximumWidth
            this.minWidth = minimumWidth
            this.minHeight = minimumHeight
            this.maxHeight = maximumHeight
        }
    }

Here's an explanation of what is going on above. In order not to overcrop the images that would be displayed, the container width and height holding this image should match the view types i.e portrait images should have a container height greater than the container width, landscape images should have a container width greater than the container height, and square images should have container width and height of equal sizes so that the images to be displayed fits almost* perfectly with the container, and not overcropped.

Now on top the onCreateViewHolder(). For portrait images, the container is assigned a minimum width 30% the screen width, complemented with a minimum height of half of the screen width, which is slightly higher than the minimum width. This would be a particularly useful for scenarios that allows a maximum of 3 portrait images to be rendered on a single row before wrapping. Now imagine we've got a portrait image and a landscape image competing for space on a row. Obviously the landscape image would need more width size than the portrait (say 50% of the screen width), and that means lesser spaces would be left for other images.

For this to work in this case, we can only have a maximum of 1 landscape photo, and the remaining 50% of the screen width would be left to be shared amongst other images. Remember we initially, we defined the minimum width of portrait images to be 30% of the screen width, which means only a maximum of 1 photo can go along with a landscape photo on the same row. The remaining 20% would be shared between these two images since we set the 'flex-grow' property of every item to be 1, i.e stretch to fill the remaining space.

This analogy would also be applied in cases for landscape and square images. The key lies within using the min/max width and height properties to properly configure how much space each item can be allowed to have on a single row based on their aspect ratio, before wrapping subsequent images to the next row. The min width determines the smallest possible width an item can have on a row, while the maximum width determines the maximum possible width an item should have when stretching, regardless of how much space is left on the row. I hope you find this explanation useful. I'm still recovering from the 'eureka' moment I had after I discovered this layout approach😅 and here's what it looks like on the app

Why's managing background tasks in react native so difficult?

EchoEye — Tue, 14 Apr 2020 19:56:48 +0000

Hello React Native developers! So, According to the official react native docs, the only way to implement background tasks is by using HeadlessJS which only works on android. What's confusing is that popular apps like Instagram, Facebook are built with react native and they definitely handle background tasks on both android and iOS devices pretty well. Since this issue seems resolved, is there a reason why their solution hasn't been released as a package for other react native developers to use and integrate seamlessly into their react native applications. After-all, react native is a product of Facebook and I haven't been able to find a perfectly working solution that works really well on both platforms.

Creating an animatable bottom bar with Animated and React Navigation in React Native

EchoEye — Sun, 02 Feb 2020 17:08:01 +0000

This tutorial is essentially to show how you can apply animations to the bottom bar view when you press any of the tab buttons in a react native app. I recently saw a UI design concept illustrating this and with a few tweaks from the docs from react-navigation, I was able to achieve this. Note that you should have prior knowledge of creating basic animations in react native as this is not a tutorial to get started with it. We'll need react-navigation and react-navigation-tabs for this project. The full code can be viewed here

Here's a gif showing what we'll be building:

First we import our necessary files in the App.js file with the following code:



import React, {useState} from 'react'
import {View, Dimensions, Animated} from 'react-native'
import {createBottomTabNavigator, BottomTabBar} from 'react-navigation-tabs'
import {ScreenOne, ScreenTwo, ScreenThree} from './Screens'

Now we create the respective screens for each navigator item. Create a new file and name it Screens.js and input the following



import React from 'react'
import {View, Text, StyleSheet} from 'react-native'
const ScreenOne = () => {
    return(
        <View style={styles.container}>
        <Text>This is the first screeen</Text>
        </View>
    )
}

const ScreenTwo = () =>{
    return(
         <View style={styles.container}>
        <Text>This is the second screeen</Text>
        </View>
    )
}

const ScreenThree = () =>{
    return(
         <View style={styles.container}>
        <Text>This is the third screeen</Text>
        </View>
    )
}

const styles = StyleSheet.create({
    container:{
        flex: 1,
        backgroundColor: '#fff',
        justifyContent: 'center',
        alignItems: 'center'
    }
})
export {ScreenOne, ScreenTwo, ScreenThree}

Back to our App.js, let's map our respective screens to the bottom tab component. It receives two arguement. An object containing the screens, and the configuration for the bottom tab component We continue the code:



const bottomComponent = createBottomTabNavigator({
    Home:{
        screen: ScreenOne,
        navigationOptions:{
        tabBarIcon: ({tintColor}) => <Ionicons name='md-home' color={tintColor} size={24} />
    }
    },
    Notifications:{
        screen: ScreenTwo,
        navigationOptions:{
        tabBarIcon: ({tintColor}) => <Ionicons name='md-notifications' color={tintColor} size={24} />
    }
    },
    Profile:{
        screen: ScreenThree,
        navigationOptions:{
        tabBarIcon: ({tintColor}) => <Ionicons name='md-person' color={tintColor} size={24} />
    }
    }
})

We can customize the look of the bottom bar with the BottomTabBar component imported from createBottomTabNavigator. To do this, we add our we create a configuration object that would be passed to the createBottomTabNavigator. It should look like this:



const config= {
    tabBarOptions:{
    activeTintColor: '#fff',
    inactiveTintColor: 'rgba(0,0,0,0.7)'
  },
  tabBarComponent: (props) => <CustomBottomBar {...props} />
}

Our createBottomTabNavigator should now look like this:



const bottomNavigator = createBottomTabNavigator({
  Home:{
    screen: ScreenOne,
    navigationOptions:{
      tabBarIcon: ({tintColor}) => <Ionicons name='md-home' color={tintColor} size={24} />
    }
  },
  Notifications:{
    screen: ScreenTwo,
    navigationOptions:{
      tabBarIcon: ({tintColor}) => <Ionicons name='md-notifications' color={tintColor} size={24} />
    }
  },
  Profile:{
    screen: ScreenThree,
    navigationOptions:{
      tabBarIcon: ({tintColor}) => <Ionicons name='md-person' color={tintColor} size={24} />
    }
  }
}, config)

The important property here is the tabBarComponent. This accepts a component to act as the default bottom tab bar. We named this CustomBottomBar. It also has props that should be passed down to it so that the custom view object still behaves like the default tab bar. React navigation gives us access to the BottomTabBar component so we can configure such component into how we want this to look instead of using the default look and feel of the bottom component.

Now, let's go on to creating the CustomBottomBar component. Still in the same App.js, do the following:



const CustomBottomBar = (props) =>{
    //We use the spread operator to pass down all default properties of a bottom bar
    return(
        <View>
        <BottomBar {...props} style={{backgroundColor: 'tranparent'}}>
        </View>
    )
}

Note that the background color of the BottomBar should be set to transparent so that it doesn't overshadow the custom indicator.
To avoid complexity, we won't be adding any further styling to the bottom bar. You'll notice we wrapped a view around the BottomBar component. This is so that we can add a custom indicator of our choice to it. Since our aim is to create that movable colored view in the image above, we add a new component to the CustomBottomBar. The code should now look like this:



const CustomBottomBar = (props) =>{
    //We use the spread operator to pass down all default properties of a bottom bar

    //custom styles for our indicator
    //The width of the indicator should be of equal size with each tab button. We have 3 tab buttons therefore, the width of a single tab button would be the total width Dimension of the screen divided by 3

    const {width} = Dimensions.get('screen')
    const animStyles = {
        position: 'absolute',
        top: 0,
        left: 0,
        bottom:0,
        width: width/3,
        backgroundColor: 'rebeccapurple'
    }
    return(
        <View>
        <Animated.View style={animStyles} />
        <BottomTabBar {...props} style={{backgroundColor: 'tranparent'}} />
        </View>
    )
}

This is how the app should look.

Now, we animate it. The indicator is required to move to the very position of the tab button pressed. The BottomTab component receives an onTabPress prop which is a method and this returns the route name of the tab pressed. This method executes an action everytime a tab button is pressed. We'll use this action to properly animate the indicator to the specific location. Still in the CustomBottomBar component, we modify it as:



const CustomBottomBar = (props) =>{
    //We use the spread operator to pass down all default properties of a bottom bar

    //custom styles for our indicator
    //The width of the indicator should be of equal size with each tab button. We have 3 tab buttons therefore, the width of a single tab button would be the total width Dimension of the screen divided by 3

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

    //Create an animated value 
    const [position] = useState(new Animated.ValueXY())

    //We attach the x,y coordinates of the position to the transform property of the indicator so we can freely animate it to any position of our choice.
    const animStyles = {
        position: 'absolute',
        top: 0,
        left: 0,
        bottom:0,
        width: width/3,
        backgroundColor: 'rebeccapurple',
        transform: position.getTranslateTransform()
    }
    return(
        <View>
        <Animated.View style={animStyles} />
        <BottomTabBar {...props} style={{backgroundColor: 'tranparent'}} />
        </View>
    )
}

With everything set, we can now animate our position to where we want it. We create a method called animate, This method would be passed to the onTabPress prop of the BottomBar component. So we should have our code like this:



const CustomBottomBar = (props) =>{
    //We use the spread operator to pass down all default properties of a bottom bar

    //custom styles for our indicator
    //The width of the indicator should be of equal size with each tab button. We have 3 tab buttons therefore, the width of a single tab button would be the total width Dimension of the screen divided by 3

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

    //Create an animated value 
    const [position] = useState(new Animated.ValueXY())

    //We attach the x,y coordinates of the position to the transform property of the indicator so we can freely animate it to any position of our choice.
    const animStyles = {
        position: 'absolute',
        top: 0,
        left: 0,
        bottom:0,
        width: width/3,
        backgroundColor: 'rebeccapurple',
        transform: position.getTranslateTransform()
    }

    const animate = (value, route) =>{
        //navigate to the selected route on click
        props.navigation.navigate(route)

        //animate indicator
        Animated.timing(position, {
            toValue: {x: value, y: 0},
            duration: 300,
            useNativeDriver: true
        }).start()
    }

    return(
        <View>
        <Animated.View style={animStyles} />
        <BottomTabBar {...props} onTabPress={({route}) =>{
            switch(route.key){
                case 'Home':
                //animated position should be 0
                     animate(0, route.key)
                     break
                     case 'Notifications':
                     //animated position is width/3
                      animate(width/3 , route.key)
                      break
                      case 'Profile':
                      //animated position is width of screen minus width of single tab button
                       animate(width - (width/3), route.key)
                       break
            }
        }} style={{backgroundColor: 'transparent'}} />
        </View>
    )
}

And that's it. We have successfully animated our indicator for the bottom bar to focus on the actively selected screen of the bottom bar. Here is the full. We just had to modify the BottomTabBar component imported from react-navigation-tabs as we would do for a normal react component. Nothing much here!