lasagna-love-portal / project-ricotta Goto Github PK

next.js is a framework that builds on React to move rendering of pages from client to server. next.js is intended for websites where data is not highly variable, where much can be pre-rendered on the server and updated on a periodic basis. next.js came into the project with the work to separate Project Ricotta out of its monorepo structure and into a Docker deployable container. It's not known whether this was an intentional decision, or one made for ease of getting that work done.

I propose the removal of next.js from the project and a shift back to using React on its own without next.js. This will shift page render predominantly back from the server to client-side rendering.

Pros:

• next.js can improve initial page rendering times for static content and for dynamic content where that content is not updated frequently.
• next.js improves SEO over just using React

Cons:

• Using next.js moves the project-ricotta repo away from our long-term goal of using the project-ricotta codebase as a starting point for Android & iOS apps via React Native. Some projects are out there for using next.js with React Native, though they appear to be fairly early efforts with significant issues.
• Many if not most of the pages on the volunteer portal are dynamic and content is driven from API calls that are not conducive to infrequent updates.
• Additional package maintenance and overhead that may not be giving any real return
• next.js 13 (the next upcoming version, currently in beta) is going to significantly restructure how projects are written, and will likely prompt significant effort if we want to move to it once out of beta

On initial page load, the progress indicator, Create Account button, and Log In text renders in front of the photo gallery, then disappears. It does not re-appear until the photo gallery auto-scroll is triggered. The behavior is inconsistent, but seems to be more frequent when viewing on a narrow viewport.

Environment: Chrome 112.0.5615.137 on macOS Ventura 13.3.1 (M2)
App Build: Commit 81be0a2

I'm running the app via the new Dockerized environment in #24, which may have introduced the issue.

In testing #32 it was discovered that as of commit 4483304 the project would run when run in a Docker container, but running npx next build would error out with TypeScript issues.

Best would be to prevent the Docker container from building if there are issues?
Or to recommend local compilation as a sanity check?
Or some other solution?

description:

False positive in lint report: "github" used in link. i.e. https://github.com/Lasagna-Love-Portal/bechamel-api
Lint expected "GitHub" (PascalCase)

screenshot of workflow error:

zoomed screenshot of workflow error:

raised error

/github/workspace/README.md
  89:31  ✓ error  Incorrect usage of the term: “Github”, use “GitHub” instead  terminology

✖ 1 problem (1 error, 0 warnings)
✓ 1 fixable problem.
Try to run: $ textlint --fix [file]

fix?

1. Open README.md file.
2. Find the line with the error (line 89).
3. Replace with fix, replace github with GitHub while potentially breaking link, avoid links with PascalCase?
4. Save the file.
5. Open a terminal or command prompt.
6. Navigate to the directory containing the file.
7. Run textlint --fix README.md command.
8. Verify the error is fixed in the file.
9. Commit and push the changes to the repository.

When running super-linter locally, results differ from when the linter is ran via the Actions workflow. This is because have overrides living in both the workflow file itself and the linter configuration directory.

Can we consolidate these so they live in a single location, or otherwise provide configuration such that we get consistent results from Actions and local execution?

An authenticated user should be redirected from the homepage to http://localhost:3000/landing automatically, rather than landing them back at the Create Account/Log In homepage.

Potential tasks to close PR#19:

• Local development with MySQL.
• Validate .sql files (this could be a separate task):
  • backend-app/sql/ricotta_tables.sql
  • reference_materials/ll_v1_database_tables.sql

Inspired by #47 - this PR introduces some cloud architecture principles and discussion that applies across Project Ricotta, and not just the project-ricotta repository. Previous to this PR, @iamthebot and @mattkuznicki-ll authored a general architecture proposal covering cloud and other topics as a Google Doc - see the Quick guide for details (not posting here).

Let's determine where cloud and architecture discussion and information germane to the whole Project Ricotta initiative should live, and then move what needs to be moved to reflect that decision.

Right now, the base URI for accessing the Bechamel API is hard-coded in source.

This should be updated to be obtained from a configurable source, such as an environment variable on the server-side provided to the client.

The linter configuration seems to have a conflict between the ESLint and TSConfig files, as shown in the linter output. The added .ts files seem to lint OK but I've not yet been able to get a tsconfig.json + .eslintrc.json pair that successfully has the src/services files included. Files in src/pages seem not to have this issue, even without an explicit include of that directory.