Lifecycle hooks, threading and notification system in the user story system in GSOC'20

sharmaaditya570191
Published: 08/03/2020

A whole new set of awesome features are here for our beloved users. Do not get worried by the heavy terms in the title. Sit back, relax and follow me to catch a glimpse of my implementation for giving you the best possible user experience. You will soon be able to write your own story, share with us how you use our products, relate to other users’ stories, vote them up and we’ll make sure we deliver cohesive solutions to you.

What did I do this week?

This week it was time to design a personalized notification system for our users to notify them about the latest features when we launch them. Only author and followers(users who have voted) of the launched story should receive the notification so that we do not disturb other users who might be busy writing their own amazing stories.

The admins update the status of a user story to “launched” via the back end Strapi panel when our team have successfully pushed a new feature to production.

Now Strapi lifecycle hooks come into action. The lifecycle hooks are functions that get triggered when the Strapi queries are called. They will get triggered automatically when we manage our content in the Admin Panel or when we develop custom code using queries.

I wrote a asynchronous afterUpdate hook in the user story model which checks if the status of a user story has changed to “Launched” after being updated. If the status has changed then it creates a new notification record on the server with a custom message, seen status, link to the story page and a list of users to whom the notification is to be shown. I did this by utilizing Strapi services which are a set of reusable functions. They are particularly useful to respect the DRY (don’t repeat yourself) programming concept and to simplify controllers logic. Every notification on the server is required to have a different and unique message.

On the client side I fetch the notifications for the particular authenticated user using GraphQL queries. When the user has seen the notifications then they are marked as seen on our Strapi server too. This is done using GraphQL mutations which update the status of a notification. I made sure that we do not hit our API multiple times to update the status of a notification. 

The next major feature of the week was to add threading in comments. This allows users to reply to a particular comment on a story in a thread. I created a separate model on the server for user story comment replies. Each comment reply belongs to one comment, a user can have multiple comment replies, each reply belongs to one user and one comment can have multiple replies. Such was the complexity of relations between the models schema. You can also see the number of replies and even add your own reply via the client side. 

All these extra efforts will make your user experience super smooth. The blazing fast React re-renders and updates on the client side will be a icing on my cake. :P

What is coming up next?

I will spend some time to polish and test the existing features.

I will also work on the user story privacy policy to allow admins to manage and update the policies from the admin panel. Users should receive notifications whenever the privacy policies are updated. The user can then choose to accept them or remove their account.

Did I get stuck anywhere?

I got stuck at multiple places be it writing hooks and custom controllers in Koa for my server or implementing mutations in an effective and optimized way on the client side.

However, I did not give up and kept reading more about the topics and technologies involved. This way I was able to learn a lot of new things during the week. Debugging and troubleshooting became super easy after I hit my learning goals and covered all basic concepts properly.

This ended the week with the second evaluation. I received a really nice feedback from my mentors. I expressed my sincere thanks to them today for always supporting, motivating and inspiring me to learn more.

DJDT

Versions

Time

Settings from gsoc.settings

Headers

Request

SQL queries from 1 connection

Static files (2312 found, 3 used)

Templates (11 rendered)

Cache calls from 1 backend

Signals

Log messages