trestres / ontheplate Goto Github PK

This is going to be rather tricky.

1. Figure out how to connect to GAPI
2. Determine if events can be displayed in calendar format upon query or if we can only guarantee a migration
3. Check data that is required for mapping
4. Since GAPI uses REST framework, determine if batching is appropriate

Currently the new user form only needs the password to be entered once

New passwords should be entered twice with some backing logic to confirm both entries are the same.

I mean, just because.

In GraphQL, Filters contain one or more Filter Groups
A Filter Group contains one or more Filter Conditions

We expect a user to save a filter in order to search lists, so we don't expect to actually use a Filter Group. There can however, be several filter conditions.

Users will:
-navigate to the searches page
-customize a filter using the UI
-have the option to run, save, edit, or discard the filter

When they save the filter, FilterConditions objects should be created and stored as info into the new Filter object. The entire Filter object is what's saved to the database, including the FilterConditions within. The conditions aren't expected to be reusable.

Is your feature request related to a problem? Please describe.
This should be phone-accessible to some extent and we shouldn't make the same mistakes we did with previous static sites

Describe the solution you'd like
First, some fidelity mockups of the mobile version are probably in order (contingent on desktop front end design)

Material-UI has ways of harnessing the size of the screen for a CSS baseline (I think it's even a Component) that can be used to present components on different kinds of screens

Describe alternatives you've considered
Bootstrap...is eh....?

Additional info
Add any other necessary info/reference material here.

Describe the issue or provide a code snippet

In resolvers/list.js and others, we're doing the same thing over and over to the data models retrieved from the database, e.g. transforming date objects into ISO formatted strings

Pitfalls to this approach
We're repeating ourselves multiple times, and we're likely going to screw up and provide inconsistent data at an endpoint

Suggested Fix
There may be a library that can take care of this, or more likely, we can write a module that handles data transformations from all resolvers, as a single source to handle mapping query results to JSON objects correctly.

Estimation of effort
This is a small to medium scale effort since it affects nearly all resolvers in lists.js, merge.js, and users.js. Conceptually, it shouldn't be difficult.

Describe the issue or provide a code snippet
This is self-evident. CSS was great in the beginning but now the prototype needs to start handling styles better. Nesting and mix-ins will be a big thing here.

Estimation of effort
We have roughly 6 different CSS files, so maybe an hour to replace everything with the current visual state as is.

Current look of the project

Why it can be better:
Our shared components look very bland and are concocted using a mixture of vanilla CSS and material-ui. This is fragile and does not take advantage of themeing

Suggested change
When doing a visual pass, make sure that these are addressed.

with auth:
update user info
delete a user
get all the lists for a user
get all the tasks for a user
update a list
delete a list (deletes all tasks within)
update a task
delete a task

Describe the bug
Reloading the page after login destroys the token and sends the user back to the login screen

To Reproduce
See description

Expected behavior
We have a token expiration time and make the token persist until that time has lapsed

What can we use for safe persistence in local storage?

https://mochajs.org/#getting-started

https://easygraphql.com/docs/getting-started/overview

There should be test against the queries, mutations, and all the resolvers

Please, I'm so tired of copying user _doc ids

Suggested change
We can use a sliding/overlay mechanism to transition between pages, with the nav bar acting as a track, instead of suddenly blinking to the content.

https://graphql.org/graphql-js/type/#graphqlschema

We should leverage the API to make extensibility easier:

1. Instead of using template literals for schema, use constructors to create types
2. Resolvers should be split into files for functional areas, and then collated in graphql/resolvers/index.js
3. We can use the power of template literals/text on the other hand to define enums in one place for mongoose models and graphql types alike

There's likely to be some sort of other piece that would allow us to generate mongoose models and graphql types from a singular endpoint, but that is a lot of nuance we may not need

We can create custom theme items that can make the UI consistent.
As much as possible, we should apply one single theme at the root level with enough attributes to cover different components.

This will likely involve changing the navbar to use MUI components as well.

https://material-ui.com/customization/theming/#createmuitheme-options-args-theme

Now that we know that the authorization workflow works using our middleware, we should upgrade to Auth0

I didn't know those were a thing. 😓

See design: