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

Set the user's registration year to the earliest year available in the calendar #1611

Open
wants to merge 1 commit into
base: stable
Choose a base branch
from

Conversation

MMDJafari
Copy link
Contributor

No description provided.

@n1313
Copy link
Contributor

n1313 commented May 5, 2023

This is not the right way. For example, I am registered on May 2015 when freefeed.net was launched, but my oldest posts are from 2009 (because I imported my archive with posts from friendfeed.com).

@MMDJafari
Copy link
Contributor Author

This is not the right way. For example, I am registered on May 2015 when freefeed.net was launched, but my oldest posts are from 2009 (because I imported my archive with posts from friendfeed.com).

Oh, you are right. I completely forgot about the tool for importing the archive from Friendfeed. I think we should set the first post date to it. What do you think?

@n1313
Copy link
Contributor

n1313 commented May 5, 2023

It's doable, but to be honest I don't see the value of doing so. There is no simple way of finding out what the date of the first post of a user is, so you'd need to do a bit of work on the backend to make that work first, and then pass this data to the frontend, and then use it here. I do not think that the problem is worth the fix.

@davidmz
Copy link
Member

davidmz commented May 5, 2023

We already have the seeds for this in the API, when we show posts by day. When shown by year, we could return the previous and next non-empty years. If there is no such previous year, then the posts have run out.

@MMDJafari
Copy link
Contributor Author

MMDJafari commented May 5, 2023

It's doable, but to be honest I don't see the value of doing so. There is no simple way of finding out what the date of the first post of a user is, so you'd need to do a bit of work on the backend to make that work first, and then pass this data to the frontend, and then use it here. I do not think that the problem is worth the fix.

Just for a better user experience. I thought that the first post data had been registered somewhere in the database, so we could fetch it directly without fetching all feeds. However, if this is not the case, then it's not worth doing.

Since I haven't imported anything from elsewhere to FreeFeed, I don't have a clear view on this situation. But I did see some flags in the state called archiveActivityForm, archivePost, and archiveRestorationForm. Are these related to importing archives? If yes, then we can set the minimum year to 2000 if the user has imported archives. If the user hasn't done that, we can set it to the registration year.
Screenshot 1402-02-15 at 21 56 46

@MMDJafari
Copy link
Contributor Author

We already have the seeds for this in the API, when we show posts by day. When shown by year, we could return the previous and next non-empty years. If there is no such previous year, then the posts have run out.

Honestly, I'm having trouble understanding your statement. Could you please clarify? What I observed is that the calendar allows me to go back to the year 2000, but my first post on this account is from 2021. It doesn't seem to make much sense to have the ability to view previous years with no data in them.

@n1313
Copy link
Contributor

n1313 commented May 6, 2023

@MMDJafari what @davidmz is talking about is taking the "next/previous day/month with posts" functionality that we already use on day/month views on calendar page, and putting it to use on year view as well. Right now we simply show all possible years and users can navigate between them even if they have no posts, and instead we could change this to navigating only between non-empty years.

Screenshot 2023-05-06 at 11 46 03

However, I think I don't like skipping empty years, so if I had posts only in 2020 and in 2022 then I would like to be able to click "← 2021" from 2022 and see an empty 2021, then click "← 2020" again and see 2020 with posts. But I agree that letting users navigate past that is not useful.

@MMDJafari
Copy link
Contributor Author

MMDJafari commented May 7, 2023

@MMDJafari what @davidmz is talking about is taking the "next/previous day/month with posts" functionality that we already use on day/month views on calendar page, and putting it to use on year view as well. Right now we simply show all possible years and users can navigate between them even if they have no posts, and instead we could change this to navigating only between non-empty years.

Now I understand what he meant. Thankful.
By blank dates, I meant the year view.

However, I think I don't like skipping empty years, so if I had posts only in 2020 and in 2022 then I would like to be able to click "← 2021" from 2022 and see an empty 2021, then click "← 2020" again and see 2020 with posts. But I agree that letting users navigate past that is not useful.

In this case, I don't want to skip 2021 either, but showing the years before 2020 is not very logical.
Generally, there are two scenarios:

  1. The date of the user's first post is equal to or greater than the date of their registration.
  2. The user imported their archive from Friendfeed, and the date of their post is unknown.
    If it is scenario 1, we can set the minimum year to their registration date. If it is scenario 2, we can set the minimum year to 2000, for example.

To recognize scenario 2, we can use a flag if it exists. As I mentioned earlier, I observed some elements in the state. Since I didn't import anything, I can't test them. Could you please log the state in your console and send me a screenshot like the one I posted before? Here's the link to my previous post for reference: #1611 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants