botffy / bubistats Goto Github PK

This will also take care of handling the title changes needed for #39

on the station page.

• Show addRide form only on the rides page
• Add quotes to the stat pages.

When sorting by a column, it should always have an implicit secondary sort that makes the table look less ragged.

• Upload image to cloud storage
• Call function that processes that image and returns the values
• Fill the form and let the user add the ride. Or add automatically?

• storage and gcp processing of uploaded screenshots
• backups stored for 7 days

• Create a footer
• Create production build
• Deploy!

After #14 , we can implement a custom firebase auth for Strava (oauth flow => firebase token)

It should have its own section in the settings page.

"Cannot read properties of undefined (reading 'name')"

Elsewhere we handle this gracefully, displaying the station code.

Users can select dates in the future, but they will get a notification afterwards that it's not possible.

My recommendation is that the list should start with the current year.
The notification can be kept, I think only the year picker should be fixed.

• list of routes: from station a to station b, this many rides, retours, maybe first/last occurrence
• stats about retours, retour with same bike
• longest chains

There should be feedback for the user after every ride, the spinner stopping is not enough,

When the user clicks on the row, they should see the rides linked to that bike or station in a subtable.

• The "connect accounts" thingie
• Facebook
• Username/password
• A section in the settings page to connect more accounts

when the visitor is not logged in

When a new ride is added, toast messages should be displayed:

• the ride is the nth ride with that bike
• first/nth visit of a station
• break broken
• streak extended
• chain extended
• retour detection
• Fire celebrations on successfully adding a ride

this Could be calculated serverside, with the list of celebrations returned to frontend as the response

• Readme (with gittens)
• Licence
• Make repo public

• Dialog to display available and used filters
• Send filters to rideService
• Filters should be persisted. To local storage, probably.

So the problem is that the editor loves applying it's own rules while editing, for example, " characters for automatic imports.
It also loves to play with identation and other stuff like that.

We should at least agree on these things:

• identation (I usually prefer tabs, but as I can see here you @Botffy used 2 spaces)
• is line ending semicolons needed in ts files
• typescript types - should it break the build if we don't pass at least any
• maybe function complexity? (if we really wanna torture ourselves but in a beneficial way)
• empty line on end of file

ESLint for TypeScript: https://github.com/typescript-eslint/typescript-eslint/tree/master/packages/eslint-plugin

In my opinion we should try out the default configuration first, with our own set of rules that we discuss here.

It looks like nothing is happening.

• On a new "settings" page
• Let the user delete their account (rides)
• Let the user export their data

• in a footer
• there should be links to privacy policy, repo, about page
• a changelog page
• as well as version info (git commit hash and date)

• rides by hours in polar chart
• rides by weekdays in polar chart
• line chart for weekly rides

Also add a celebration if the user had to pay for the ride (the ride is longer than 30 minutes)

At least on mobile, when i add a new ride either by screenshot or by the form, I get wrongly calculated celebrations. As though the newly added ride weren't filtered out properly: e.g the first ride is celebrated as second etc

it should use dynamically calculated categories

It lets the user select only 0 and 1 as hours for the current day. Also, it doesn't allow seconds as input

Currently mostly everything is just in the src root (except totally reusable components like TimeAgo).

@egkrly proposed a feature based system, and we do have multiple independent features:

• stat pages (Bikes.vue, TimePage.vue etc, whose name could be standardised to *StatPage.vue)
• adding rides (RideForm.vue, RideFormByScreenshot.vue, the celebration service)
• the mostly static pages like InfoPage

ride-service.ts doesn't really play nice with this, especially since it reads and writes firestore data and also calculates celebrations (which it shouldn't). But it can be split into a "read rides from firestore" and "write ride to firestore" service.

• Create a scheduled function scraping the bubi api for stations, storing the results in Firestore. Keep old stations!
• let stationService draw station data from there
• Mark the dates when a station was out of service.
• Use the out of service data in the ride validation logic

• setup functions in project, emu. auth, cors, write to firestore
• addRide function
• validation
• Display errors
• use common model
• editRide function
• deleteRide function

It should be human-readable, easily accessible from the front page even when not logged in, and also when logged in. Maybe we could also push notifications about recent changes when the user logs in.

Users with no rides are presented with a rather confusing situation: they can click all the menu items, but all pages show the very same view:

Proposed solution
When the user has no rides, we should hide the menu items pointing at the stat pages and show the current page, except with an expanded tutorial/introduction about the thing.

fyi @egkrly

When the user is not auth'ed, we display the InfoPage in the StatPage and elsewhere. I did it this way because I like soft redirects, and we have no login page to redirect to anyway.

Once #14 necessitates a login page, we will be able to use vue route guards in the traditional way.

On mobile, the situation is pretty bad, as the navbar is squashed into the hamburger menu, and the html title isn't visible, that may need a different solution, but I'm not a fan of having a h1 title in the page itself