codeforfoco / fd-servicedirectory Goto Github PK

Right now there are separate calls for the google spreadsheet. In order to make the app easier to migrate to a PWA, we need to make 1 or a few calls to the google spreadsheet instead of calls scattered around.

For example, the search page pulls the google sheet and the home page does as well. These can both share the google sheet state (which should be similar to a commander-style design pattern).

Results

The google spreadsheet should be a single source of truth, or in other words, there should be exclusively 1 place where the sheet state exists and should only be pulled if necessary.

Needs #52 #53 to start work on this.

Any call to getGoogleSheet should be handled globally. This way we can keep track of errors more easily and output them to the admin's error page.

This is how things should work after this PR:

1. When the app loads, the entire google sheet is pulled. This is available globally.
2. After we get the google sheet, we need to test every category / service to make sure it is valid (not missing a category, has correct references, etc.) Utils for this will be done in #52
3. If a category / service is invalid, it will be removed from the results and the error will be logged on the /errors page, where admins can see warnings and errors about the sheet. See #53
4. A link should appear on the home page with text along the lines of: "There was an error processing your data. Site admins please see the /errors page" (There should already be a component for this)

There is logic to handle errors in the app. This should be extracted and tested in /utils

These should be pure functions that don't modify state. For example, something like this:

// Returns true / false if a category is valid.
// maybe returns an error message
const isValidCategory()...

Why?

Currently, the app is in use by the Poudre Fire Authority. Michael Durkin has presented the app to several fire chiefs who are interested in using the app for their fire department.

It'd be nice if our app could be in use by other fire departments as well as Fort Collins!

What we aren't offering...

We do not have the time or resources to offer on-call support to fire departments across the United States. The goal is to offer Fire departments ways to run and manage the app by themselves.

Acceptance

There are several ways this can be done. As of writing this, these are the requirements I've come up with:

1. Add very detailed documentation on the Wiki page for deployment instructions. This should be accessible enough that someone with no technical knowledge could follow the instructions and get the app deployed. Ideally, this would require the fewest steps possible.
2. The app should have a hook that pulls from master whenever we make an update.
3. Site metadata like icons, help page, titles, etc. should be easily modified. This could be done through a special page on our google spreadsheet.

Break this ticket down

We should break this ticket into smaller parts to make it more digestible.

As @airandfingers pointed out, lodash is used once in the project in the file src/pages/categories/index.jsx. We can easily create a uniqBy utility to replace Lodash's and reduce our package size.

@Vpr99 I'd like your input before we remove this. We may have plans to use Lodash in the future.

It'd be nice to have metadata for services like linkedin to be able to pull the site picture, title, description, etc. so on sites like linkedin, the webpage will display an image.

This is done through the "og:image" "og:description", etc. meta tags and should be added the /public/index.html

We should use tslint or update eslint to force best practices with Typescript.

Acceptance

1. Typescript best practices are identified.
2. Our linting should enforce these best practices.
3. Our pre-commit-hook should run the new linting rules.

The logo and intro text components on the home page should be smaller and have less margin. I think it takes up a lot of space, especially if fire fighters are using this on mobile.

Just a suggestion, we can keep it as is if you think it's best @Vpr99.

If you want to go forward with this, let me know and I can do it.

Right now, we search the database by pulling the google sheet and querying data by hand. It'll be less messy and probably more optimal to use "fuse.js" for text search.

I'm not sure how this will be done (we may need to break this down more to make it easier to understand / develop), but the I think the idea with making the app a PWA is to cache the spreadsheet and app bundle.

Results

The user should be able to access the site offline.

flexbox can be used to align the help page text CONTAINER on the center of the page. The text itself should be align: left.

I think it would look better this way.

We should use TypeScript for the app. Typescript only extends JavaScript, so I see no reason why not. We can slowly implement this as we add files and convert .js files if needed.

@Vpr99 what are your thoughts on this?

This issue'd be closed when we...

1. Add Typescript standard to README.md
2. Add Typescript support to the app.

@Vpr99 mentioned that he recommends adding Typescript through babel.

We should separate the block of code in the search page /search/index.jsx to make the code easier to understand, read, and more re-useable.

Admins should be able to view an error page where they can see google sheet errors.

When there is an error, admins should see something like this on the homepage and help page;

"Error processing data. Admins please see the error log page."

Depends on #64

We should test our new redux code to make sure it functions correctly. For example, we should test that the homepage, categories, orgs, etc. render correctly.

Basically, this ticket should be accepted when...

1. React-Testing-Library is added.
2. Testing file structure is decided.
3. We've tested the core functionality of new redux code

I noticed two things off about the current values in the Google Sheet:

1. Index sheet, cells C7 and C8 say "Counselins" instead of "Counseling".
2. Index sheet columns D and E repeat "house" and "water" over and over. I'd suggest changing:
   a. the "Mental Health/Addiction" rows (7 and 8) to "conversation" (and maybe "fire")
   b. the "Medical" rows (9, 10, 11) to "medical" and "fire".

I think it'd be a good idea to put in red text above the categories saying "For Emergencies call 911."
Let me know your thoughts on this.

It'd be nice to have a search page built for the fd. I don't think this would be MVP, but I think moving forward it's a must-have. Ideas for MVP user stories:

1. I can search for a type of service. For Example: "food" would return say, the food bank. We can use components from the categories page.

At least two services have a long "word" (a URL) that breaks the layout of the services and service-details screens on small phones.

Broken services list at /categories/basic-needs/housing:

Broken service details page at /categories/basic-needs/housing/cfc-3:

I'm not sure why the top title bar are broken by this, especially the nav bar's fixed positioning.

We should list the requirements for the help page. If we're talking MVP, this is what I had in mind:

1. Phone number to the current operator-system the fd uses
2. Link to where people can submit issues about the app

Reproduce this bug:

1. Go to "search"
2. Click the text field on a mobile device
3. The footer will appear on top of your mobile keyboard

The footer should stay in it's original position when you tap the text field on mobile.

Our goal is to handle google sheet errors instead of the app crashing. Currently, if data is not formatted correctly, we have potential for 0 categories to work!

There are a decent amount of changes we need to make for this to work properly. I listed them below:

1. Create category validation utils #52
2. Handle errors globally #51
3. Create base error page #53

Found a bug while running the app locally (master). My GOOGLE_API_KEY is pointing to the development google spreadsheet.

Notice how one of the icons is blank? We should have a type of default icon for services. It'll just make the app look nicer.

This issue is a "master" issue that should be a list of everything that needs to be done to make the site offline. This is what I have so far:

1. Make the google spreadsheet a single source of truth #54
2. Cache the spreadsheet / app / api so it's available offline #55

Why?

To help the user refine the list of services down to those that are applicable to the person they're currently helping.

Other notes

• Probably should be built using query params in the URL

When a users searches for a string and there are no results, we should display "no results". Otherwise the use may think the search never activated.

It'd be easy to create a dockerfile for the app, that way contributors have a single command to run the app and don't need to install or upgrade nodejs.

The footer apparently takes up some space from the main list container, so that on small phones like iPhone 5/SE (simulated via DevTools), the bottom category can be cut off:

Ideally, the footer would have a fixed amount of space with no overlap with main container, so that this ^ wouldn't be possible for any screen size or main content.