Issue 496/add recent activity page

[paskal98]

Added activity page with infinity scroll list

Closes #496

[wbazant]

Okay, this is still a draft PR because I can see comments in the Cyrillic alphabet ;) but I had a rough read through!

I like that all the main pieces of the solution seem to be there, and that you were able to use the API to get the required data. What was the reason to fetch locations by ID? We should not need to do two API calls for something that can be a database join and, if it's just one or two fields that are missing it's much better if we add it to the API payload - you can open a ticket in https://github.com/falling-fruit/falling-fruit-api and stub out the data for now. Either Ethan will add it, or I'll be able to have a go myself.

Instead of changing state.list and state.location (which hold data needed the list page and location page respectively), it's going to be much better for maintainability if you define a new slice, state.activity, and keep the state there: it will look like

const { changes, isLoading, offset } = useSelector(state.activity)

in the component. The async / promise chaining code should also go there, and ideally your component will mostly be rendering and doing UI code.

We would also benefit if the organization of the changes follows a few other conventions in the code base:

• the effect of first changes being loaded after the initial URL load goes in the src/components/connect folder, see src/components/connect/ConnectTypes.js
• styles go in the same module as the component being styled
• utils go in src/utils

Can you have a look at existing usages of state.type.typesAccess and compare to how you've used it currently? It's a class, with methods for accessing the data, so the rest of the code base shouldn't need to access state.type.typesAccess.localizedTypes.

[wbazant]

Marking the PR as not ready yet - see comments on the issue and in the PR

[wbazant]

Also, this encouraged me to go with an infinite list for #525 ! I had a thought @paskal98 , you could have a look at the code organization for the list module, I think with what the students originally did + how I changed it, it makes a lot of sense. The redux module offers "start/extend" reducers to show the start and end, there's a ListPage file which handles loading / unavailable scenarios, and Locations which is responsible for the display.

There actually isn't a 'src/components/connect' module for the list because there's an obvious place to put the effect in - the list page - whereas for e.g. the localized types there isn't, so my ConnectTypes example wasn't that good.

Also, if you have any suggestions for me on the list changes, I'll appreciate them - feel free to add yourself as a reviewer on my PR.

[paskal98]

I have already make chnages regarding to review

• The subheading was fixed, now it has less text.
• Aggregation was implemented.
• Headings were changed to the dd-mm-yyyy format.
• Changes were made to the position of the activity link in the settings menu for the mobile version.
• Additionally, there were changes with the API request, now it's a single request

To implement filtering by dates or months, I would extend the current endpoint with additional parameters will be good solution
GET 'https://fallingfruit.org/api/0.3/locations/changes?limit=100&offset=0&range=false&startDate=dd-mm-yyyy&endDate=dd-mm-yyyy'

startDate=dd-mm-yyyy&endDate=dd-mm-yyyy

This can greatly help with loading and optimizing infinite scrolling

At the moment, the infinite scrolling remains the same as before, loading data when scrolling to the very bottom. Currently, I am also exploring ways to improve and optimize the rendering

Thnak you very much for you feedback and review ! ❤️

[wbazant]

Nice! I checked out the newest branch you pushed -d619c41 which still has "activity" in its own section on mobile so you have probably have something newer locally.

First comment, something strange happens to location links:

[Clementine x7, Grapefruit, orange, Orange, Olive, Mango](http://localhost:3000/locations/1996388), added in Tel Mond, Center District, Israel — Itai

The intention to group by type and user is great, but the links need to be correct. Maybe in the case of multiple locations the line should say "{number of locations} locations" and end with a chevron right, that on click unfolds to e.g.

• Clementine
• Clementine, Grapefruit
  ...

I also spotted this one, it is not correct:
25-10-2024
Black elderberry x2, Jelly ear fungus x2, edited in Glasgow City, Scotland, United Kingdom — Wojtek

because I've edited one location twice.

The scrollbar jumps when the list gets extended, and there's no visual cue that more element will happen. Try add a skeleton entry - header and a few lines of grey bars, see Skeleton in the code and its uses - and extend the list day by day, even if it is fetched in larger chunks?

[wbazant]

Also, a code suggestion, if you're making transformations on the API payload and they are getting quite complex, you can dedicate a module in src/utils to just that, and use Typescript. Define a data structure that is easy to display, and have the type checker help you with functions that convert the API data structure into one you need. I did something like that in src/utils/localizedTypes.ts .

[ezwelty]

@paskal98 I finally had a chance to take a look at the exciting developments in this thread! A few thoughts:

• I'd like to deviate from what @wbazant said and discourage you from lumping multiple locations together. I believe each element should be for one location. This will allow us more flexibility to further refine this view in the future: for example, to display types by common and scientific name as done now in the list (Show multiple types in list view #525), to include photo thumbnails, etc. Merging is something worth exploring, but should be limited to same user, location, and day. There is then no need for "x2" or similar.
• ##-##-yyyy is a very ambiguous date format, as it can mean month-day to some and day-month to others. Better would be yyyy-mm-dd, but instead I would suggest to just use "x days ago" throughout. This is a phrase we already have translated and might actually be more user friendly, since I don't expect many people to scroll down further than a few weeks.
• Use /changes instead of /activity for now to match the current website (https://fallingfruit.org/changes)
• Use "Recent changes" instead of "Recent Activity" to match the current website (that allows us to directly reuse existing translations)
• Please drop the trailing comma after the types (e.g. "Feijoa, added in Los Angeles, California, United States")
• Please drop the trailing dash if author is null (e.g. "... —")
• Don't limit the length of the types list (e.g. "Blackberry, Viburnum x2, European linden, Canadian serviceberry x2, Grape, Chinese crabapple, Silk tree, ..., added in Deidesheim, Rheinland-Pfalz, Germany — The REED Center")

Otherwise, I think it looks great and I'm looking forward to merging!

[paskal98]

Hi, i added new updates

• Changed date format to "x days ago"

• Removed the comma after object types

• Removed the dash if there is no author

• Ensured proper grouping of objects (no aggregation with multipliers; each object with a unique location ID has its own link. No duplicates for edited objects. Aggregation only occurs when it’s the same author, location, and day)

• Added visual loading indicators for new items

• Updated the section title

• Changed the URL path

• Optimized performance for list expansion (added debounce for API calls with a 300ms delay and limited the number of DOM elements rendered to 500 for infinite scroll. For full optimization, I would like to allocate a separate issue as this requires more time and discussion)

[wbazant]

Awesome, this looks really good! Thanks again for working on this. Being able to scroll down and see what people added is really fun.

🐛 After scrolling down and then up, I end up at this view:

I think removing locations from the top of the list to manage the DOM size is a really reasonable idea, but something should be in place to handle scrolling back to the top. Can we maybe put in another skeleton with an intersection observer, whose action will be to shift the list upwards?

🐛 Comparing the list to https://fallingfruit.org/changes reveals some missing content - looks like you're accidentally skipping locations that don't have a user or an address.

🦋 I like separating different locations with a black comma. If a user adds or edits a location with multiple types, for example this one I changed a week ago:

[Black elderberry](http://localhost:3000/locations/1989825), [Jelly ear fungus](http://localhost:3000/locations/1989825) edited in Glasgow City, Scotland, United Kingdom — Wojtek

could we show it as one link - with the comma also blue, and underlining together on hover?

🦋 I like the typography and the fact that the site reads well on both desktop and mobile, in a variety of screen sizes

🦋 I like the skeleton that extends the list and communicates that something is loading! The initial skeleton could be bigger to cover most of the screen - say three sections with five to seven days each - while the little skeleton at the end is great. That's a really minor change so only do it if it sounds inspiring

[paskal98]

Thank you very much for your feedback!

Regarding to : 🐛 Comparing the list...

When comparing data returned from the API ( Swagger) with the data rendered on the main site, inconsistencies are evident. The data in the API response and the data displayed on the site do not match, suggesting a potential server-side issue.

For example data from swagger:

[...
,
{
    "created_at": "2024-11-01T17:11:56.904Z",
    "description": "added",
    "location_id": 1996461,
    "review_id": null,
    "type_ids": [
      111
    ],
    "user_id": 65250,
    "author": "Max Mender",
    "city": "Northampton",
    "state": "Massachusetts",
    "country": "United States"
  },

{
   "created_at": "2024-11-01T17:11:31.056Z",
   "description": "added",
   "location_id": 1996460,
   "review_id": null,
   "type_ids": [
     111
   ],
   "user_id": 65250,
   "author": "Max Mender",
   "city": "Northampton",
   "state": "Massachusetts",
   "country": "United States"
 },

{
   "created_at": "2024-11-01T17:10:58.655Z",
   "description": "added",
   "location_id": 1996459,
   "review_id": null,
   "type_ids": [
     111
   ],
   "user_id": 65250,
   "author": "Max Mender",
   "city": "Northampton",
   "state": "Massachusetts",
   "country": "United States"
 },

{
  "created_at": "2024-11-01T17:10:31.963Z",
  "description": "added",
  "location_id": 1996458,
  "review_id": null,
  "type_ids": [
    111
  ],
  "user_id": 65250,
  "author": "Max Mender",
  "city": "Northampton",
  "state": "Massachusetts",
  "country": "United States"
},

  {
    "created_at": "2024-11-01T16:34:22.853Z",
    "description": "added",
    "location_id": 1996457,
    "review_id": null,
    "type_ids": [
      20
    ],
    "user_id": 25249,
    "author": "Kristin",
    "city": "Norwich",
    "state": "Connecticut",
    "country": "United States"
  },

Here missed
[Apple ](https://fallingfruit.org/locations/1996456?c=forager%2Cfreegan&locale=en)(#1996456) added in Tiffin, Ohio, United States
[Common hazel ](https://fallingfruit.org/locations/1996455?c=forager%2Cfreegan&locale=en)(#1996455) added
[Tree swing ](https://fallingfruit.org/locations/1996454?c=forager%2Cfreegan&locale=en)(#1996454) added

{
  "created_at": "2024-11-01T12:22:52.033Z",
  "description": "added",
  "location_id": 1996453,
  "review_id": null,
  "type_ids": [
    93
  ],
  "user_id": 63346,
  "author": "AlexisVan",
  "city": "Watkinsville",
  "state": "Georgia",
  "country": "United States"
},
...
]

Data that rendered on main site
Hovered hovered itmes represent data above. As you can compare between data on main site and swagger are differnet

As you can see those 3 itmes didnt come from server, that makes this skips

[wbazant]

Thanks for explaining, I've made a ticket in the API repo. I think we can merge without that! Would you like to address the other bugs / suggestions before we merge?

[paskal98]

So far, this is the only bug I have found 🐛

As for suggestions, I would modify the API for /locations/changes to include the ability to search by date parameters “start” and “end” This would be a good optimization for both the list and future functionality.

[wbazant]

Updated the API ticket, thanks! What would you like me to do with this PR for now?

[paskal98]

I'm currently adding scroll-up functionality with skeleton loading for optimization and making minor updates. I plan to complete the work by the end of the day and would appreciate it if you could merge it afterward 😊. If any new bugs occur, I hope my implementation is stable, but if anything does come up, I will be happy to fix them as a new ticket

[paskal98]

I've added minor updates, but it seems that optimizing the infinite scroll will need more time to explore and discuss 🥲. It would be better if we could create a new ticket for that and close this one, if possible 🙂

[wbazant]

You could leave it for a while if you're fed up with it, or I can have a go at finishing the PR for you? It was a big piece of work, and you've done it the hard way (also reconsidering

I've looked at the code and there are

[wbazant]

Sorry, my baby sent a comment and closed the PR! I was gonna say, I can finish it for you if you like. Apart from the bug / missing feature with the list not coming back up, I also see some changes to the code that will be good for long-term maintenance of this feature:

• locationsById added to state.location that doesn't seem to do anything
• "getPlantName" instead of other uses of types access
• naming: "InfinityList" -> Changes or something similar
  Feel free to leave it and do something else for the project if you'll enjoy that more, and we'll get to doing this one too.

[paskal98]

I will continue 😁

It's interesting for me. I just need a time to research how provide optimisation for infinity scrolling. It seems no good solution using react-windows, because of items of list are always have different size, and using react window virtualisation may cause some new bugs. Other way using chunks, today I try added this one, but I struggle with not proper way of chunking data and other bug appears with not smooth scrolling. Additionally i added reducers for maintaining rerendering, it's seems to be good solution but with chunking it was laggy sometimes. So that is way I thinking about closing this issue , and opening others one. Just for delegation work. Provide good optimisation seems can take more time that we can expected

Additionally I wanna thank you for supporting and feedbacks!

[wbazant]

I agree with you that since react-window asks for fixed (or at least known) element sizes it is not the right tool here. I think how you're solving the virtualization is fine - with an IntersectionObserver and an upper limit of displayed entries so the page doesn't get infinitely long - it just needs another piece so the user sees something valid after scrolling back up. Or take a step back and just let the page get longer and longer.

When I'm not sure how to proceed with something, I find it often helps me to revisit the existing code and try to restructure it or simplify it - "make the change easy, then make the easy change" - and it's especially true since the availability of AI tools like Aider. So if I was to continue this work, I would start from that - for example, making a separate redux slice for this functionality will definitely be good.

[wbazant]

@paskal98 let's finish this PR together :)! If you're still interested in it, you could bring the branch up with the work we did since:

• we now have user pages that we can link to thanks to View user profiles #582
• Ethan added the attributes for paging the requests by day, see API for activity page falling-fruit-api#44 (comment)
• merge conflicts but shouldn't be too bad since it's a new feature

I can take it on once I'm done with #383, and can then take it over from you up to the finish line. We'll be sending out a newsletter soon and tell users we're developing the beta site, I think this is a really cool feature and a good showcase for what can be achieved with React vs. server side rendering on the live site, so it'd be neat if we had it working.

[paskal98]

Okay😊

[wbazant]

All right, I'm taking over! I'll open another PR when I'm done and add you as a reviewer.