squanchy-dev / squanchy-firebase Goto Github PK

The behavior for Date objects stored in Firestore is going to change
AND YOUR APP MAY BREAK.
To hide this warning and ensure your app does not break, you need to add the
following code to your app before calling any other Cloud Firestore methods:

  const firestore = new Firestore();
  const settings = {/* your settings... */ timestampsInSnapshots: true};
  firestore.settings(settings);

With this change, timestamps stored in Cloud Firestore will be read back as
Firebase Timestamp objects instead of as system Date objects. So you will also
need to update code expecting a Date to instead expect a Timestamp. For example:

  // Old:
  const date = snapshot.get('created_at');
  // New:
  const timestamp = snapshot.get('created_at');
  const date = timestamp.toDate();

Please audit all existing usages of Date when you enable the new behavior. In a
future release, the behavior will change to the new behavior, so if you do not
follow these steps, YOUR APP MAY BREAK.

We should be able to treat private submissions as such. Syx passes us that flag but we don't support it; it may come especially handy when/if we have a CMS/CFP platform of our own.

Now that we have some tests (adding more is an ongoing effort) we should have a CI to validate them too. We should be using CircleCI like we do for squanchy-android.

https://github.com/firebase/firebase-tools#using-with-ci-systems

We should deploy every time we do a merge on master.

Right now we need to fetch the tweets manually but it should be a cron'd job (e.g., every 5 minutes). See here

Right now we're using Optional as our optional type, cause it lets us have a typeguard:

const present<T>(Optional<T> t): t is T

this is great but the best would be able to use typescript optional const present<T>(t?: T), investigate if that's a feasible solution

Gulp has served its purpose well, but it's time to say goodbye and use babel to compile the app.

Reference: https://github.com/Microsoft/TypeScript-Babel-Starter

See #3 (comment)

Right now we're using manually triggered functions to convert our data to views, ideally we should have a Cloud Firestore Trigger firing up the function.

Most likely we can go with onWrite and write/delete the record as required.

We need to create views in Firestore (some through Cloud Functions by reading the raw data coming from the CfP platform into Firestore itself) that normalise data so that it's ready to be digested by the app.

• Schedule
• Tweets (social stream, comes from Twitter)
• Venue info (static data)
• Favourites (needs a users collection linked to Auth that holds favourite IDs and user profile)
• Search
• Event details
• Speaker details
• Conference info (static)
• Tracks

We need to add other_events to:

• Schedule view
• Event details view

Add function template that allows to import the conference data from a 3rd party API into firestore.

Right now we have basic validation for patch, but a few rules are only written in // TODO comments. We should implement those checks.

The tweets feed is in /social_stream/twitter/tweets but should be moved to /views/social_stream/tweets for consistency with the rest of the views

Due to how Syx works, all our events backed by a submission have type talk, including the ones that are in fact keynotes. When generating views we should check if type == talk && track == keynote and in that case change the type to keynote.

We need to ensure references pushed with patch are existing, or fail the request otherwise.

#62 introduced some great ideas (the enum, some other things) which we want to keep in master, cherry pick these

Currently the event index in Algolia matches the query with the name of the event and its description. It should, if present, match it with the speaker name too.

Real life use case: I'm searching for a speaker, not because I'm interested in his bio, but because I'd to see what talk he will perform

See https://cloud.google.com/firestore/docs/manage-data/export-import, we should dump the DB for the dev DB instance (sans user data) and make it available for people that wants to get started bringing up a dev environment.

We must comply with GDPR, useful summary in https://techblog.bozho.net/gdpr-practical-guide-developers/

Right now the client just needs the twitter handle, as it will try to deeplink into the Twitter app and if it can't then it will open the browser building the full url

Currently the speakers order for events is lost when creating the schedule (and possibly the event details too)

Cloud Functions 1.0 are out and they have some breaking API changes. We should move to the stable version.