feat: favorite categories segmentation logic

[dkoo]

All Submissions:

• Have you followed the Newspack Contributing guideline?
• Does your code follow the WordPress' coding standards and VIP Go coding standards?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes proposed in this Pull Request:

Proposes logic for segmenting by favorite category. Picking up a thread from #1155 (comment). Note that I was slightly incorrect in my description of the logic in that thread; I missed the key() function in the current logic which means that the criteria categories are only compared against the top-most-viewed category.

The way the current (non-rearchitected) logic works is that a category is considered "favorite" if it's been viewed more times than any other category. This could result in a slightly awkward situation where if the very first post visited matches the segment criteria, it would make for a match on that very first pageview.

The proposed logic is almost the same, but tweaks it so that a category isn't considered favorite unless the reader has viewed at least two different articles, either in the same category or different categories. If the reader has viewed multiple articles in different categories, the top category must actually have more views than the other categories in order to be considered a favorite. This prevents the criteria from matching if, for example, the reader only views a single article in several different categories (in which case none can be considered a favorite).

How to test the changes in this Pull Request:

1. Create a segment at top priority and assign several categories to the "Favorite categories" criteria.
2. On the front-end, view some articles that don't match any of the categories in the segment. Confirm that you don't match the segment.
3. In the same session, view multiple articles in one of the segment's categories (more than you viewed in step 2). Confirm that you do match the segment now that you've viewed more articles in at least one of the segment's categories than any other category you've viewed.
4. In a new session, view at least two articles in any of the segment's categories. Confirm that you match the segment after viewing at least two articles in one of the segment's categories. This is so that readers who only ever view articles from a single category can still match the segment.

Other information:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes, as applicable?
• Have you successfully ran tests with your changes locally?

[miguelpeixe]

It's working as described!

Non-blocking NIT, I think the same logic could be applied with a simpler statement:

views.length > 1 && countsArray[ 0 ][ 1 ] > countsArray[ 1 ][ 1 ]

I also came across an issue that I'm not sure we should handle. I have a "Featured" category in my local instance that is always on top during my tests because it's prioritized on the homepage. It's always assigned with other categories that are actual topics, but my "favorite category" doesn't work as "favorite topic" when using categories in this way.

[miguelpeixe]

Whoops! Ran into an issue on a fresh session. It's trying to access the index of a countsArray item when countsArray is empty:

Uncaught TypeError: Cannot read properties of undefined (reading '1')
    at Object.eval [as matchingFunction] (favorite-categories.js:27:92)

[dkoo]

845a854 should simplify the logic as suggested, as well as fix the case where the countsArray var is undefined.

I have a "Featured" category in my local instance that is always on top during my tests because it's prioritized on the homepage. It's always assigned with other categories that are actual topics, but my "favorite category" doesn't work as "favorite topic" when using categories in this way.

Can you describe how to set up categories in this way? And what does your segment's configuration look like? How can I replicate the issue?

[miguelpeixe]

Can you describe how to set up categories in this way? And what does your segment's configuration look like? How can I replicate the issue?

It's how our bootstrap content is set up. We have a category named "Featured" that has demo posts attached to it:

While navigating to do my local tests, the "Featured" category was ranked at the top. It's not a "topic", so it defeats the purpose of the "favorite categories" segmentation. My favorite category can't be "featured".

I don't think there's a way around this. Anytime a publisher uses a category for other reason that is not a topic in combination with categories that are topics, there's a risk to not have the feature working as expected. Non-topic categories at the top.

[miguelpeixe]

Just realized that my suggestion can also fail if the reader has only visited a single category in multiple views. It'll try to get an index of undefined countsArray[1]

This should work:

1 < views.length && ( ! countsArray[ 1 ] || countsArray[ 0 ][ 1 ] > countsArray[ 1 ][ 1 ] )

Or, to save a little processing power, the views.length can move up to line 4 and return early so no unnecessary category calculation logic is executed and this check can be just ! countsArray[ 1 ] || countsArray[ 0 ][ 1 ] > countsArray[ 1 ][ 1 ]

[dkoo]

Ah, so it's more about how different publishers might use categories for things other than topics, then? I think that's something we can't really control for. IMO as long as the feature works consistently for any category term, it's up to the publisher to create segments that make sense for their readership.

[dkoo]

Ah, just saw your last comment. Will test your latest suggestion!

[dkoo]

How's 855d094?

EDIT: plus f5d14ff, whoops

[miguelpeixe]

Working as described! 🙌

[dkoo]

Thanks, Miguel!