Rename SaaS frontend to React frontend

[ryankopf]

As we should be supporting any number of frontends based on what developers want, each frontend should have a name reflecting the technology it uses.

This PR renames "SaaS App" to "React App" in all places it is used. Because in the future, the options will probably look like:

> Stateless App
> API-Only App
> React Frontend
> HTMX Frontend
> Other frontends as desired

Since I hope HTMX is worked on from this issue, this is a necessary first step before we can approach HTMX.

I'm not quite sure how to test everything properly, but I did the following test and debugging steps to ensure this works. If I am missing any steps, let me know. Please also confirm that everything works as expected from your experience as well.

In the root project folder:

cargo test

Everything passes except 1 failure, but the failure is due to windows line endings in the mailer template "/r/n" so the test just needs to be updated later to accommodate either.

Then in the /loco-cli/ folder

cargo test

and all tests pass!

Here's the tricky part - the starters are generated from the BASE_REPO_URL, so I had to change that in my code while testing this to actually get the updated starters.

I had to modify "BASE_REPO_URL" to target my updated branch, and so I also had to specify a BRANCH_NAME. I figure this feature is useful to retain for future developers as they may add more frontends, making this easier to debug.

So in my case, to run tests, I had to set:

const BASE_REPO_URL: &str = "https://github.com/ryankopf/loco.git";
const BRANCH_NAME: &str = "react-frontend";

cargo build
.\target\debug\loco new
Presents the new options!

[kaplanelad]

Your efforts are genuinely commendable; thank you for the extensive work you've put in.

We should not support all kinds of started (like you write in the description).
Many starters mean a lot of maintenance and work and depend on a lot of changes in many places. the start should be minimalist, small and contain a context,

As I see it adding all these kinds of templates should be like this repo that people can clone and start to work on.

[ryankopf]

I agree, limiting the supported starting templates is probably a smart choice!

However making React the default starter for a SaaS application will alienate a lot of developers, and there seems to be a lot of community support for HTMX in the Frontend issue:

#130

I would definitely be on board with limiting the options to these, supported starters, and I am willing to volunteer to maintain the HTMX frontend starter template.

> Stateless App
> API-Only App
> React Frontend
> HTMX Frontend

[ryankopf]

(Closed PR on accident, sorry.)

[ryankopf]

Further note, I separated the PRs renaming "SaaS App" and creating the "HTMX Frontend" into two different PRs for exactly this reason.

Even if we don't support additional frontends, "SaaS App" is misleading when it is really "API + React Frontend".

[kaplanelad]

@ryankopf, as mentioned in my previous comment, For now, I prefer not to open the starters selection per use case (e.g., SaaS app, SaaS with React, SaaS with HTMX, etc.).

I suggest creating a project similar to this one. Users can clone it and start their work from there.

[ryankopf]

@kaplanelad I think the community should have a say regarding which starters are included. All the guides say to use "cargo loco new" to create a project, and having a "SaaS App" that starts with React is an unexpected experience for many devs. Further, a framework SHOULD be as JavaScript-agnostic as possible, which is why the recommendation for HTMX; it would be much easier to replace than replacing React if the default frontend is React. As I've said, I'm willing to volunteer to maintain an official HTMX starter.

Alternatively, all starters should be removed from the project and we should change the docs to suggest cloning one of the examples as you proposed.

[kaplanelad]

Reconsidering the way we serve starters is a valid idea. However, I suggest implementing such changes after we establish a clear vision and engage in thorough discussions about these modifications because this will affect on how we going to maintain and manage those apps (like I wrote you in this pr #345).

So, at this point, I recommend opening a discussion, making a decision there, and how it fits into the roadmap of @jondot and I

[ryankopf]

#355

[kaplanelad]

@ryankopf, I am closing this pull request for now.