Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes Issue #462 Integrate inactive blog url and include logic to filter inactive feeds #520

Closed
wants to merge 6 commits into from

Conversation

c3ho
Copy link
Contributor

@c3ho c3ho commented Dec 16, 2019

Issue This PR Addresses

#462

Type of Change

  • Bugfix: Change which fixes an issue
  • New Feature: Change which adds functionality
  • Documentation Update: Change which improves documentation
  • UI: Change which improves UI

Description

There is no logic for handling inactive feeds in storage.js. I added a few functions that allows for active feeds to be moved to inactive feeds, get all inactive feeds and get count of all inactive feeds. There is one function that should be debated which is getInactiveFeed.

Still a WIP but would like some feedback on current changes before continuing

Checklist

  • Quality: This PR builds and passes our npm test and works locally
  • Tests: This PR includes thorough tests or an explanation of why it does not
  • Screenshots: This PR includes screenshots or GIFs of the changes made or an explanation of why it does not (if applicable)
  • Documentation: This PR includes updated/added documentation to user exposed functionality or configuration variables are added/changed or an explanation of why it does not(if applicable)

@c3ho c3ho changed the title Issue 462 Fixes Issue #462 Integrate inactive blog url and include logic to filter inactive feeds Dec 16, 2019
@c3ho
Copy link
Contributor Author

c3ho commented Dec 16, 2019

I opted to use SMOVE to move members from one set to another instead of doing an SINT(set intersection).

Copy link
Member

@manekenpix manekenpix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, just one comment

