Curating Posts

Posts are looking pretty snazzy now, but we still don’t have a way of easily finding posts a user might want to see. Discoverability of new content is integral to social media platforms, so we should really add this.

The first discoverability feature we’ll address is tags. We implemented the Markdown for tags earlier—now let’s add the queries and page to browse posts by tag.

Tags

We’re going to use a PostgreSQL regex condition on our query, but we don’t want to require knowledge of PostgreSQL specifics in our guestbook.messages namespace. So we’ll use Clojure expressions in HugSQL to generate our regex inside our query.

First, let’s create a namespace guestbook.db.util and write a helper function there:

Note that it’s sanitizing our input. This is important when using Clojure expressions to inject generated strings because HugSQL has no way of knowing which parts of our returned SQL are meant to be escaped.

Now let’s write a simple query using this helper function:

To use our helper function, we need to require the new guestbook.db.util namespace from guestbook.db.core.

Great, now let’s try it out from the REPL:

Perfect, we’re getting tagged posts correctly! Let’s add a wrapper function and a service API endpoint to get our posts by tag:

Then let’s test it out in Swagger:

Looks good. Now let’s write our tag page based on our author page:

We have the same core component as the author page but without the author-specific pieces. Let’s write the supporting code for this page and then connect it to our routes.

Our :messages/load-by-tag is similar to our :messages/load-by-author; we’ve just changed two things. We’ve switched the :url in the :ajax/get effect to the one we just created, and we’ve changed the :messages/filter map to filter messages with a regular expression.

Let’s try it out by clicking one of our tag links:

Great! Now we can view all posts with a specific tag.

We have the ability to view posts for a single tag and a single author. Next, let’s add the ability for users to subscribe to authors or tags.

Personalized Feed

One of the core features of most social media is a personal curated feed, with posts relevant to them. Let’s add the ability for users to subscribe/unsubscribe to users and/or tags and view a personalized feed based on their subscriptions.

First, let’s write a query that takes a vector of users and a vector of tags and returns a feed.

We need to write another helper function similar to tag-regex that takes a vector of tags instead of just one.

Now we’re able to get a feed based on a map of :follows and :tags, and we can leave one or the other empty.

Next, we need to get this subscriptions map from somewhere. Let’s add subscriptions to a user’s :profile JSONB. We’ll reuse our /api/my-account/set-profile endpoint, so we just need to add some utilities for working with the :subscriptions field on the :profile map.

Create a new ClojureScript namespace called guestbook.subscriptions and add a subscribe-button component:

Our :subscription/set event is the core of our logic. Unlike our profile page where we have a bunch of local changes, we’re doing a single change at a time. The subs-type parameter specifies whether we’re working with a tag or a user, sub is the value itself, and subscribe? is whether we’re adding or removing the subscription. Based on these parameters, we modify the profile we have and immediately send it to set-profile, and set a ::loading? flag to ensure that we don’t send conflicting updates simultaneously. The rest of the namespace is fairly straightforward.

Now let’s include the subscribe-button in our tag page and our author page:

Great! We have the ability to manage subscriptions for our feed.

Now we just need to add a page to render it. Let’s start with a new namespace called guestbook.views.feed:

This is similar to our other message-list-based pages, but we have the added concern that the feed is dependent on the current user’s session rather than parameters. To manage this, we’ve expanded the scope of our :auth/user-state case statement, and we’ve added an :identity function to our controller that changes with every reload. This ensures that we never get stuck with an old list of messages.

Before this page will work, we need to connect a service endpoint to the query we wrote earlier, and we need to write the :messages/load-feed event to call it.

Let’s start with our endpoint:

Note that we require an identity to be present on the request map, so we should add a new auth entry as well:

Now let’s write our re-frame event:

Notice that we have to update our :message/filter logic to account for multiple ways of matching. We’ve simply allowed for a vector of maps in place of a single map. This allows us to accomodate the feed filter without having to change our older, simpler filters.

Finally, let’s add our feed page to our routes and our navbar:

Let’s try it out.

Great! We have a personalized feed. Aside from enriching some features and tweaking style, we have a fully functional and feature-complete social media application! Congratulations!