Extra information on Profile

[davehakkens]

Component infos

Description

In the profiles we need some additional information in a sidebar
Map pin: Show if profile has map pin (and link to pin. )
How-to: Show amount of how-to's created by this profile (all approved ones)
Events: Show amount of events created by this profile (all approved ones)

Page related

Will be used in :
Profiles

Mockup

[BenGamma]

For this one IMO we should add new fields in the user model : howtoCount & eventCount to avoid having to do heavy reading on the DB (that filters from all how-to's the ones from the author) each time a user profile is displayed.
Instead Increment the counters howtoCount & eventCount each time a how-to or event is approved. These values are directly on the user's data, along with his basic informations (name- profile pic, etc).
What do you think @chrismclarke ?

[chrismclarke]

Yep definitely agree with you that we need to keep specific counters for these things rather than calculating each time. I would suggest however instead of adding a lot more to the user profile we store the info either in a single userStats variable, or possibly use a subcollection so all the info sits at users/chrismclarke/stats or similar in the db.

I also think we should move the logic away from individual pages/stores (e.g. update when a user clicks to create a howto), to the database itself via triggers (i.e. when new entry is detected under howtos, read the _createdBy field and update that users stats). Actually, a good way to go about this would be to write a single trigger for all db updates (create or delete events), that keeps a single list of every entry created by that user, so all howtos, events, mappins in the same place - we can then just pull that list and filter to present any stats we want?

[BenGamma]

Agree with the userStats variable.

I also think we should move the logic away from individual pages/stores

You mean we will then create a firebase function that will update userStats when a db entry is created or updated ?

[chrismclarke]

Exactly, so nothing needed to be called manually from the user on the webpage (which is much more prone to error), and nothing required in main platform code (all be within the functions instead)

[alromh87]

Hello DB trigers for updating count when new howto/event are ready, now I will go for the display. What are your tougths on data for the frontend:

Extend user model
Create new model just for this

Note: I remember that last time I added fields to a model It caused trouble with the caching system and it would trigger big dta updates

[alromh87]

In case of the first is possible I have PR ready

[davehakkens]

Neat
Could you make sure it also says How-to and Events?

Now it only shows the icon..

[alromh87]

Thanks updated

[davehakkens]

Howto is called event? Also should be on one line

[alromh87]

Should be fixed now

[chrismclarke]

I've made a few changes to the code to also keep track of draft/pending as well as specific ids of events/howtos in the stats as it's cleaner from a dev perspective and figure could be useful in the future. @davehakkens - by default this shows the counts for both approved and pending howtos or events, is there a strong preference to have the number only indicate approved (one line of code to filter if that's the case), or ok to include both?

[davehakkens]

no strong preference. Including draft/pending count for how-to's is also good. (there are very little of those anyway)