Comment on lines 98 to 102
* Gets an array of guids from redis
* @param from lower index
* @param to higher index, it needs -1 because redis includes the element at this index in the returned array
* @return Array of guids
*/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you need this comment here? You're not passing anything to 'getInactiveFeeds` so I don't know what that comment is for.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hahaha, you're right. I had fixed this in a new commit but didn't push it to origin. I just wanted some thought on it.

@manekenpix manekenpix added area: back-end area: redis Redis Database related type: enhancement New feature or request labels Dec 17, 2019
Copy link
Contributor

@humphd humphd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels like it's duplicating code. Could we not refactor things so that we pass FEEDS vs. INACTIVE_FEEDS to some private functions that actually do the shuffling of keys between sets?

This PR makes me want to think harder about our data and how we're structuring it, but I should probably leave that for later. I suspect we need to make some changes soon.

@c3ho
Copy link
Contributor Author

c3ho commented Dec 17, 2019

I had to double the code unfortunately, because we can't SMOVE if there is no destination.

@c3ho
Copy link
Contributor Author

c3ho commented Dec 17, 2019

This feels like it's duplicating code. Could we not refactor things so that we pass FEEDS vs. INACTIVE_FEEDS to some private functions that actually do the shuffling of keys between sets?

This PR makes me want to think harder about our data and how we're structuring it, but I should probably leave that for later. I suspect we need to make some changes soon.

Oh wait I see what you mean. I can probably do that

@humphd
Copy link
Contributor

humphd commented Dec 17, 2019

So I wonder if what we really need to do, is create a class for Feed like we have now for Post, and let it manage some of this state.

const feed = new Feed(url, name, ...);
await feed.save(); // now in Redis, and part of FEEDS set
...
const feed = await Feed.byUrl('https://.....'); // get feed from Redis 
feed.inactive = true; // indicate that we want this to go into INACTIVE_FEEDS when we save
feed.save(); // saved, and the "inactive" flag is used to move it into the right set

I'm just thinking out loud, but your code at this level could support that one level above.

@c3ho
Copy link
Contributor Author

c3ho commented Dec 17, 2019

@humphd do you want get these changes through first and then file a separate issue to refactor, although it is a WIP there is still another issue that depends on this one. I'll be happy to refactor it and move all of it to its own class after.

I'll work on this now actually as part of this fix.

constructor(url, name) {
this.url = url;
this.name = name;
this.inactive = false;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should include this in the actual data. Let's have it be something that gets exposed based on which set it's in. When we read from the db, we'll figure that out.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so in this case we just want the this.inactive as the only property?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's going to have to be an async getter/setter, since it requires a database operation vs. storing something on this. We don't need an actual property, just a way to get at the database.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it, don't we have a problem here then? If we're trying to retrieve from the database, should active/inactive be kept track of in the DB as well?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My thought here is that the state we're going to store won't be on the Object, but rather, in which of the two sets this hash object lives in Redis. A feed is either in the feeds or inactive-feeds set, but not both. So we can use that as a state we read from the database, and expose as a boolean via the JS API.

What about:

const isActive = await feed.isActive(); // checks if this feed is in feeds set
await feed.inactive(); // set this feed inactive (move to inactive feeds)
await feed.active(); // set this feed active (move to feeds)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess what I'm confused about is I have code like this now

async inactive() {
  const isActive = await this.isActive();
  await this.save();
}

I won't be passing isActive to save(). So now my addFeed(feed) function which is called when save() is called can't differentiate between whether it should add it to FEEDS or INACTIVE_FEEDS. The only workaround I can think about this is to separate the addFeed function into a addActiveFeed(feed) and addInactiveFeed(feed).

src/backend/feed.js Show resolved Hide resolved
* Marks the feed as inactive
*/
inactive() {
this.inactive = true;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of storing state for this, put it in the appropriate set.

How we we re-activate a feed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

on it, added an active() function that will do the opposite and adjusted the storage.js addFeed to handle it as well

* @return feedId
*/
addFeed: async feed => {
if (feed.feedId && (await redis.exists(INACTIVE_FEEDS)) === 1) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These add* functions are doing two things, and should be split. First, you're dealing with creating a hash to store the feed data. That makes sense, and should stay here. Then, you're putting the id into a set, and that can get moved out to separate functions.

Also, you probably want to use sismember vs. exists.

Copy link
Contributor Author

@c3ho c3ho Dec 18, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, I think I was trying to do too much with this function.

Would addFeed even be an appropriate name for this function, since we're not technically adding the feed anywhere?

* @param feed Feed Object
*/
addInactiveFeed: async feed => {
if ((await redis.exists(INACTIVE_FEEDS)) === 1) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code is identical to what you do above. The only difference is that one uses FEEDS where the other uses INACTIVE_FEEDS. As such, you can refactor this to use 2 arguments passed to a function, and then only do this code once, but call it from two helper functions that deal with the order of these args.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I slowly realized this... and have something working in storage.js as with feedSet as a param for the set to send it to

addFeed: async (feed, feedSet){

}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whoops please disregard this as I replied to this before the previous one.


getInactiveFeedsCount: () => redis.scard(INACTIVE_FEEDS),

getFeedStatus: feedId => redis.sismember(FEEDS, feedId),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't well named. isFeedActive maybe?

Copy link
Contributor

@humphd humphd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did another look over this. I'm having trouble figuring out what API to recommend, and with names. I wonder if part of the problem is that we have no tests, no callers for Feed. If we added that, it might become more clear as we try and use it.

Also, I'm going to vanish into holidays for a while, so I may not get back to this til after the break.

*/
async save() {
this.feedId = await storage.addFeed(this);
await storage.storeFeed(this.feedId);
}

/**
* Checks if feed is part active feeds list. If it is, will move feed from active FEEDS set to INACTIVE_FEEDS set
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

part of active feeds list

}

/**
* Checks if feed is part active feeds list. If it is, will move feed from active FEEDS set to INACTIVE_FEEDS set
* else will move ffeed from INACTIVE_FEEDS to FEEDS
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/ffeed/feed/

*/
async inactive() {
const isActive = await this.isActive(this);
async move() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this is really toggleStatus vs. move right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you'd be better off having 2 functions for this vs. one. Let the caller mange deciding which one to use.

* @param feedId unique ID of feed to be stored
* @param destination set feed is being added into
*/
storeFeed: async (feedId, destination) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about this name, but also don't know what to suggest. Need to think on it.

@c3ho
Copy link
Contributor Author

c3ho commented Dec 18, 2019

Thank you for the review, I'll write some tests and make the requested changes. Happy holidays!

@c3ho
Copy link
Contributor Author

c3ho commented Jan 13, 2020

Will move this PR to 0.6

@humphd
Copy link
Contributor

humphd commented Jan 23, 2020

My work in #592 will help with this, I think. It will also require rebasing.

@c3ho
Copy link
Contributor Author

c3ho commented Jan 23, 2020

@humphd thanks! Will review that asap

@c3ho
Copy link
Contributor Author

c3ho commented Jan 27, 2020

Code has changed a lot since this PR was submitted, will close and submit a new PR when ready.

@c3ho c3ho closed this Jan 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: back-end area: redis Redis Database related type: enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants