davidajohn / my-guitar-collection Goto Github PK

This would be useful, especially for testing cloud functions and security rules.

There's a great video explanation here.

This is long overdue - the homepage needs to be generated dynamically from real data now that the 'add new guitar' functionality is in place.

I have photographs of my own guitar collection, let's add them and then show them in descending date order initially, and then later, allow them to be viewed in order of popularity once the 'like' functionality is implemented.

Adding a footer would be a simple way to improve the look of the site.

It doesn't need to do much - perhaps just link to an About page that explains the project.

Before moving on with the rest of the project, it would be good to update from v9 of Angular to v11. There are always performance gains in terms of bundle size with each version.

It should be done in two stages, v9 to v10, then v10 to v11.

Head to: update.angular.io

Using Tailwind has somehow caused a problem with the main page layout, even though I can't find the direct cause.

Perhaps there's an issue with the way Tailwind interacts with angular Material.

It may be best to remove Tailwind and stick to using flexbox and/or css grid for the layout instead.

When a new guitar is added, the owner id is saved, but the owner name is null.

It needs to contain the logged in user's display name.

Are the cards on the home page too big?

Even on a monitor at 1920x1080 they feel a bit much. Let's look for a way of presenting info to the user that is more about the visual aspect rather than showing too much text, even if it means moving away from the Material card component.

You know what guitar players are like... we just want to droll over pictures anyway.

While there are comparatively few components and services at the moment, there really should be some more unit tests added to the application.

I'll also think about integration tests and bringing in cypress at some point too.

With Firestore being a NoSQL database, there will need to be some duplication of data between the players and guitars collections.

Although the PlayerId is stored in the guitars collection, it doesn't allow us to get the player's display name or their profile picture via a traditional SQL-style join.

The displayName and profileImage fields will need to be held in both tables. They can then be kept up to date with a cloud function if the user ever updates their profile. Ultimately, this is about quick read access to the collection of guitars.